Four days ago I blogged about the LZVN packed Apple Logo’s but I forgot to mention the four LZVN packed Panic Dialog images that I found. Two for normal mode, and two for HiDPI Mode. There are also four Colour LookUp Tables (Clut). All data will be made available in an updated version of PanicDialogData.h. This way everyone can use it.
Update
Finding the data was only the start, because it took two days more to add the missing LZVN panic dialog images for BLACKMODE and to replace the LZSS data with the new LZVN data. After this I modified RevoBoot to let it show the panic dialog instead of the Apple logo. This helped me to visually verify all four images and corresponding CLUT data. Everything looked fine so: mission accomplished.
Pike's Universum 
Feedback: I’ve tested the ‘LZVN for all’ version. Compiled in Release mode with a ‘Clean up’ before ‘Build’.
The Boot.efi boots on my MBP2,2 with a white Apple logo on black background for 10.8.5 ML as well as 10.9.0 Mavericks – no spinning pinwheel, but when the pointer appears, it changes to a dark grey Apple logo on a grey background. Yosemite boots normal with a white Apple logo on black background and a white progress bar.
Interestingly, in the previous ‘ProgressBarFix’ booted 10.8.5 ML with a grey logo – but 10.9.0 Mavericks with white/black.
I’ve tested now Sheep’s latest version with legacy grey mode on my MBP2,2.
Dark grey Apple logo on grey background for 10.8.5 ML as well as 10.9.0 Mavericks, dark grey spinning pinwheel – the usual look.
Yosemite: dark grey Apple logo on grey background and a white progress bar – but only the 1st quarter of the boot, then it changes to a black progress bar.
The grey boot screen is btw not ‘legacy’. My Mac mini 6,1 as well as a supported MacBook Pro from a other Macrumors member boots the official Yosemite in grey too.
Pike, sorry to bother you, but some users that have installed Little Snitch 3.4.1 on their old Mac Pros are reporting boot problems (continuous reboots?) on the Macrumors forums with the latest commit of your boot.efi in Mavericks and/or Yosemite. Can you please shed some light into this issue? This might be a hard one to crack. I’d be willing to be your guinea pig in about 24 hours, in case you feel you need to create a special build with trace information. First, I would need to update to LS 3.4.1 myself and reboot my computer, of course. Let me know if something can be done.
Hi Peter,
Interesting. So this reboot problem wasn’t there with any of the previous (experiential) versions of boot.efi?
Does it reboot with Mavericks and the latest boot.efi?
The untouched versions from Tiamo still work with Mavericks?
Edit:
A lot has changed in Yosemite. For example. The kernel name and path to the kernel file have changed and thus boot.efi now expects to find:
/System/Library/Kernels/kernel
This instead of: /mach_kernel
Maybe that is the problem. I’m not sure, but try one of these:
1.) Copy /mach_kernel to /System/Library/Kernels/kernel
2.) Add
to com.apple.Boot.plist
Does that stops the reboot?
I don’t have a first-hand knowledge of any of these issues, as I haven’t updated to LS 3.4.1 yet and am still in Mavericks. At Macrumors.com at least one user has stated that the new boot.efi abnormal behaviour is only observable under Mavaricks (with LS 3.4.1, of course) and Tiamo’s boot.efi restores normal boot. Another user, however, has stated that the continuous boot is ALSO observable in Yosemite. In addition, it is observable in ALL of your commits, so that means it is unrelated to LZVN, etc. I’m beginning to think it may be a quirk of VS 2013. I’m going to try it to compile with an older version of Visual Studio and report back if I succeed, unless you have a better idea.
I can’t find anything that can cause this problem with LS v3.4.1, but if it is some quirk in VS 2013 then compiling Tiamo’s boot.efi should result in the same reboot loop. And then why only with v3.4.1 because I am told that v3.4 boot fine. Or is this info incorrect as well?
Edit: I checked the kext of Little Snitch v3.4.1 and found this:
In other words. It reads the first 1024 bytes from the /mach_kernel, which shouldn’t be there in Yosemite so I wonder if people who still have that file there in Yosemite, if that triggers the reboots. Or perhaps that not having the file there causes the reboot problem. Might be a good idea to verify this.
I still have LS 3.4.0, but I haven’t installed the new boot.efi. It appears the Macrumors forum members with LS 3.4.0 and Mavericks or Yosemite haven’t experienced any problems with new boot.efi on their early Mac Pros. In addition, someone reported that LS 3.4.1 in Yosemite with the new boot.efi was just fine on an old iMac! So, the situation is rather confusing, I would say. I’ve compiled your latest commit in debug/Win32 configuration to test it with LS 3.4.1 in Mavericks (I plan to do that tonight on my Mac Pro) and/or Yosemite with LS 3.4.1. So far, nobody has reported either failure or success. If that were to work, we might have solved the riddle. Otherwise, as you say, the next step would be to compile Tiamo’s boot.efi in VS 2013 and see if it exhibits the continuous reboot problem.
Hi Pike,
It is not a matter of LS working or not with Mavericks and Yosemite, LS works with Mavericks or Yosemite, the issue is only when updating LS.
Yosemite was running with Chameleon bootloader before Pike’s boot, it was easy to install LS and even to update later.
So when Yosemite was running with Chameleon boot i did install 3.4, as soon as Pike’s boot was available i stopped using Chameleon.
Then 3.4.1 has been made available, i made a try and got a permanent reboot, but, because there is a but ! under Mavericks and Tiamo’s boot it was exactly the same issue with others LS Versions.
If you have Yosemite installed running with Chameleon boot that means with Apple original boot.efi you can install, update, everything works 100%.
Sadly, I cannot verify that. I’ve just update my Mavericks install with Little Snitch 3.4.1, leaving Tiamo’s boot.efi in place. No reboot. Everything works as it should.
The latest consensus opinion seems to be that this entire episode was due to the corruption of boot.efi (either Tiamo’s or Pike’s or perhaps even Apple’s) caused by a faulty Little Snitch installer, which somehow damaged the boot loader both in Mavericks and Yosemite. Two people have now confirmed that using the right Little Snitch 3.4.1 installer doesn’t cause any problems with Tiamo’s boot.efi in Mavericks or with Pike’s boot.efi in Yosemite.
The “consensus opinion” seems to have been finally confirmed. The whole boot failure scenario was caused by some faulty installer or procedure. Sorry for unwittingly having contributed to this unnecessary confusion. There’s nothing wrong with your boot.efi, and it is fully compatible with Little Snitch.
Ok. I presume that you guys checked the checksum of boot.efi before and after the update to LS 3.4.1 to be certain that the installer was the culprit?
Just for references.
Chameleon, Chimera and RevoBoot all emulate the EFI, and only a small part of it. It won’t ever load boot.efi and calls like runtimeServices64->ResetSystem cannot reset a system. This because there is only a c3 (ret) instruction. Nothing more.
Also. Both Chameleon and Chimera won’t even initialise stuff like bootArgs->Flags. Only RevoBoot does. By the way. This is where kBootArgsFlagRebootOnPanic is set, which you may not want to set when something goes bonkers. Then you may also want to add BOOT_MODE_VERBOSE to BlpBootMode in src/boot/Options.cpp
Not that it really matters anymore, because I see that the problem was caused by a bad installer. You guys figured it out already. Good work!
pike, we just saw that there’s a new commit (Recovery HD fix). nice to see that you’re still working on the new boot.efi! I just tried to build the latest source and I got lots of errors:
Error 1 error C3274: __finally without matching try C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\LoadKernel.cpp 601 1 boot
Error 2 error C2143: syntax error : missing ‘;’ before ‘{‘ C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\LoadKernel.cpp 602 1 boot
Error 3 error C2226: syntax error : unexpected type ‘EFI_STATUS’ C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\LoadKernel.cpp 620 1 boot
Error 4 error C2143: syntax error : missing ‘;’ before ‘{‘ C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\LoadKernel.cpp 621 1 boot
Error 5 error C2601: ‘LdrLoadRamDisk’ : local function definitions are illegal C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\LoadKernel.cpp 637 1 boot
Error 6 error C1075: end of file found before the left brace ‘{‘ at ‘LoadKernel.cpp(347)’ was matched C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\LoadKernel.cpp 674 1 boot
Thanks. Fixed.
Feedback Recovery HD: I’ve tried to compile the new version, but there are 7 errors with the LoadKernel.cpp, line 601 ‘__finally without try’, line 602 missing’;’, line 620 ‘EFI_Status not expected’, line 621 missing’;’, line 637 ‘LdrLoadRamDisk function definition improper’, line 347 ‘{ without equivalent’, ‘ line 674 end of file reached without ‘{‘ .
Ok thanks. Should be fine now.
yup, after fixing the fix, it compiled without any errors. when I try to boot the Recovery HD with this new boot.efi I’m getting a KP -> https://farm6.staticflickr.com/5602/15356910159_b70048813f_o.jpg
I switched on verbose boot mode, for testing, and added a couple of dumps (PIKE: Kernel cache located!) which should be seen, otherwise it is not working.
it’s not compiling: Error 1 error C2065: ‘BOOT_VERBOSE_MODE’ : undeclared identifier C:\Users\mikeboss\Desktop\macosxbootloader-master\src\boot\Options.cpp 13 1 boot
Sorry. Mixed stuff with that of a different boot loader.
ok now. tried to boot the recovery and the screen flashes black, with five rows containing the same message. looks like “Kernel Cache Located” or something similar. couldn’t capture it with the iPhone’s camera…
Feedback Boot_Verbose: Compiling was ok. Boots the patched Installer (5 times PIKE: Kernel cache located), doesn’t boot the installed Yosemite (10 times PIKE: Kernel cache located, hangs with a underscore then), doesn’t boot ML as well as Mavericks.
the message appears only for the fraction of a second, filmed it in Slo-Mo with the iPhone. the error says “PIKE: Kernel cache located!”.
Ok. New debug strings added so that we can determine if the kernelcache is being invalidated by the call to LdrpKernelCacheValid()
You probably see this: “PIKE: Kernel cache NOT valid!” but that should become: “PIKE: Kernel cache is valid!” if that is true.
compiled fine. booting the Recovery HD gives the same error: “PIKE: Kernel cache located!”.
commit ccd7c25dfa still gives “PIKE: Kernel cache located!”.
Hmm. Then it bails out even earlier as I thought. New debug strings, plus the (i) added, so that we can see what it finds.
Compiler produces this output with commit a5ccc33fa7:
Error 1 error C2220: warning treated as error – no ‘object’ file generated C:\Users\PJH\Desktop\macosxbootloader-master a5ccc33fa7\src\boot\LoadKernel.cpp 435 1 boot
Warning 2 warning C4189: ‘kernelCacheValid’ : local variable is initialized but not referenced C:\Users\PJH\Desktop\macosxbootloader-master a5ccc33fa7\src\boot\LoadKernel.cpp 435 1 boot
Warning 3 warning C4505: ‘LdrpKernelCacheValid’ : unreferenced local function has been removed C:\Users\PJH\Desktop\macosxbootloader-master a5ccc33fa7\src\boot\LoadKernel.cpp 142 1 boot
Ok. Thanks. Variable and function taken out for a new experimental version (Recovery HD boot test).
It compiles fine. Now we’ll see what forum members with Recovery HD in place say.
This is the report received:
with this new build I’m getting
PIKE: Kernel cache located: 0 !
PIKE: Kernel cache located: 1 !
Ok, but does it boot?
with this new build I’m getting
PIKE: Kernel cache located: 0 !
PIKE: Kernel cache located: 1 !
Ok, but does it boot?
sorry, I was out of office. nope, Recovery HD is not booting. it hangs on the grey Apple logo after displaying the errors for the fraction of a second.