InstaDMG 1.4b3 causing Kernel Panic

[rfitzwater]

I am curious if anyone else has experienced the same problem I am. Basically things have been going great using InstaDMG to build our images. Using the ASR file created by InstaDMG 1.4b3, using all the same packages and base OS, applying this image results in a kernel panic at boot. The kernel error mentions the following: [i][quote]Unable to find driver for this platform \”ACPI”\.\N”@/SourceCache/xnu/xnu-1228.5.20/iokit/Kernel/IOPlatformExpert.cpp:1407
.
.
.
Mac OS version:
Not yet set
.
.[/quote][/i]

I was able to resolve this issue by booting into safe mode (holding shift key). I am assuming since holding the shift key at boot rebuilds the Extensions.kextcache and Extensions.mkext files that this resolved the issue. Subsequent reboots were without kernel panics.

I was able to reproduce this by imaging several models of iMacs. Each got the same kernel panic at boot.

I then went back and rebuild the ASR file with InstaDMG1.4b2 to see if the problem was somehow caused by 1.4b3. After rebuilding, with zero changes, I reapplied the image to the same machines and the booted fine. No kernel panics!

It would seem to me that the kernel panics are now caused somehow by some process that was modified in InstaDMG 1.4b3. Can anyone confirm or provide more details?

Thanks,

-Rhon

[Chris George]

This is interesting. I’m still in the “just getting started” with InstaDMG, and yesterday I created and applied my first image generated with it to a 20″ iMac. The machine booted to the Apple logo and pinwheel… spun for a good 3-4 minutes, rebooted, and repeated the process. I’m thinking that something related might be happening in the background, though I didn’t have a chance to check yet for certain.

One reason I think it might be related:
[i]Mac OS version:
Not yet set[/i]
When I used NetRestore to download the image from the server, it yelled at me saying “some of the postrestore scripts cannot tell what version of Mac OS is in use” or something like that.

[rfitzwater]

Chris,

I would try reboot into verbose mode to see what is going on. Hold down Command V key when booting. You should see where and possible why it is rebooting. Post any relevant messages back. You may want to open a new thread though.

-Rhon

[Chris George]

Well, I retract my report. Turns out that the instauser script I was using was stomping all over var (the same problem as the users in [url=https://www.afp548.com/forum/viewtopic.php?forum=45&showtopic=21354]this thread[/url].) Correcting my instadmg package allowed the build to complete successfully.

[larkost]

Thanks Chris!

This explains nicely the reasons why some of us can see it and others can’t. I fell in the latter camp, and it seems the reason is because I have my own version of a user creation system (not yet ready for public consumption).

I have verified that the InstaUser in svn does indeed have this problem, and have put in the request to the other developers that this be fixed. I can’t do so because InstaUser uses PackageMaker, and the version I have on all my computers (the latest from Apple) is broken, and I would do more harm than good by touching it. So hopefully we will have that fixed soon in svn, and maybe Josh will decide to put out another beta to cover that.

[Chris George]

Ok, NOW I got the kernel panic described in the first post.

With both, the target was an iMac 20″ 2.66. The difference is that the working image was built ON an iMac, while the non-working image was built on an Xserve. Both used the same base DVD, the OEM install DVDs from the aluminum iMac 20″.

[rfitzwater]

[QUOTE][u]Quote by: Chris+George[/u][p]Ok, NOW I got the kernel panic described in the first post.

With both, the target was an iMac 20″ 2.66. The difference is that the working image was built ON an iMac, while the non-working image was built on an Xserve. Both used the same base DVD, the OEM install DVDs from the aluminum iMac 20″.[/p][/QUOTE]

Chris, did you try building with the latest revision? Does holding the shift key down at first boot clear the kernel panic? These things resolved the kernel panics I was getting.

-Rhon

[Chris George]

[QUOTE][u]Quote by: rfitzwater[/u][p][QUOTE][u]Quote by: Chris+George[/u][p]Ok, NOW I got the kernel panic described in the first post.

With both, the target was an iMac 20″ 2.66. The difference is that the working image was built ON an iMac, while the non-working image was built on an Xserve. Both used the same base DVD, the OEM install DVDs from the aluminum iMac 20″.[/p][/QUOTE]

Chris, did you try building with the latest revision? Does holding the shift key down at first boot clear the kernel panic? These things resolved the kernel panics I was getting.

-Rhon[/p][/QUOTE]

This was done with the 1.4b3 that is posted here on AFP548. I didn’t try pulling any later builds from any other site, if there are any.

Shift key seemed to prevent the kernel panic, but the system never completed booting.

[rfitzwater]

[QUOTE][u]Quote by: Chris+George[/u][p][QUOTE][u]Quote by: rfitzwater[/u][p][QUOTE][u]Quote by: Chris+George[/u][p]Ok, NOW I got the kernel panic described in the first post.

With both, the target was an iMac 20″ 2.66. The difference is that the working image was built ON an iMac, while the non-working image was built on an Xserve. Both used the same base DVD, the OEM install DVDs from the aluminum iMac 20″.[/p][/QUOTE]

Chris, did you try building with the latest revision? Does holding the shift key down at first boot clear the kernel panic? These things resolved the kernel panics I was getting.

-Rhon[/p][/QUOTE]

This was done with the 1.4b3 that is posted here on AFP548. I didn’t try pulling any later builds from any other site, if there are any.

Shift key seemed to prevent the kernel panic, but the system never completed booting.[/p][/QUOTE]

Thats odd. My kernel panic was tied to the Extensions.mkext cache file. Booting in safe mode rebuilds this file, as well as others, thus resolving the kernel panic permanently. The latest internal builds of InstaDMG contain code that deletes these cache files before compressing the image file.

If you do get the machine to boot, can you test to see if you have any problems with Disk Utility (verify disk, repair perms, etc.). As this is the current problem I am experiencing. I am interested if anyone else building their images with 1.4b3 is getting the same results.

Please keep us posted of any new developments.

[larkost]

I would like to note that I would guess that the majority of the dev team are always using the retail 10.5.0 DVD to install from, and then using “Combo” updates downloaded over the web from Apple’s site (if you want the exact list I am using look at the vanilla catalog in InstaUp2Date).

Using a model-specific DVD should work in principal, but none of us are testing it.

The reasoning behind this is that the teams at Apple that put together the model-specific DVDs are completely different than the team that puts together the “retail” DVDs. The latter team is focused on making sure that things work on as many different models as possible, whereas the former teams are only responsible for making sure that that version works on one revision of a specific model of hardware. This can lead to things like missing kexts… things that would cause problems exactly like the things described here.

Can those who are experiencing the problem fill us in on the Base DVD that they are using?

And I am not going to lay any bets on things built on an XServe probably running MacOS X Server…. That is really far from what I am testing… and I am the one tossing code in at the moment.

[Chris George]

Well, I started using the retail and combo updater build process, but I was running into really really weird issues. ASR would fail to apply an image over the top of a machine that had such an image on it (“Could not erase target error”), and Disk Utility would refuse to even erase such a drive.

After consulting on Bombich’s forum (because I was using NetRestore to deploy the image) I was soundly scolded for using a retail DVD on a machine that shipped with 10.5.2, and pointed to Apple’s [url=http://support.apple.com/kb/HT2186?viewlocale=en_US]tech note[/url] explicitly advising AGAINST using a build of the OS earlier than what ships with the machine. Since I switched from using a retail build to a machine specific build, I’ve eliminated these issues. (Keep in mind that our entire ‘fleet’ of machines are all the exact same machine, the 20″ Aluminum iMac 2.66 GHz, so building against a machine specific DVD has very little risk for us.)

While I understand that in concept, the 10.5.4 combo updater should incorporate any changes that have been made previous, including any machine specific modifications, this doesn’t seem to be as true in practice. And when Apple is specifically instructing _against_ the exact course of action that you guys are recommending, that troubles me some.

[larkost]

Both the scolder and the technote are not reflecting the process in InstaDMG. Both of them are assuming that you are installing straight onto the computer, and in that case they are correct that you should not start with the 10.5.0 retail DVD. However, InstaDMG essentially synthesizes a 10.5.X retail DVD, and gets around all of these problems.

The people who are advocating that also don’t realize that that method is only really going to work for the exact hardware you are working on. It will usually work on other hardware, but you are going to be in for the occasional glitch (that are really hard to figure out).

So for InstaDMG it is a better path to use the retail DVD (less stick situations) and all of the combo updates.

Of course all of this is predicated on the idea that there is a Combo Update that is newer than the hardware you are installing on. At the moment 10.5.4 is newer than all the hardware out there, but when the next new piece of hardware ships there will be a window where that is not true, and people wanting an InstaDMG build for those computers will be out on a limb for a little while.

And the ASR issues can’t have anything to do with what DVD you used. An ASR restore just slaps the bits down on the disk, it does not try to evaluate them (not strictly true… but close enough in this case). And the “could not erase target error” has nothing to do with the source, that is a target error. Usually it means that something has some file on the disk open.

[Author]

Posts