OpenCore General Discussion

[miliuco]

4 hours ago, tonyx86 said:

I was thinking of replacing EFICheckDisabler.kext with RestrictEvents.kext; however, when I tested RestrictEvents.kext, it appears that eficheck driver still loads, so I'm not sure that eficheck is blocked.  When using RestrictEvents.kext, should I see EFICheck driver attached to LPCB in IORegistry?

I'm using RestrictEvents and I don't have eficheck bit I'm not sure if it was without the kext.

Spoiler

 

A naive question: how can I post a block titled Reveal hidden contents as yours? Thanks @tonyx86

Edited June 11, 2021 by miliuco

[deeveedee]

[miliuco]

2 minutes ago, tonyx86 said:

I'm dumb 

[deeveedee]

@miliuco Not at all!!!  Easy thing to miss.  I moved my EFICheck disable question to here if you have any comments or advice.  Thank you.

Edited June 11, 2021 by tonyx86
Corrected link

[miliuco]

1 hour ago, MifJpn said:

Hello developers.
Thank you for your excellent development.

In this commit 8dcc535eec1e170b91ceb568f7688db9ea74bbd6, ocvalidate said:

Misc->Entries [0]->Path is too long (should not exceed 128)!...

Try 36869e7 build. It's fixed.

[miliuco]

@Matgen84

I had not read your issue in the bug tracker, I replied without knowing that you had published it there.

[mnfesq]

I have a question regarding the min and max version feature for kexts in the kernel section of config.plist.  First, some background:  With Monterey's release, Bluetooth no longer works using the BluetoothInjector.kext.  However, a new kext called BlueToolFixup.kext has been developed which makes Bluetooth work in Monterey.  You cannot use BluetoothInjector.kext with BlueToolFixup.kext and from what I have read, you need to delete BluetoothInjector.kext from your kext folder. I have a single OC EFI folder for booting Big Sur and Monterey.  In Clover, I can put BluetoothInjector.kext in my 11 kext folder and put BlueToolFixup.kext in my Other kext folder and can get Bluetooth to work in both Big Sur and Monterey.  I tried using the min and max version feature with these kexts to use OC to boot in Big Sur and Monterey.  In the BluetoothInjector.kext, I set the maxversion to 20.6.0 and in the BlueToolFixup.kext, I set the minversion to 21.0.0.  When I boot to Big Sur I have no problem but when I boot to Monterey, I get a KP, which is being caused by the BluetoothInjector.kext being loaded.  Am I using this feature correctly or am I trying to do something it was not designed to do?  Is there any other way I can use OC to boot to Big Sur and Monterey with them needing different kexts to work correctly?

Edited June 15, 2021 by mnfesq

[Sherlocks]

I have a question regarding the min and max version feature for kexts in the kernel section of config.plist.  First, some background:  With Monterey's release, Bluetooth no longer works using the BluetoothInjector.kext.  However, a new kext called BlueToolFixup.kext has been developed which makes Bluetooth work in Monterey.  You cannot use BluetoothInjector.kext with BlueToolFixup.kext and from what I have read, you need to delete BluetoothInjector.kext from your kext folder. I have a single OC EFI folder for booting Big Sur and Monterey.  In Clover, I can put BluetoothInjector.kext in my 10.6 kext folder and put BlueToolFixup.kext in my Other kext folder and can get Bluetooth to work in both Big Sur and Monterey.  I tried using the min and max version feature with these kexts to use OC to boot in Big Sur and Monterey.  In the BluetoothInjector.kext, I set the maxversion to 20.6.0 and in the BlueToolFixup.kext, I set the minversion to 21.0.0.  When I boot to Big Sur I have no problem but when I boot to Monterey, I get a KP, which is being caused by the BluetoothInjector.kext being loaded.  Am I using this feature correctly or am I trying to do something it was not designed to do?  Is there any other way I can use OC to boot to Big Sur and Monterey with them needing different kexts to work correctly?

there is no problem in my case. i can boot both

Sent from my SM-N960N using Tapatalk

[1Revenger1]

1 hour ago, mnfesq said:

I have a question regarding the min and max version feature for kexts in the kernel section of config.plist.  First, some background:  With Monterey's release, Bluetooth no longer works using the BluetoothInjector.kext.  However, a new kext called BlueToolFixup.kext has been developed which makes Bluetooth work in Monterey.  You cannot use BluetoothInjector.kext with BlueToolFixup.kext and from what I have read, you need to delete BluetoothInjector.kext from your kext folder. I have a single OC EFI folder for booting Big Sur and Monterey.  In Clover, I can put BluetoothInjector.kext in my 10.6 kext folder and put BlueToolFixup.kext in my Other kext folder and can get Bluetooth to work in both Big Sur and Monterey.  I tried using the min and max version feature with these kexts to use OC to boot in Big Sur and Monterey.  In the BluetoothInjector.kext, I set the maxversion to 20.6.0 and in the BlueToolFixup.kext, I set the minversion to 21.0.0.  When I boot to Big Sur I have no problem but when I boot to Monterey, I get a KP, which is being caused by the BluetoothInjector.kext being loaded.  Am I using this feature correctly or am I trying to do something it was not designed to do?  Is there any other way I can use OC to boot to Big Sur and Monterey with them needing different kexts to work correctly?

I usually do max version = 20.99.9 to account for any new security updates, and min version=21.0.0
I know that there was an issue at one point with panics, I'd make sure you're using the latest version from the repo. (If you don't want to build it, the Dortania website has a builds page with every commit there which gets updated automatically)

[mnfesq]

1 hour ago, Sherlocks said:

there is no problem in my case. i can boot both

Sent from my SM-N960N using Tapatalk
 

 

You have both kexts in the same folder and both kexts listed in Kernel>Add?  Do you use min and max version?  Would you mind sharing your config.plist?

[HenryV]

4 hours ago, mnfesq said:

I have a question regarding the min and max version feature for kexts in the kernel section of config.plist.  First, some background:  With Monterey's release, Bluetooth no longer works using the BluetoothInjector.kext.  However, a new kext called BlueToolFixup.kext has been developed which makes Bluetooth work in Monterey.  You cannot use BluetoothInjector.kext with BlueToolFixup.kext and from what I have read, you need to delete BluetoothInjector.kext from your kext folder. I have a single OC EFI folder for booting Big Sur and Monterey.  In Clover, I can put BluetoothInjector.kext in my 11 kext folder and put BlueToolFixup.kext in my Other kext folder and can get Bluetooth to work in both Big Sur and Monterey.  I tried using the min and max version feature with these kexts to use OC to boot in Big Sur and Monterey.  In the BluetoothInjector.kext, I set the maxversion to 20.6.0 and in the BlueToolFixup.kext, I set the minversion to 21.0.0.  When I boot to Big Sur I have no problem but when I boot to Monterey, I get a KP, which is being caused by the BluetoothInjector.kext being loaded.  Am I using this feature correctly or am I trying to do something it was not designed to do?  Is there any other way I can use OC to boot to Big Sur and Monterey with them needing different kexts to work correctly?

Yes, you can make a couple of small FAT32 partitions, one with OC for Big Sur and the other with OC for Monterey.  You can use Refind as your boot manager and chainload whichever one you want.  You can also use linux's GRUB2 and chainload whichever version you want.  You can do the same with clover.

 

https://www.insanelymac.com/forum/topic/346639-updated-tips-and-observations-for-115-beta/

[joevt]

I read the document at https://github.com/acidanthera/OpenCorePkg/blob/ee0fb99105a191c16926b8d6cd58ce2151eb7894/Debug/README.md

so I thought the following might be interesting:

 

I'm doing some source level debugging of a UEFI app in Parallels Desktop for macOS. It seems to work well except for a couple things.

 

I have "Config -> Options -> Show developer tools" enabled. I also have "Config -> Hardware -> Boot Order -> Advanced -> BIOS" set to EFI 64-bit (not Secure Boot) and the following Boot flags (I don't know if the flags are necessary or what exactly they do):

• vm.efi.debug=1
• vm.efi.stub_console=1

I start the VM, and my UEFI app starts running ("/EFI/Boot/bootx64.efi" on the VM disk image). Then I can select "Develop -> Start Debugging Session" which starts the VM's gdb server and starts lldb in Terminal.app. I can exit there and restart lldb elsewhere (I would like to start it from Xcode to use Xcode's graphical debugger but I don't know of a way to do that - maybe I should try VS Code for macOS?).

 

I have a script that launches the VM (if it's not already running), waits for the gdb server to start, waits for the gdb server to be free (you have to exit from the lldb that launched in Terminal.app before you can connect lldb from elsewhere), parses the VM's parallels.log file for EFI images and addresses, creates an lldb script with all the necessary info (target module file name and slide address), and launches lldb with the address of the gdb server and the script. For the target module, I can use the macho .dll and it's .dSYM of my .efi app even though EFI uses pecoff. I can set breakpoints (up to 16) and watchpoints (up to 4) which all seem to work. I can print and set expressions. etc.

 

I think there may be a problem with stepping over source lines using "thread step-over". After awhile the VM might not continue, and gdb won't accept new commands (to interrupt the process or whatever) so the VM has too be restarted.

 

While breakpoints usually work, sometimes they do not - and they cause the VM to stop. For example, I have one breakpoint that occurs after approximately 30 seconds. The VM outputs a breakpoint exception message to the parallels.log file and stops the VM instead of going to lldb.

06-16 15:24:52.733 F /monitor/ OTG print: !!!! X64 Exception Type - 03(#BP - Breakpoint)  CPU Apic ID - 00000000 !!!!

Everything starting from "!!!!" appears to be from Cpu.Dxe of UEFI.

Does the gdb server stop working after awhile or did the exception table (or whatever it's called) get modified? How do I examine the exception table in lldb?

Watchpoints seem to work without issue - I can set one at the beginning and it will work even after breakpoints stop working. If I do "Start Debugging Session" later then breakpoints will work. I guess "Start Debugging Session" sets up the exception table properly for the debugger.

 

 

Other issues:

1)

The "thread backtrace" command only works if the functions are using the $rbp register (frame pointer). My UEFI app uses the frame pointer for all of it's functions so it's usually ok, but the back trace will end when it reaches a function that doesn't use the $rbp. I have debug code in my app to generate a backtrace (using $rbp) for every allocation so I can find memory leaks. However, if the allocation occurs outside of my app (for example, if my app calls EFI_FILE_HANDLE->Open) then a simple frame backtrace won't show where my app calls Open because the backtrace will end before it reaches there. In that case I have a slower backtrace method that I can enable that doesn't use $rbp - it just scans for addresses that point to a LOADED_IMAGE. Many of the return addresses will be false positives (stale return addresses because functions don't always erase the space they use for locals) or pointers to data. Anyway, for lldb, I suppose a script can be created to produce a similar backtrace.

 

2)

While I have the names and addresses of all the UEFI images that are loaded, I cannot add them as target modules in lldb because I don't have the symbol files for Parallels' firmware. There doesn't appear to be a way to add a range of memory as a module. lldb can save all the memory ranges as files, but it won't accept the files as target modules. Maybe I could extract the files from Parallels' firmware volume but I don't think lldb accepts pecoff files? The files won't have symbols, but it might be useful to know which loaded image and section a breakpoint or address belongs to.

 

I haven't tried the OpenCorePkg/Debug stuff. Instead of parsing a log file like I do, the OpenCorePkg/Debug script actually finds images by scanning memory for the EFI system table. Then it gets the EFI_DEBUG_IMAGE_INFO_TABLE_HEADER from the ConfigurationTable. Do all UEFI's have a EFI_DEBUG_IMAGE_INFO_TABLE_HEADER? Shouldn't it scan the handle database for images? Actually, Parallels firmware does have the EFI_DEBUG_IMAGE_INFO_TABLE_HEADER so I copied the lldb commands from OpenCorePkg/Debug/efidebug.tool into my script like this:

gdb-remote ${GDB_REMOTE_URL}
settings set plugin.process.gdb-remote.target-definition-file /Volumes/Work/Programming/EFIProjects/joevt-OpenCorePkg/Debug/Scripts/x86_64_target_definition.py
target module add /Volumes/Work/Programming/EFIProjects/joevt-OpenCorePkg/Debug/GdbSyms/Bin/X64_GCC5/GdbSyms.debug
command script import /Volumes/Work/Programming/EFIProjects/joevt-OpenCorePkg/Debug/Scripts/lldb_uefi.py
command script add -c lldb_uefi.ReloadUefi reload-uefi
reload-uefi

 

It works. It lists all the symbol files for Parallels' firmware and for my UEFI app but of course, I only have the symbol file for my UEFI app so only that gets loaded as a module. I wonder if symbolication can be done without a symbol file using functions from lldb.utils.symbolication?

 

One problem is that I cannot print variables that exist in both my app and GdbSyms, such as gST. Is there a way to change the module search order or to unload the GdbSyms module (it's only needed to define the types used by the reload-uefi command).

 

[deeveedee]

I am noticing that HP laptops and desktops limit the number of bootable EFIs to a number less than the total number of installed EFIs. Is there a work-around that lifts this restriction?  

 

Details: On my HP laptop (two drives: one M.2 NVMe SSD and one SATA HD), when configured for UEFI boot mode, the BIOS permits only one EFI to be bootable (the second EFI is disabled).  Someone has reported to me that on their HP EliteDesk 800 G4 Mini (three drives: two M.2 NVMe SSDs and one SATA HD), the BIOS permits only two EFIs to be bootable (the third EFI is disabled).  

 

Is this a "BIOS" limitation, or is there a work-around that permits booting from all EFIs?

 

EDIT: After some experimentation with my HP laptop (two drives: one M.2 NVMe SSD and one SATA HD), if I install OC in the EFI of both the NVMe SSD and the SATA HD, BIOS forces boot from HD EFI (booting from the NVMe SSD EFI is not an option).

Edited June 21, 2021 by tonyx86

[vit9696]

@joevt, Parallels GDB is bugged as hell to my memory, so I can imagine all sort of joy here. Also lldb client worked less reliably than gdb for some reason for me. I am not sure that symbolication can be done without the files, most likely not. But I did see scripts exporting symbols from IDA: https://github.com/night199uk/gdb-symbol-maker.

[HenryV]

7 hours ago, tonyx86 said:

I am noticing that HP laptops and desktops limit the number of bootable EFIs to a number less than the total number of installed EFIs. Is there a work-around that lifts this restriction?  

 

Details: On my HP laptop (two drives: one M.2 NVMe SSD and one SATA HD), when configured for UEFI boot mode, the BIOS permits only one EFI to be bootable (the second EFI is disabled).  Someone has reported to me that on their HP EliteDesk 800 G4 Mini (three drives: two M.2 NVMe SSDs and one SATA HD), the BIOS permits only two EFIs to be bootable (the third EFI is disabled).  

 

Is this a "BIOS" limitation, or is there a work-around that permits booting from all EFIs?

 

EDIT: After some experimentation with my HP laptop (two drives: one M.2 NVMe SSD and one SATA HD), if I install OC in the EFI of both the NVMe SSD and the SATA HD, BIOS forces boot from HD EFI (booting from the NVMe SSD EFI is not an option).

If you have an Insyde BIOS you can choose the order of the listed EFI boot entries.  You can use GRUB2 or Refind as the boot manager and chainload a dozen different EFI patitiions on different disks if you want.   Any reasonable number of disks or partitions.

 

See the multibooting info:

 

https://www.insanelymac.com/forum/topic/346639-updated-tips-and-observations-for-big-sur-and-monterey-b1/

 

 

[deeveedee]

@HenryV Thank you for your quick response and a great write-up. I've seen mention of GRUB2 and Refind, but thought these are "frowned upon" by the OC Developers and at the very least are unsupported by Acidanthera.  Is that still true?

 

Pinging @andjules since you may be interested in this.

[HenryV]

17 hours ago, tonyx86 said:

@HenryV Thank you for your quick response and a great write-up. I've seen mention of GRUB2 and Refind, but thought these are "frowned upon" by the OC Developers and at the very least are unsupported by Acidanthera.  Is that still true?

 

Pinging @andjules since you may be interested in this.

The last time I looked Refind does not officially support Open Core, but you can still chainload Open Core and boot your OS.

 

One issue with Refind is that it scans and detects bootable efis that you may not want to see in the graphical boot menu.

 

However those entries are easily excluded in the refind.conf file. 

 

It is worthwhile to note that you can put GRUB2, refind, Open Core and Clover all in the same ESP, or you can split off as many FAT32 bootloader partitions as you need to launch differently configured OSs....such as one clover config for Big Sur and another for Monterey. 

 

Works fine.

 

 

[mnfesq]

On 6/21/2021 at 9:03 AM, tonyx86 said:

I am noticing that HP laptops and desktops limit the number of bootable EFIs to a number less than the total number of installed EFIs. Is there a work-around that lifts this restriction?  

 

Details: On my HP laptop (two drives: one M.2 NVMe SSD and one SATA HD), when configured for UEFI boot mode, the BIOS permits only one EFI to be bootable (the second EFI is disabled).  Someone has reported to me that on their HP EliteDesk 800 G4 Mini (three drives: two M.2 NVMe SSDs and one SATA HD), the BIOS permits only two EFIs to be bootable (the third EFI is disabled).  

 

EDIT: After some experimentation with my HP laptop (two drives: one M.2 NVMe SSD and one SATA HD), if I install OC in the EFI of both the NVMe SSD and the SATA HD, BIOS forces boot from HD EFI (booting from the NVMe SSD EFI is not an option).

 

HP always makes its HD the primary boot source even when an SSD is present.  I used to have an HP laptop that had 2 HD drive bays and an M2 slot and it was the same as you described (EFI on 1st HD and M2 worked but not 2nd HD). Now, my HP laptop has 1 HD drive and 1 SSD and EFI partitions on both drives work, although the HD EFI is always first to boot unless I hide the entry using an EFI boot menu editor like EasyUEFI.  Here's what my EFI situation looks like (the SSD EFI is on the left and the HD EFI is on the right):

 

[deeveedee]

@mnfesq My observations with my HP Envy are the same (1 M.2 NVMe SSD, 1 SATA HD).  I have also noticed that if I install OC in the SATA HD EFI, the OC picker appears a few seconds earlier than when I install OC in the M.2 NVMe SSD EFI.  It's as though the HP laptop always searches the SATA HD first and after a timeout, searches the M.2 NVMe SSD.

Edited June 23, 2021 by tonyx86

[obus]

Hi all developers.

I have a problem with my intel i210 Nic and I'm not sure if this is a bug in OC or something with Big Sur 11.4.

My intel i210 Ethernetcard (8086 1043) gives me KP as soon as I connect a lan-cable to any of the two ports. If I boot with any of the cables attached I get KP just before or a little bit after the login screen. Without cables connected or card disabled in bios booting works fine with both OC 0.6.9 and 0.7.0 The problem occurs only with Big Sur 11.4. Big Sur 11.3 works great with both OC 0.6.9 and 0.7.0.Everything works fine with Clover ver. 5137

There is a solution at hand in form of a kext (LAN-WSPRO.kext) provided from  @joedm ru on another thread here:

Spoiler

 

My question is if I should start a new issue in bug tracker (which I've already had) or if I should just stay put and use the provided kext.

[naiclub]

Hello all developers, I have a lot of questions in my head I want to ask about the yellow circle by the circle. We will follow in the yellow circle to press where, if anyone knows, please answer again.
And there is another question circled in yellow on the right. If we add an order to cancel OC, do you think you can do it?
I think if this cancel order will help us to switch between OC and Clover easier.

thank you everyone

[HenryV]

On 6/24/2021 at 8:02 AM, obus said:

Hi all developers.

I have a problem with my intel i210 Nic and I'm not sure if this is a bug in OC or something with Big Sur 11.4.

My intel i210 Ethernetcard (8086 1043) gives me KP as soon as I connect a lan-cable to any of the two ports. If I boot with any of the cables attached I get KP just before or a little bit after the login screen. Without cables connected or card disabled in bios booting works fine with both OC 0.6.9 and 0.7.0 The problem occurs only with Big Sur 11.4. Big Sur 11.3 works great with both OC 0.6.9 and 0.7.0.Everything works fine with Clover ver. 5137

There is a solution at hand in form of a kext (LAN-WSPRO.kext) provided from  @joedm ru on another thread here:

  Hide contents

 

My question is if I should start a new issue in bug tracker (which I've already had) or if I should just stay put and use the provided kext.

If all is well with clover, but the kexts are not injected and functional with OC, then it would appear to be a problem with OC, perhaps including within the config.plist.  Note that prior versions of Big Sur worked with intel wifi kexts and OC .  With subsequent releases of Big Sur the kexts stopped loading with functionality,  and reverting to a previous working verson of OC did not rectify the problem.

 

OC may have to change the way kexts are injected as mac OS updates.

 

The most recent update to Mojave caused a boot failure issue with clover.  Clover update fixed that.

Edited June 27, 2021 by HenryV

[naiclub]

None of the developers are interested in my offer?

[hardcorehenry]

13 hours ago, naiclub said:

We will follow in the yellow circle to press where

Press Tab key.

[naiclub]

3 hours ago, hardcorehenry said:

กดแป้น Tab

thank you very much

edit.... OC is starting to be fine with me. It went as far as the Mac OS 10.8-12. I can't get this far. I want to try it with Mac OS 10.5-10.7.

Edited June 28, 2021 by naiclub