InstaDMG system slower to boot than DVD installed system

[ptone]

I have a hybrid instadmg style w/radmind deploy method.
I was noticing slow boot times on my test machines of SL as I get this school years SL update ready.
I’m working with original 10.6 update DVDs that came with our last big purchase of Macbooks and the 10.6.4 combo updater.
Using the osinstall.mpkg onto a partition, and then restoring that partition to another partition results in boot times in the 50-60second range on my lab AL iMacs, while using the installer on the same DVD to do an install on a partition results in an OS install that boots in 20-30 seconds?
I’m trying to use the mpkg under the assumption that I want an “unbooted” image
Has anyone else noticed this? I’ve replicated it several times.
Is there some post processing being done by the SL DVD installer that is not being done by just the regular installer?

This is more a question of the InstaDMG methodology rather than the reference script – as I’m invoking the osinstall.mpkg install outside instadmg.

Does anyone know what steps the DVD installer is doing beyond the package install that would effect boot times? I’ve zapped pram, set boot volume etc.

-Preston

[Allister Banks]

Hey Preston,

I haven’t had the partial success you’re experiencing when I’ve done .mpkg OS installs, just it works or it doesn’t(‘1st gen’ mac mini servers wouldn’t boot 10.6.0 server retail + combo update, for example) so I can’t tell why that’s happening. What is restoring the partition? Are these the newest iMacs?
This isn’t a ‘best practice’ per se(yet), but you also may want to snag a 10.6.3 reference build from a new box set or late SL upgrader that gets a retail copy and try with that. Do logs show anything helpful? And the original partition your installed before restoring, does that one boot with the same lag? What OS are you running the installer.app from?
The DVD-booted installation does do consistency checks, as does instadmg(among other housekeeping it runs the diskutil binary to repairpermissions,) but when you’ve gotten the symptom repeatedly on different hardware with different partition schemes(like for instance, onto a firewire-target-disk booted volume) those peculiarities should subside. There are more consistent -target options when you run the installer binary from the command line rather than the GUI(as instadmg does), but I would be surprised if the Cocoa version of installing the osinstall.mpkg was at fault exactly.

Good luck,
Allister

[ptone]

as a follow up – the issue was that by using the installer cmd on a partition and then grabbing that as an image, the owner of / of the restored system was 501:80 instead of root (0:80).

This was preventing the kernel caches from being rebuilt properly

so a:

chown root:admin /
touch /System/Library/Extensions

now startup takes half the time

-Preston

[Allister Banks]

Wow, the bad juju!
It’s been many, many svn revisions since diskutil –repairpermissions was added to the the “closing symlinks that point off the disk” stage, so I would’ve really hoped between that and a chrooted installdaemon an image couldn’t make it out of instadmg so borked. Just chown’ing /, huh? Thanks for offering it up to the great google in the sky!

Allister

[ptone]

Actually – if you look at my OP I mentioned that I was using an InstaDMG methodology, but not the reference tool

hence all I was doing was using the CLI installer tool on a /Volumes/X partition

I’ll have to check the current InstaDMG script for other steps that I should put into my workflow

-Preston

[Author]

Posts