[dano]

well…I knew someone would correct me if I was wrong. There is one issue I have run into regarding partition maps related to external drives. This problem occurred under Tiger (haven’t checked under Leopard yet). Disk Utility wouldn’t change the external hard drive’s partition map scheme. If you had formatted your drive while attached to a PowerPC computer and then tried to reformat while attached to an Intel computer, the partition map would not change from APM to GUID. Which makes the external drive non bootable from an Intel Mac. The workaround for this is to erase the disk using the diskutil tool from Terminal.

[dano]

An image generated on Intel hardware probably is not compatible with PowerPC hardware or vice versa. What this means is you should:

1. Deploy images built on Intel hardware to Intel hardware only.
2. Deploy images built on PowerPC hardware to PowerPC hardware only.

Note: There was some rumors that Apple was going to unify the partition mapping between PowerPC and Intel. Not sure if it happened. It’s safer to assume that Intel images won’t work on PowerPC hardware and vice versa. This is definitely the case under Tiger and I suspect the same applies to Leopard.

[dano]

First….the disclaimer….I have no idea what’s going on.

If I were attemtpting to remedy this, the first thing I would try is to remove the user account setup packages. Then generate an InstaDMG image and restore to your test volume. Boot the newly restored volume and see if you can successfully boot your image (after manually generating your first user account). If you are successfull then it might be some sort of issue with your user account generation packages.

Second option would be to try generating your InstaDMG image on an Intel Mac if you have one available.

[dano]

better get to that coffee quick…. 😀

[dano]

Thanks Spider….I’m just in the process of figuring out how to install user accounts. I haven’t gotten to Office yet but will keep this in mind when I get to Office.

[dano]

One more comment. I would install all Apple applications (Aperture, iLife, iWork etc) that are part of your base image into the AppleUpdates directory first. Make sure they are first in the order of install. Then install all applicable updates. If you are installing an Apple application that is not installed on all your workstations, I would place it in the CustomPKG folder and then add all the applicable AppleUpdates in the CustomPKG folder as well.

One other option would be to install the Apple application and applicable updates separately as part of your deployment process. In other words you would install your base image and then install separate packages comprised of this application and applicable updates after the image has been restored.

Of course, there are lots of ways to do this and ultimately it’s up to you!

[dano]

I should add that I’m moving to Leopard and all my testing is on Leopard exclusively.

[dano]

I’ve installed iLife as the first AppleUpdate using the original iLife package. Testing is on a MacBook Pro as my build machine for setting up my build workflow. Everything worked fine. Try this AppleUpdates order:

/{path to InstaDMG folder}/AppleUpdates/00/iLife ’08.mpkg
/{path to InstaDMG folder}/AppleUpdates/01/RemoteDesktopClient.pkg
/{path to InstaDMG folder}/AppleUpdates/02/iDVD_701.pkg
/{path to InstaDMG folder}/AppleUpdates/03/iMovie_710.pkg
/{path to InstaDMG folder}/AppleUpdates/04/iPhoto_710.pkg
/{path to InstaDMG folder}/AppleUpdates/05/GarageBand_411.pkg
/{path to InstaDMG folder}/AppleUpdates/06/iLifeSupport.mpkg
/{path to InstaDMG folder}/AppleUpdates/07/iWeb_203.pkg
/{path to InstaDMG folder}/AppleUpdates/08/QuickTime745_Leopard.pkg
/{path to InstaDMG folder}/AppleUpdates/09/iTunes.mpkg
/{path to InstaDMG folder}/AppleUpdates/10/AirPortUtility_Leopard.pkg
/{path to InstaDMG folder}/AppleUpdates/11/FrontRowUpdate2.1.3.pkg
/{path to InstaDMG folder}/AppleUpdates/12/MacOSXUpdCombo10.5.2.pkg
/{path to InstaDMG folder}/AppleUpdates/13/iMovie_711.pkg
/{path to InstaDMG folder}/AppleUpdates/14/GarageBand_412.pkg
/{path to InstaDMG folder}/AppleUpdates/15/iPhoto_712.pkg
/{path to InstaDMG folder}/AppleUpdates/16/LeopardGraphicsUpdate1.0.pkg
/{path to InstaDMG folder}/AppleUpdates/17/Time-Machine-Update.pkg
/{path to InstaDMG folder}/AppleUpdates/18/SecUpd2008-002.pkg
/{path to InstaDMG folder}/AppleUpdates/19/Safari311UpdLeo.pkg
/{path to InstaDMG folder}/AppleUpdates/20/iPhoto_713.pkg
/{path to InstaDMG folder}/AppleUpdates/21/RAWCamera.pkg

Note: Two packages needs “hacking” before they can inserted into the AppleUpdates chain. Details as follows:

iLifeSupport.mpkg (without this iLife apps won’t launch due to inability to find necessary app frameworks/libraries)
1. Open file – iLifeSupport.mpkg/Contents/Installers/iLifeMediaBrowser.pkg/Contents/Resources/postflight_actions/repairLeopardLinks
2. On lines 25 and 30, immediately following the equal sign, remove “$TargetDisk . ” ($TargetDisk – space – dot -space)
3. Save file

iTunes.mpkg (scratch disk image won’t dismount due to postflight action which launches iTunesHelper app)
delete – iTunes.mpkg/Contents/Resources/iTunesX.pkg/Contents/Resources/postflight_actions/runiTunesHelper

[dano]

After a little more experimenting I’ve determined that the contents of the password hash file is strictly password information. There is no UUID link to the contents of the hash file. The name of hash file, however, must be the account’s UUID. It would appear that he following sequence of events happens when an account is generated:

1. After inputting user name and password information, an account is generated with appropriate keys including the randomly generated UUID.
2. A file is created using the account UUID as th file name and saved to /var/db/shadow/hash
3. The password is “hashed” and the resulted is saved to the file created in the previous step

I’ve also determined that one can take any hash file and attach it to any user account as long as the name is changed to the UUID of the account it is being attached to. I haven’t figured out how to generate a password hash but do check out the sample script specified by the initial post of this thread (posted by akinspe )

[dano]

The issue is the command to generate a password doesn’t work. All the other commands to generate the various account keys work. If one boots from the install DVD and uses the password reset utility to change the password, it is possible to successfully login to the account.

[dano]

The tip for using dscl on a non booted volume is good. The only problem I’m having is setting a password on an account I’m generating on a non booted volume using this method.

Using the appropriate command for setting password on account on a booted volume works:
/usr/bin/dscl . -passwd Users/instadmg “password”

whereas using the command for setting a password on account on non booted volumes doesn’t work:
/usr/bin/dscl -f “/Volumes/InstaDMG/var/db/dslocal/nodes/Default” localonly -passwd /Local/Target/Users/instadmg “password”

Any suggestions would be greatly appreciated.
Thanks

[Author]

Posts