(Solved) EXITBS:START reboot with OpenCore on legacy Arrandale notebook - can't boot the installer

[AsD Monio]

Hello,

 

I'm new to Hackintoshing and I'm trying to put together my first hack. It's been fun so far, I've managed to boot the installer on my desktop but on my laptop I can't get past the boot.efi handoff stage (#[EB|LOG:EXITBS:START] / EndRandomSeed), so I would like to ask for a little help.

 

Specs:

HP G62 Notebook PC (G62-b10sw)

CPU: Intel Core i7-640M (Arrandale)

GPU: integrated, Intel Ironlake

RAM: 2x4GB

storage: ADATA SX930 120GB SATA SSD

booting from a USB 16GB pendrive

 

I'm currently trying to boot the Monterey installer but I've tried different versions all the way down to High Sierra, which, as far as I know, should definitely run on this hardware. My issue is a little different than any other case I could find when searching about this - the machine does not get stuck at EXITBS:START, but instead reboots, despite debug=0x100 being present in the boot-args.

 

I'm using OpenCore in legacy mode as this computer does not have UEFI. The guide I've followed is the Dortania OpenCore guide, using Windows to create the installer USB, and more specifically the Arrandale Laptop config.plist setup guide. I've remade the EFI a few times and kept it minimal (no kexts for network cards, no UEFI drivers and kexts for touchpad, etc.) as the goal, for now, is just to boot the installer.

Some notes / deviations from the guide:

• I've tried both the Windows (booting directly from the recovery dmg) and Linux (extracting the HFS+ partition from the recovery dmg and putting it on a partition on the pendrive) USB creation methods, both with the same result, so I stuck with booting from the dmg
• ACPI:
  • Skipped SSDT-EC - after dumping and decompiling the stock DSDT, it turns out the embedded controller device was already named "EC"
  • Added SSDT-HPET - generated using SSDTTime on Windows as suggested in the Getting Started With ACPI part of the guide, added the patch section to the config.plist
• Booter -> Quirks: Enabled AvoidRuntimeDefrag as recommended for Big Sur and up
• Kernel -> Quirks:

  • Enabled AppleCpuPmCfgLock and AppleXcpmCfgLock - just in case since I'm having problems - OpenCore says the CFG lock is not present, so I will want to turn those off in the future

  • Enabled LapicKernelPanic since I'm using an HP motherboard

  • Enabled DisableIoMapper - there is no option in the BIOS to disable Vt-d and I'm not certain whether it's enabled or not after reading Linux kernel logs

  • Disabled XhciPortLimit - I mapped the USB ports in Windows instead, using USBToolBox, and added its kexts

• Added -no_compat_check to boot-args instead of changing the SMBIOS - tried both with no change, both work to get past the unsupported error
• UEFI -> Drivers:
  • Used OpenHfsPlus.efi instead of HfsPlusLegacy.efi - After extracting the recovery partition from the dmg (Linux USB creation method in the guide) it did not show up in the boot picker when using HfsPlusLegacy
• Uefi -> Quirks: Enabled UnblockFsConnect - as recommended by the guide, since I'm using an HP motherboard
• Keyboard: I got a liitle confused by the guide only suggesting to enable UEFI -> Input -> KeySupport on computers with UEFI. In the end, the internal keyboard ended up working with KeySupport enabled and the Ps2KeyboardDxe.efi driver loaded. OpenUsbKbDxe.efi ended up not being required, so I left it out.

 

The config.plist validates with no issues using ocvalidate. I've already tried everything from the troubleshooting section of the guide (though probably not every combination), some other quirks from the guide (like DevirtualiseMmio) and many various odd things I could find online - with no change. I'm attaching the EFI with PlatformInfo removed as well as the OpenCore debug boot log. I would appreciate any pointers 🙂

EFI.zip opencore-2022-02-09-194115.txt

Edited February 20, 2022 by AsD Monio

[AsD Monio]

@Hervé Thanks for your reply, I've just tried re-making the USB using MBR, but sadly nothing has changed.

 

My G62 is currently running a dualboot of Linux and Windows on GPT, with GRUB being the main bootloader - so, I have a GRUB "BIOS boot" partition in addition to an ESP. What's interesting is that I have had trouble getting Windows to boot. Normally it's possible to load the legacy bootmgr from GRUB, but when I tried it, I got a reboot. Eventually, I got it to work by creating an MBR-partitioned disk image, putting the Windows bootloader on it, then using the loopback command in GRUB to load the image and booting from that.

 

My guess is that bootmgr checks the partitioning scheme, or, more likely, searches for a partition containing something (The BCD? The active partition?) and the legacy version only has MBR support, while the EFI version only supports GPT. But now that you mentioned your G72, maybe GPT booting trouble could be a quirk of this product line? Though, I am also able to boot my Windows 11 install in EFI mode using OpenCore and, if I recall correctly, I booted Linux once too.

 

Here's what the USB looks like on most of my attempts:
 

Spoiler

The warning on partition #2 is about the filesystem being smaller than the parition - I didn't touch it after extracting it from the recovery dmg onto a much larger partition.

 

And, just in case, here is my MBR attempt:

Spoiler

 

I've also attached the OpenCore log booting from the MBR setup, though it looks the same as before at a glance.

opencore-2022-02-09-194115.txt

[AsD Monio]

Update: I tried booting with the factory memory configuration for this laptop - 1x2GB, and got some strange results.

Somewhere along the way I also realized I forgot to add the USBToolbox kexts, so I added them back - with no change.

 

When attempting to boot Big Sur and Monterey installers from the dmg I got this error, which seems to be rather rare:

AAPL: MH_FILESET detected, but MACH-o headers not present in LC_SEGMENT_64 commands.  Cannot continue.

I got dropped back to the boot picker after that. Here's the full boot log: opencore-2022-02-13-190639.txt. The error sounds like maybe the dmg contents are corrupted but both of them booted right up on my desktop. Maybe they're getting corrupted in memory, or simply cannot fit into 2GB of RAM?

 

Trying to boot the extracted partition ("Method #2", Linux in the OpenCore guide), which required disabling SecureBootModel, had the same result as before - reboot after EXITBS:START.

 

I've also tried to boot the High Sierra installer, and that resulted in:

Couldn't allocate runtime area

So, I followed the guide's recommendation, Fixing KASLR slide values. The memory map had changed a lot after swapping the memory - that's probably to be expected. For the 2x4GB configuration, the slide value was 0, for 1x2GB, after a few mistakes (with the incorrect slide values simply causing the same memory allocation error), it ended up being 232. After adding slide=232 to the boot-args and enabling ProvideCustomSlide, once again, the machine rebooted at EXITBS:START. The slide value also resulted in no change trying to boot the Big Sur and Monterey installers (got either the MH_FILESET error or a reboot as described above).

[Slice]

Sorry you have 2Gb RAM? I think 10.7.5 is the last macOS for this.

[AsD Monio]

2 hours ago, Slice said:

Sorry you have 2Gb RAM? I think 10.7.5 is the last macOS for this.

Normally I'm using 8GB, I was just trying to boot with less to see if it would help. I just looked up the RAM requirements, and you are (mostly) right - 4GB is required since Catalina, according to Wikipedia - which explains the different error on Big Sur and Monterey. I just tried again with 4GB (in two configurations: 2x2GB and 1x4GB), and got the same reboot at EXITBS:START, both when booting from dmg and from a separate partition. So, I'll stick with my initial memory configuration of 2x4GB as it seems that it is not the problem and I'm back to square one.

[Baio77]

https://github.com/Baio1977/HP-630-CPU-Arrandale-Bios-Legacy- 

I have a similar PC, see if it improves by trying this EFI. You have to go through a procedure and convert the EFI partition of the USB to MBR. Otherwise it will never boot.

[AsD Monio]

@Hervé I have 8GB of RAM, in my earlier post I tried to boot using less, because 8GB is the maximum amount that my motherboard / CPU support, and I thought that maybe that was causing problems. I also have the same problem when trying to boot the High Sierra installer using 8GB of RAM - it reboots at EndRandomSeed.

 

@Baio77 Thanks for sharing your EFI. I re-partitioned my USB to MBR and tried booting using your EFI, but I ran into the same issue - rebooted at EXITBS:START.

 

I think I finally have some small progress. My attention was drawn to the "Print K and dead loop" patch from the sample OpenCore config. According to the comments in this OpenCore issue on GitHub, as far as I can understand, this patch can be used to see if the code execution in the macOS bootloader reaches that function or not and find exactly which function fails to work properly. In the mentioned issue the computer was getting stuck, so the "Early reboot" patch right next to it was used instead.

 

I've tried enabling this patch before, but it had no effect, which is strange - according to the comment, it should cause the computer to get stuck when we reach the _vstart function, which is very early in the boot process.

I read somewhere that _vstart gets called from _pstart, so I tried setting the Base of the patch to _pstart. This also didn't have any effect, until I added the slide value to the boot args and enabled ProvideCustomSlide - then, with the patch enabled, I finally got stuck at EXITBS:START, instead of rebooting.

 

So, unless something else related to the slide value is wrong, this means that _pstart is what fails on my machine, since _pstart calls _vstart, and patching the latter to hang does not result in a hang.

[shl628]

If you have the following items in BIOS setup, set it to Enabled.
- Execute Disable Bit (EDB)
- NX ( No eXecute ) Memory Protection
- XD Execute Disable Bit
- Data Execution Protection
- Memory Execution Protection

 

If the above item is set to Disabled in BIOS settings, Darwin/XNU Kernel fails to load and the system immediately reboots.

[AsD Monio]

Well, I feel pretty dumb. Resetting the BIOS fixed it. I hadn't tried it because I had already unplugged the CMOS battery fairly recently, when swapping some parts (CPU, RAM and SSD).

 

What led to this is: I found out that the G62's BIOS is actually an EFI 😄 It is very locked down and all EFI booting options are disabled, leaving only legacy boot available. The "system diagnostics" startup menu option has two implementations. A simple one, which is built into the BIOS. And a more advanced, graphical mode one (with even a working touchpad!), which can be installed from a "driver update"-like package ("HP System Diagnostics UEFI"). It simply creates a FAT32 partition (or renames an existing one) to "HP_TOOLS" and copies over some EFI executables.

 

I even managed to boot OpenCore directly by replacing the system diagnostics executable that the BIOS looks for (\Hewlett-Packard\SystemDiags\SystemDiags.efi). But it's not really feasible to keep booting this way, both because it replaces the real diagnostics function and because it requires getting into the startup menu on every boot.

 

On 2/19/2022 at 12:34 AM, shl628 said:

If you have the following items in BIOS setup, set it to Enabled.
- Execute Disable Bit (EDB)
- NX ( No eXecute ) Memory Protection
- XD Execute Disable Bit
- Data Execution Protection
- Memory Execution Protection

 

If the above item is set to Disabled in BIOS settings, Darwin/XNU Kernel fails to load and the system immediately reboots.

 No such option in my BIOS, and NX is definitely enabled - it's present in /proc/cpuflags on Linux. You were the closest to the solution, though - the culprit was BIOS-related after all 🙂

 

This BIOS is an Insyde H2O, version F.48 - the latest, and has very few options, the only useful one (for OpenCore) is "Virtualization technology". So I thought I could use the modified GRUB shell with the setup_var command to change some hidden settings. I've cracked open the BIOS file from an update package, to decrypt it (BIOS modding forums mention RSA) I had to use a... SLIC injection tool, which I think is better not named, as its primary use is Windows piracy - I could not find any other tool to decrypt the BIOS. I then followed this guide (point E6.) in order to extract the variable offsets, which can be passed as parameters to setup_var, in my case I had to extract the PE32 image section of DriverSampleDxe / SetupUtility.

 

I tried enabling UEFI Boot, but that made me unable to boot both: EFI files, using the system diagnostics method (caused graphical glitches and a system hang) and legacy bootloaders - which failed with memory allocation errors. So, not being able to boot the GRUB shell to change this back, I reset the settings from within the BIOS setup. After that, the Monterey installer booted right up using OpenCore with legacy booting (I kept the slide value boot arg). I'm worried about this issue coming back randomly and requiring another BIOS settings reset, so I might try disabling "Fast boot" or a few other settings, like VT-d, which I had no hopes of disabling - it is present in the variable list!

 

On 2/18/2022 at 8:18 PM, Hervé said:

Maybe you should consider Clover instead of OpenCore

I should have mentioned in my first post: I had already made a (probably not very good) Clover EFI, and had the same problem with it. I kind of forgot about it and went back to troubleshooting the OpenCore one for a while before finally posting (I started learning and working on an EFI last October).

On 2/18/2022 at 8:18 PM, Hervé said:

OC has no support for Arrandale CPU power management, unlike Clover (Generate P-States, Generate C-States).

Thank you for sharing this, I didn't know that. I might need to switch then, though I've seen one or two EFIs for Arrandale laptops and at least one claimed working power management in the README. So, I'll probably give it a try on OpenCore first and switch to Clover if needed.

 

Thanks to everyone for getting involved 🙂

[1Revenger1]

https://github.com/Piker-Alpha/ssdtPRGen.sh

Probably used something like ssdtPRGen to generate an SSDT with power management vectors.

[1Revenger1]

https://github.com/Piker-Alpha/ssdtPRGen.sh/blob/Beta/Data/User Defined.cfg

Looks like you can add your own data for various CPUs. There's examples here for first gen cpus here. Probably can set most of those values as command arguments as well.
It's definitely not as easy as using Clover's automatic features though.

[Евгений Евтушенко]

I have a similar hardware and I successfully install BigSur, I can send my efi, try it. although I do not see the point in this, very weak hardware, there will be permanent brakes. Install Mojave and relax

[deeveedee]

Looks like you are making progress.  This thread might help.  I have always found that Arrandale power management works fine without any extra SSDTs or configs as long as LPCB is spoofed to one supported by macOS.  I did try ssdtPRGen, but it didn't help (and actually made performance worse in my case).  Performance on Arrandale with 8GB RAM and SSD is impressive for such an old platform.