Is anyone experiencing continuous kernel panics? Even under Yosemite, as soon as I use the new boot.efi my Mac goes nuts..
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS boot.efi developer's thread
- Thread starter mikeboss
- Start date
- Sort by reaction score
Try to do this:
Restart the computer and press Cmd-R when you hear the chime. That way, you'll be booting the Recovery HD. Now, go to Terminal. Assuming your El Capitan disk/partition's name is "Macintosh HD", enter
touch /Volumes/Macintosh\ HD/System/Library/Extensions/*.*
Reboot. That instruction will force OS X to ignore the kernel cache, which is probably corrupted. You may have a legacy incompatible kext that interferes with SIP.
The above advice would apply for El Capitan, but I have no idea as to why you would have problems in Yosemite.
o.k., so I created a new legacy installer by starting with a clean copy of Install El Cap.app
imaged BaseSystem.dmg, deleted the S/I/Packages symlink, copied the complete Packages folder over to said, copied BaseSystem.dmg and BaseSystem.chunklist to /, extracted the kernel to S/L/Kernels, and replaced the three .efi with that compiled from commit b744c92e
I did not modify any .plist, nor did I mod the Distribution located in S/I/P/OSInstall.mpkg
Same results as before: "Waiting for DSMOS" (attached output was one minute prior to the "Waiting for DSMOS" hang/stop point).
It seems to be the AirPort card, but I just don't have the attention span to remove it, now, to see.
imaged BaseSystem.dmg, deleted the S/I/Packages symlink, copied the complete Packages folder over to said, copied BaseSystem.dmg and BaseSystem.chunklist to /, extracted the kernel to S/L/Kernels, and replaced the three .efi with that compiled from commit b744c92e
I did not modify any .plist, nor did I mod the Distribution located in S/I/P/OSInstall.mpkg
Same results as before: "Waiting for DSMOS" (attached output was one minute prior to the "Waiting for DSMOS" hang/stop point).
It seems to be the AirPort card, but I just don't have the attention span to remove it, now, to see.
Attachments
The way I see it, Pike oughtn't to look for a "solution" to support this so-called "legacy" installer solution, which may well have been devised by Tiamo himself. Since Pike's version 3.0 boot.efi supports the Apple-blessed createinstallmedia solution, that's the method we should promote. Support for the legacy install method (which, by the way, is the one I used myself) should be discontinued.
I agree.
Just wanted to report my results, as many are using that to install.
btw, I finished the d/l of El Cap in Mavericks earlier this morning, and it did allow me to start the install process. Yose and El Cap are letting me d/l, but are giving me fits actually getting the .app . . . haven't really tried or sussed the cause. Later, of course.
Pike:
I am thinking that, in Line 459 of LoadKernel.cpp
\\Prelinkedkernels\\
should be
\\PrelinkedKernels\\
Just noticed my mis-type in another thread after imaging the new BaseSystem.dmg (and reviewing edits).
...just tried a build with said change, and the legacy installer still hangs at the same point "Waiting for DSMOS..."
I am thinking that, in Line 459 of LoadKernel.cpp
\\Prelinkedkernels\\
should be
\\PrelinkedKernels\\
Just noticed my mis-type in another thread after imaging the new BaseSystem.dmg (and reviewing edits).
...just tried a build with said change, and the legacy installer still hangs at the same point "Waiting for DSMOS..."
Thank you Peter but unfortunately this doesn't solve my problem.
Forgot to mention that that was a clean installation made on my supported rMBP.
I don't know, maybe there's something about my configuration that the new boot.efi doesn't like?
I'll try the 2.1 without the board-id replacement and report, that's the only thing I can think of..
EDIT: 2.1 panics too, but after a lot of time, compared to 3.0
Last edited:
Fixed. Thanks!
@PeterHolbrook,
Here are the releases that we used so far https://github.com/Piker-Alpha/macosxbootloader/releases
@bubez,
Try boot argument: -pmap_pagetable_corruption_deassert and if that doesn't help then recompile for Yosemite (see line 17 in StdAfx.h) and then use that for your Yosemite installations.
p.s. Add a (link to) the output of kextstat
Also. Since the KP list akd – AppleWatch/iPhone simulator related framework daemon – as the current thread, what version of Xcode do you have installed?
@splifingate,
Disable all debug output and verbose mode to see if that helps. Did you try to boot with either -x or -f (even without -v).
Last edited:
Booting with -f didn't help, the /S/L/K/kernel and /S/L/P/prelinkedkernel are there. I diff'ed the kernel from live system, Pacifist extract and LZVN extract: they are identical.
The problem I see with this method is that it alters the install media half way and you'll have to replace boot.efi in multiple places multiple times during the install. That's not what I have in mind for super smooth experience. That would be to start the install, go away, come back some time later and see the welcome screen of post install configuration.
Thank you guys, will try next weekend.
Pike, FYI, each kernel panic has a different active process, and right now I've only installed El Cap and Server.app.
On the other HDD, (Yosemite) I compiled and used the latest commit of the master branch with no issues.
Now I've launched memtest with max n of cycles.. Maybe some of my RAM isn't perfect..
Hmm. I don't quite follow. A friend has just lent me a small HDD that I've erased to create new bootable install media for El Capitan. Assuming your installer application is in /Applications and that your target disk has the name "Untitled", all you need to enter is:
sudo /Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/Untitled --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app --nointeraction
It will prompt you for your administrative password. It takes two o three minutes to make the new installer. Then all you need to do on that disk, I think, is, go to the following hidden folders and replace the stock boot.efi with Pike's version of it:
/System/Library/CoreServices
/usr/standalone/i386
/.IABootFiles
That should be it. I haven't tried to run it myself. It will be days or even weeks before I can try, but that disk should boot normally on an old Mac Pro and it would be able to install El Capitan on it. Admittedly, you still have to replace boot.efi, on the El Capitan target disk, in /System/Library/CoreServices and /usr/standalone/i386, but that should be all that needs to be done.
Well. So far we have been focussing on the boot.efi file, and you now only need one copy for all locations (with installer detection). We also have SIP under control (with RecoveryOS support and NVRAM read/write support) and the download of the El Capitan app from the App Store is smooth as it can get (with board-id replacement).
I also have a new launch daemon to copy our version of boot.efi to /.IABootFiles and/or /OS X Install Data so that you don't have to replace boot.efi in /.IABootFiles before the first reboot. That certainly helps, but yeah we're not done, and don't have a working solution for the other installation stages.
But don't forget. This is all new, and Apple certainly did everything to make their installation processes as smooth as butter, but we're not Apple. Luckily we also not worked a year on a new update (from Yosemite) so I think that with the current state, things are looking really good. Not as smooth as on supported hardware, but we keep trying to find a solution for this last piece of the puzzle and hope to find one in due time.
Unfortunately you'll have to replace boot.efi in /.IABootFiles after the first stage of the install process.
I tried to remove my Airport card, but one screw sits so tight I'd have to remove the mainboard to get it loose and while I haven't done that in a while and could use some practice, I won't do that.
Is there another way, maybe 'unmount' the airport card from the device tree early in the process?
That sounds promising! I somehow missed that this was on the agenda.
I'm aware that it's only up to you how far this journey goes. I appreciate what you've done so far, and could totally understand if you say thats enough for now.
My intention is, and has always been, to finish what I started. No matter how long it takes.
Edit: I ran createinstallmedia and noticed that next to: /System/Library/Kernels/kernel also /System/Library/PrelinkedKernels/prelinkedkernel is missing. That may, in certain conditions, be a problem.
Last edited:
Changing the board-id in the boot.efi file changes the "Hardware UUID" as I expected, but what i did not expect is that the new "Hardware UUID" is already in use by another user's system, as i was unable to activate some software for this reason, as the "Hardware UUID" was being used for unique system identification by the developer, as I believe Apple recommend. The "Hardware UUID" is also used by Apple for various system identification purposes that conceivably could be a serious problem... It might be an idea to make a boot.efi release available without changing the board-id and hence the "Hardware UUID", as I believe the only purpose of this change of board-id is to enable initial installation through the App Store?
No. The board-id is not involved. What you are seeing is the result of the addition of the 'system-id' property, which was missing in all versions of Tiamo's copies of boot.efi, and the one I made for Yosemite. This change changed the IOPlatformUUID aka Hardware UUID in the System Profiler, but now it is exactly like Apple is doing in their versions of boot.efi
You can check this by booting into Yosemite and witness a load of zero's before your MAC address (because that is basically what you had back in the days).
Thanks for the quick reply and clarification. I am actually still booting in Yosemite, using your boot.efi for Yosemite again, as the clash of "Hardware UUID"s was a problem: i was only preparing to install El Capitan. Yes, my original "Hardware UUID" does contain all the zero's as you say.
Does the addition of the system-id property in your boot.efi file create many collisions in the "in principle" unique IOPlatformUUID or am I just extremely unlucky?
Do we know the exact procedure that Apple will follow to replace El Capitan's stock boot.efi when a future System Update includes the boot loader? I mean, with SIP in place, how exactly will Apple achieve the replacement? The next question, logically, is: Can such a procedure, whatever it is, be easily emulated by Pike's boot.efi, ensuring its persistence across boots?
I'm afraid that is a yes. The latter that is.
@PeterHolbrook,
Yup. We have that covered with installer detection (basically doing the same as what Apples boot base.efi is doing/disable SIP for the installation).
If I understand correctly, your boot.efi emulates Apple's procedure so well, that it will destroy itself by copying a newer version of Apple's stock boot.efi if one is provided in a System Update. What can be done so that, if that replacement were to occur, your boot.efi, before been obliterated from memory, would survive the update by copying itself over Apple's newly copied version?
My version of boot.efi emulates what Apple's bootbase.efi does i.e. it disables SIP for the installation process, which is automatically detected, so you only have to use one and the same file. And the HFS driver in the EFI firmware has read-only support, but the HFS driver loaded by the OS (kernel) has read/write capabilities, so we could, in theory at least, restore boot.efi from memory. However. As far as I know, nobody ever did this.