Jump to content
mickeyd453

OpenCore 0.6.2 - Legacy Boot Problem

74 posts in this topic

Recommended Posts

I run an 'Old' Optiplex 980 as my main desktop rig and have until this point used Clover as the boot loader. As I look to move to BigSur I am looking to move to Open Core but am facing a problem even booting the OC loader. 

 

I have followed the legacy boot guide to the 'T' and not encountered any errors but as soon as I actually try to boot OC I am faced with the attached screenshot. This is very early in the boot process so any hints would be great. I have searched lots and notice a number of people report the same issue but I don't seem to be able to land on a solution.

 

An pointers?

IMG_3759.HEIC

Edited by mickeyd453
Forgot point point release from topic title
Share this post

thanks for the reply - I did that first, encountered the same issue. I also installed onto an SSD as I had read about USB issues but same result as before.

 

Very stumped as this should work fine.

 

Could you do an md5sum on your 'boot' binary please so I can see how it compares to the one that I have created during the legacyinstall process.

Screenshot 2020-10-10 at 13.25.38.png

Edited by mickeyd453
Edited to add screenshot of legacy install
Share this post

15 minutes ago, 1Revenger1 said:

Update your OpenCore - your pairing an old version of OC with a newer config.plist, and the newer OCs have better support for older hardware anyways.

 

I am running the latest - re-downloaded today. I now realise my post title should read 0.6.2 not 0.6

Share this post

6 minutes ago, mickeyd453 said:

 

I am running the latest - re-downloaded today. I now realise my post title should read 0.6.2 not 0.6

The errors above suggest otherwise - ApECID, SecureBootModel, and Arch were all added very recently with OC 0.6.1 iirc. I checked your config.plist, and they all look like they are at the proper place

Edit: I'd suggest checking to make sure your editing the right EFI, especially if you have multiple backups/copies that your messing with.

Edited by 1Revenger1
Share this post

16 hours ago, 1Revenger1 said:

The errors above suggest otherwise - ApECID, SecureBootModel, and Arch were all added very recently with OC 0.6.1 iirc. I checked your config.plist, and they all look like they are at the proper place

Edit: I'd suggest checking to make sure your editing the right EFI, especially if you have multiple backups/copies that your messing with.

 

Thanks for the help - I am definitely editing the right EFI and I have in fact got further. I solved that previous issue by swapping out HfsPlus.efi with HfsPlusLegacy.efi and I can now get the picker menu. I now have a different issue. 

 

When booting the installer I don't have any USB support and looking at the panic I don't seem to have kexts loading correctly. Is there a specific order in which kexts should be loaded? I have attached a screenshot of where the errors begin and also my current config.plist for comparison. Its as though something is stopping the kexts loading?

 

thanks

 

 

IMG_3783.jpg

config.plist

Share this post

4 hours ago, mickeyd453 said:

 

Thanks for the help - I am definitely editing the right EFI and I have in fact got further. I solved that previous issue by swapping out HfsPlus.efi with HfsPlusLegacy.efi and I can now get the picker menu. I now have a different issue. 

Oh, that'd do it. Sorry, I should've caught that earlier.

4 hours ago, mickeyd453 said:

When booting the installer I don't have any USB support and looking at the panic I don't seem to have kexts loading correctly. Is there a specific order in which kexts should be loaded? I have attached a screenshot of where the errors begin and also my current config.plist for comparison. Its as though something is stopping the kexts loading?

 

thanks

 

 

IMG_3783.jpg

config.plist

For USB Support - I don't see anything in the log above which would cause issues with USB. It is weird that WhateverGreen is erroring out, but if you don't need it, then it's fine I guess?
I'd try enabling Kernel->Quirks->XhciPortLimit. If it still isn't working - I'd check ACPI and make sure that USB isn't being disabled with an _OSI/OSYS check. Failing that, make sure that IRQ is patched.

Share this post

16 hours ago, 1Revenger1 said:

For USB Support - I don't see anything in the log above which would cause issues with USB. It is weird that WhateverGreen is erroring out, but if you don't need it, then it's fine I guess?
I'd try enabling Kernel->Quirks->XhciPortLimit. If it still isn't working - I'd check ACPI and make sure that USB isn't being disabled with an _OSI/OSYS check. Failing that, make sure that IRQ is patched.

 

Thanks for the help so far. As for USB historically I have relied upon USBInjectAll and not had any issues. I am having zero luck with USB using that method in Big Sur so I did try and use Hackintool to create a USBPorts.kext and replace USBInjectAll in the installer with that. No joy so I am not sure where to go. I have attached my kext as an example to see if you can notice anything 'wrong' but have there been any significant changes in Big Sur with regard to USB that we know?

 

 

IMG_3804.HEIC

USBPorts.kext.zip

Share this post

Hrmm, your USBMap looks fine. Looks like it's finding the USB ports as well - or atleast a few of them. I'm guessing you 90% probably need IRQ patching since it's an older dell, so I'd try that first. You can use SSDT-Time to help with that.

Share this post

44 minutes ago, 1Revenger1 said:

Hrmm, your USBMap looks fine. Looks like it's finding the USB ports as well - or atleast a few of them. I'm guessing you 90% probably need IRQ patching since it's an older dell, so I'd try that first. You can use SSDT-Time to help with that.

 

Hey - thanks for that. Would I use SSDT-Time alongside the USBPorts.kext or instead of? I have tried it on its own but no dice. Is there a guide on IRQ patching or should I just follow the SSDT-Time guide?

Share this post

1 hour ago, 1Revenger1 said:

alongside - if your using it, make sure you add the SSDT as well as the patches in patches_oc.plist into your config.plist. It should have a list of a few IRQ patches under ACPI->Patches

 

Hey - I have done the required, I think, but still getting exactly the same problem. Super annoying as I feel I am pretty close to getting this working but I really can't work this out. Attached my EFI in case you can spot any obvious errors??

 

thanks for taking the time.

EFI.zip

Share this post

1 hour ago, 1Revenger1 said:

Hrmm
You shouldn't need the USB renames btw. Try enabling UEFI->Quirks->ReleaseUsbOwnership

 

Sorry for not understanding but when you say I should try deleting the renames did you mean the EHC1 to EH01 and the EHC2 to EH02 or the HPET _CRS to XCRS Rename ?

 

I needed the EHC1 and EHC2 renames to use USBInjectAll in Clover so I added these to try and get things going in OC as I have seen similar references.

 

I removed these from my config.plist and added the quirk but no good. It seemingly stopped at a different place though, see attached. Should I put them back in and remove the HPET _CRS to XCRS Rename?

 

thanks!

IMG_3808.HEIC

Share this post

Oh, if the USB Map was done with the renames - either readd in the renames or redo the USB map. It checks the ACPI controller name, so probably easiest to add the renames I guess.
As for why your getting stuck still, I'm still confused tbh. What macOS version is this?

Share this post

On 10/13/2020 at 12:39 AM, 1Revenger1 said:

Oh, if the USB Map was done with the renames - either readd in the renames or redo the USB map. It checks the ACPI controller name, so probably easiest to add the renames I guess.
As for why your getting stuck still, I'm still confused tbh. What macOS version is this?

 

I was trying this on a BigSur installer but for ease of debugging I took the OC config and applied it to a Catalina test install that works perfectly with clover to see where the issue may be. I have discovered that for some reason my renames for EHC1 and EHC2 are not working in OC and therefore blocking USB from working correctly. I have gone over everything many times and can't work out what I am doing wrong and why the renames are failing.

 

I have attached my complete config.plist so can you spot anything that may indicate problems with the rename? The age of the system means that I do need these renames and them not working would explain why USBInjectAll wasn't working either. The values in the renames match the renames that do work in clover.

 

any thoughts as I am really confused.

 

config.plist

Share this post

2 hours ago, chris1111 said:

For Legacy Dell Optiplex try this EFI

You can also put your DSDT.aml in ACPI

 

EFI.zip

 

thanks for this - using basically your EFI I encounter EXACTLY the same issue. My EHC1&2 renames do not occur therefore I don't have USB. I have tried with and without DSDT included and various combinations in-between but nothing. Its almost like I am missing a flag to flip in order to enable the rename even though in the config.plist I have the rename there. I am truly stumped. The USB controller is there but the ports are not.

 

If I boot into clover then the renames are there and everything is 100% so it must be something simple I am missing .....

 

Any ideas?

Edited by mickeyd453
Share this post

It looks like it may be possibly getting past rooting actually and finding the USB - If you leave it for a minute or two, does the screen become garbled with a new message at the bottom saying "Still waiting for root"? If this doesn't happen - it may be another issue. As for patches not applying - make sure you aren't putting in a DSDT I guess, otherwise you have to do the rename manually yourself. I'd dump a log from OC to see if it's erroring out.

Share this post

8 minutes ago, 1Revenger1 said:

It looks like it may be possibly getting past rooting actually and finding the USB - If you leave it for a minute or two, does the screen become garbled with a new message at the bottom saying "Still waiting for root"? If this doesn't happen - it may be another issue. As for patches not applying - make sure you aren't putting in a DSDT I guess, otherwise you have to do the rename manually yourself. I'd dump a log from OC to see if it's erroring out.

 

Sorry I should have made it more clear. I gave up on the BigSur install and decided to just get OC working so I can replace Clover. I have a fully running Catalina test system that's booting 100% with clover. To debug the issue I booted that install with OC to see where it was getting stuck. I can boot that Catalina system to the desktop and it works 'fine' but it has no USB, like the BigSur installer problem. By connecting to the desktop via VNC and also ssh'ing in I can see that the USB controller is found but I have port clashes due to EHC1 and EHC2 not being renamed. I have applied the config.plist patch for this rename but I can see it fails and therefore the rename does not happen. I wonder if I am encountering a bug.

 

In clover I'd use 'bdmesg' to see a clover boot log - is there a similar command in OC ? I see there are lots of text files in the EFI for OC but these are not human readable from what I can tell. Is it possible to read them with something?

 

thanks for the help so far!

 

Share this post

The log file is probably full of just a lot of NULLs - i.e it's just an empty file. I'd replace BOOTx64.efi, OpenCore.efi, and OpenRuntime.efi with the debug version found in the releases tab and use that, and you should get logs. I would also suggest setting Misc->Security->Target to 0 whenever you don't need logs as OC writing the logs can be somewhat brutal to USBs I've found.

Also - not really related, but I noticed that you manually filled in everything under PlatformInfo rather than using Automatic=true + the Generic dictionary. You generally don't need to do that, as OC can generate most of the SMBIOS for you.

Share this post

18 hours ago, 1Revenger1 said:

The log file is probably full of just a lot of NULLs - i.e it's just an empty file. I'd replace BOOTx64.efi, OpenCore.efi, and OpenRuntime.efi with the debug version found in the releases tab and use that, and you should get logs. I would also suggest setting Misc->Security->Target to 0 whenever you don't need logs as OC writing the logs can be somewhat brutal to USBs I've found.

Also - not really related, but I noticed that you manually filled in everything under PlatformInfo rather than using Automatic=true + the Generic dictionary. You generally don't need to do that, as OC can generate most of the SMBIOS for you.

 

Thanks for the tip, I have attached my boot log here and I can't see anything obvious that would indicate what was/is causing my EHC renames to not work. Canyon spot anything that may be causing me problems?

 

On the same machine but booting via clover rather than OC I see "4:275  0:000   - [00]: (Rename EHC1 to EH01) lenToFind: 4, lenToReplace: 4, Target Bridge:" indicating success

 

With regard the SMBIOS I did try the 'Automatic' method but I discovered that various fields were not being reflected in system reports. Serial number as an example was showing as 'Unavailable' even though it was included in PlatformInfo so not sure why that would be if automatic is supposed to work well.

 

opencore-2020-10-15-121005.txt

Share this post

On 10/15/2020 at 2:24 PM, mickeyd453 said:

 

Thanks for the tip, I have attached my boot log here and I can't see anything obvious that would indicate what was/is causing my EHC renames to not work. Canyon spot anything that may be causing me problems?

 

On the same machine but booting via clover rather than OC I see "4:275  0:000   - [00]: (Rename EHC1 to EH01) lenToFind: 4, lenToReplace: 4, Target Bridge:" indicating success

 

With regard the SMBIOS I did try the 'Automatic' method but I discovered that various fields were not being reflected in system reports. Serial number as an example was showing as 'Unavailable' even though it was included in PlatformInfo so not sure why that would be if automatic is supposed to work well.

 

opencore-2020-10-15-121005.txt

 

If you have a working boot via Clover, then post your IOREG file after the system is booted.

Your USB rename may not be working because OC cannot find what you told it to look for.

The IOREG will show you the names of your devices.

Share this post

×