- This topic has 8 replies, 4 voices, and was last updated 16 years, 4 months ago by
afp548contributor.
-
AuthorPosts
-
November 24, 2008 at 6:33 pm #374842
blake
ParticipantI’m tracking down why my InstaDMG build train is producing un-bootable images. It turns out that one of the apple SU’s im using currently testing requires 2 reboots of the system when installing it normally. In the past I have seen a server SU require 2 reboots but this one is for the client OS.
Can InstaDMG handle a .pkg that requires this? If apple releases a SU that does this it seems like instaDMG would be crowbared. I’m working back through my .pkg’s to make sure that the problem is this specific SU.
Blake
November 24, 2008 at 9:09 pm #374848Rusty Myers
ParticipantThis is a total guess, but I’ve always assumed that the installer must be using some launchd item at first boot to install/configure something, then reboot again. Again, total guess, but I would think it should work if it was doing that. It would just assume that the first boot was right after you installed the package, and then it would do what it needs to and reboot again. It’s totally possible though that something else is stomping on those configurations and creating a un-bootable image. Perhaps try to narrow it down by isolating that specific install and testing.
November 24, 2008 at 10:15 pm #374850blake
ParticipantWhat I’m seeing in the .pkg is a RunAtStartup script that seems to be moving a bunch of files from /System/InstallAtStartup/path/to/file to /path/to/file
And then doing this
touch “/System/InstallAtStartup/.InstallAtStartupRestartAgain”Blake
November 25, 2008 at 7:57 pm #374873Patrick Fergus
ParticipantI’m pretty sure there are current OS X client updates that perform a second reboot on startup. Haven’t heard of people having problems that are directly attributable to that.
Not to say there won’t be issues, but I don’t think there’s a known issue.
– Patrick
November 25, 2008 at 11:29 pm #374879blake
ParticipantOk well I have a new build of this update and I’m setting up a clean 1.4b4 instaDMG setup with 10.5.0 and only this update to double check the setup. I have heard of a coworker who was successful using this .pgk with instaDMG. Time to eliminate some variables..
December 1, 2008 at 11:32 pm #374901blake
ParticipantLooks like using the -t option and specifying a temp dir on a disk other than the root volume is causing the issue. I’m attempting to determine if the -t option alone is the issue or if this SU and the -t don’t like each other.
Anybody use the -t option to move the tmp directory to another volume successfully?
Blake
December 4, 2008 at 10:00 pm #374930blake
ParticipantTurns out that I was wrong about the updater being the problem. That’s what happens when you change more that one thing at a time..
My current theory is that the -t option is causing the issue. I opened a bug on google code. http://code.google.com/p/instadmg/issues/detail?id=16
If I have some time I will try testing the -t option to determine if the problem always happens with -t or only when the temp dir is on a secondary disk.Blake
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed