[dead2sin]

The function for check volume has a new name, so that code didn’t work with the new update. I’ve taken to Liberty of updating Mosen’s patcher. I’ll post it in a new thread.

Nate

[dead2sin]

Correct, you don’t need to mess with the chroot jails. I download latest svn copy of InstaDMG and it’ll spit out an image using my firstboot package with correct permissions.

Here are a few random questions:

What machine are you building on? Is it 10.6.4? Client or Server OS?

What file system are you using? HFS+ Journaled or HFS+ Journaled and Case Sensitive?

I guess the more info we have the better.

if you could give us the bit of info InstaDMG spits out, that might also help. This block:

07:39:20 ###### InstaDMG build initiated ######
InstaDMG version 1.6rc1 (svn revision: 388)
Host OS: Mac OS X 10.6.4
Host Hardware: MacPro1,1
Output file name: staffleopard-10.6.4.13-test01.dmg
Output disk name: Macintosh HD

Nate

[dead2sin]

That is entirely weird.

Here is a good test. Install it on a test machine like you would a regular package, then go to the LaunchDaemons folder and do ls -l to see what the permissions are. If they are right, then its some issue with the InstaDMG build process.

Nate

[dead2sin]

That sample package turns out the same way it would if I posted my actual package. When you download the .dmg, you assume ownership of it and when you copy the items to your desktop, you own those as well. Could you post a screenshot if your contents tab for one of the items?

Nate

[dead2sin]

If you have OD, I wouldn’t bother with any settings via package.

The problem with multiple packages is that you’ll gunk up your receipts on the OS. Each package creates a receipt which you can view with the pkgutil command (pkgutil –pkgs). If it is payloadless, then there is nothing that pkgutil can uninstall, so the info is only somewhat useful.

I don’t have OD right now, but if I did, most of my settings would go into OD and I’d ditch a lot fo the stuff I set via firstboot.

Nate

[dead2sin]

Best practice would be to set this stuff using a single firstboot package. You *could* do one package per setting, but I find it to be rather cumbersome. I generally do all my settings via a postflight script directly on the InstaDMG image except for those that can only be run on first boot, in which case I use a LaunchD item to run a script and then have it delete it launchd item and the script.

Here is a running list of helpful stuff to change and the commands to do so:

[url]http://osxdeployment.com/wiki/Firstboot_Postflight_Commands[/url]
[url]http://osxdeployment.com/wiki/Firstboot_Script_Commands[/url]

Some things like Dock I do with a package. I think customizing the admin login isn’t necessary…most things you admin should be done transparently using ARD, SSH, etc. This is the style of admining I came to adopt anyways, I’m sure many people do it many different ways 🙂

Nate

[dead2sin]

I just tested the link and asked several others to test it and it seems to be working. Perhaps an internet filter is getting in the way?

Nate

[dead2sin]

Ah, yes. 644. I googled quickly to figure out which it should be and apparently Googled lide to me 🙂 I fixed it on the wiki.

Nate

[dead2sin]

So in Iceberg, the permissions are set to root:wheel for owner:group as well as being 655? You are running InstaDMG as root, correct? (I don’t think you can run it any other way, honestly…)

Something else has to be going wrong with the permissions. Try setting the correct permissions on the files themselves as well as in Iceberg and see if that works. I tested iceberg and it delivered the files with the proper permissions regardless of what they were in the project folder.

I doubt InstaDMG is messing up the permissions…I’ve never had it do that for it. If it is correct in the Package, then they’ll be correct on the image (InstaDMG merely installs the packages, it doesn’t really mess with permissions a whole lot)

Nate

[dead2sin]

I updated the guide explaining how to get it working with PackageMaker. If the permissions are fixed in PackageMaker, it works (I tested it). I’ll be rewriting the guide for Iceberg when I have time. Iceberg will keep the permissions when downloaded and copied over, unlike the PackageMaker example files.

Nate

[dead2sin]

It will, but you’ll want the postflight to fix the permissions of the files after they are put into place by the package file.

I use JAMF’s Composer to build my post flights and have never had permissions issues with it at all. I think everyone should have it in their toolbox 😀 😀

Nate

[dead2sin]

I know firstboot packages work with InstaDMG, so I’m not sure what else could be causing it. PackageMaker might not be saving the permissions correctly or not applying them correctly after the files are placed. Perhaps creating the firstboot.pkg using another free packaging program would be a good troubleshooting step (I use Composer, which isn’t free, but it works 100% of the time for me).

Perhaps you could try using Iceberg and see if you come up with a different outcome: [url]http://s.sudre.free.fr/Software/Iceberg.html[/url]

Nate

[dead2sin]

This is a rather annoying quirk of PackageMaker (Or perhaps my inexperience with using it), but it seems that when you mount the Firstboot.dmg, it doesn’t retain any information about owner and group on the files within the package. Just go to contents and change the permissions to what I references in my earlier post.

Nate

[dead2sin]

Just for reference, the launchdaemon must have the following permissions:

Owner: root
Group: wheel
Permission: 644

Nate

[dead2sin]

It sounds like the permissions on the launchd item are wrong and the script isn’t being run at all. If the login window changes, that means the postflight script is working, but the firstboot script is not.

Nate

[Author]

Posts