Jump to content
8755 posts in this topic

Recommended Posts

@vandroiy2012 The action to build macOS binaries failed for your publishing of 0.7.5 today and there is no binaries being published. https://github.com/acidanthera/OpenCorePkg/runs/4073396559?check_suite_focus=true

  • Like 3
  • Thanks 1

Upgraded from OC 0.7.4 -> OC 0.7.5 following the steps here.  Upgrade was smooth and easy.  Acidanthera developers - you continue to do amazing work!  Thank you!!!

 

 

Acidanthera developers - it is a pleasure to use my HackMini8,1 thanks to your incredible work on Open Core (and to the CLOVER team's work and other boot loader work that preceded you).  I use my rig in a production environment virtually every day and it is problem-free.  This is my last hack before I purchase M1-based hardware.  Thank you for maintaining OC to allow all of us to maximize the utility and performance of our Intel-based rigs.

Edited by tonyx86
  • Like 2

Is anyone using IntelBluetooth on Monterey?

Airport kext is working but i cannot load the system with the bluetooth kexts. Tried the last working versions, tried with the latest ones, also with and without BluetoothFixup kext. Any ideas?

On 11/2/2021 at 4:40 PM, tonyx86 said:

Upgraded from OC 0.7.4 -> OC 0.7.5 following the steps here.  Upgrade was smooth and easy.  Acidanthera developers - you continue to do amazing work!  Thank you!!!

 

 

Acidanthera developers - it is a pleasure to use my HackMini8,1 thanks to your incredible work on Open Core (and to the CLOVER team's work and other boot loader work that preceded you).  I use my rig in a production environment virtually every day and it is problem-free.  This is my last hack before I purchase M1-based hardware.  Thank you for maintaining OC to allow all of us to maximize the utility and performance of our Intel-based rigs.

 

If you use OpenCore Auxiliary Tools you no longer have to do all this manual work to update the config. https://github.com/5T33Z0/OC-Little-Translated/tree/main/D_Updating_OpenCore

Hi, anybody knows if it is possible to spoof the device-id of a usb device with opencore?I know about pci, but what about usb?

The issue is with the trackpad of a macbook pro 4,1: a user is reporting that device id 0x0231 works as expected, mine is 0x0230 and I can't use two fingers+click for right click.

 

The device is located at:

IOService:/AppleACPIPlatformExpert/PCI0/AppleACPIPCI/UHC3@1D,2/UHC3@5d000000/AppleUSBUHCIPort@5d200000/Apple Internal Keyboard / Trackpad@5d200000

Edited by ghost8282
17 hours ago, 5T33Z0 said:

 

If you use OpenCore Auxiliary Tools you no longer have to do all this manual work to update the config. https://github.com/5T33Z0/OC-Little-Translated/tree/main/D_Updating_OpenCore

 

Good to know.  Call me old-fashioned, but I still prefer manual changes to my config.  Then again, I was still installing kexts in /LE up through Catalina. :)

19 hours ago, dsynos80 said:

Is anyone using IntelBluetooth on Monterey?

Airport kext is working but i cannot load the system with the bluetooth kexts. Tried the last working versions, tried with the latest ones, also with and without BluetoothFixup kext. Any ideas?

 

Intel AX200 on monterrey ok.

 

IntelBluetoothInjector.kext & BlueToolFixup.kext should not play together.

 

1351160735_ScreenShot2021-11-09at09_17_58.thumb.png.4b00ee323f5df4a1fc75028d6349715c.png

 

  • Like 5
  • Thanks 1

I was curious about a change made a while back and one I have continued to change for my own build or stuff doesn't work. I ran into this again now that Clover is using OpenCore as well.

 

Why this change was done on this section where as further on in the code, the logic (based on WriteFlash is set or not) was maintained. (search on Config->Nvram.WriteFlash)

 

Does it hurt to put this back - ie to use Config->Nvram.WriteFlash ? OPEN_CORE_NVRAM_NV_ATTR : OPEN_CORE_NVRAM_ATTR,

 

the file: Library/OcMainLib/OpenCoreNvram.c

 

  if ((Config->Misc.Security.ExposeSensitiveData & OCS_EXPOSE_VERSION_VAR) != 0) {
    OcSetSystemVariable (
      OC_VERSION_VARIABLE_NAME,
-      OPEN_CORE_NVRAM_ATTR,
+     Config->Nvram.WriteFlash ? OPEN_CORE_NVRAM_NV_ATTR : OPEN_CORE_NVRAM_ATTR,
      AsciiStrLen (Version),
      (VOID *) Version,
      NULL

the - is the current code

the + is the old code that I still need.

the difference is OPEN_CORE_NVRAM_ATTR vs OPEN_CORE_NVRAM_NV_ATTR
 

#define OPEN_CORE_NVRAM_NV_ATTR    (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE)
#define OPEN_CORE_NVRAM_ATTR       (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS)

 

@tluck Old code made OpenCore write the version to NVRAM flash if writeFlash=true. New attribute only writes to NVRAM flash if ForceOcWriteFlash is enabled. Most people probably don't want it written to NVRAM flash though.
What you may be running into is that the Opencore version was written to flash in older versions, so the newer version does not appear when using newer OC versions. Either use the "nvram" utility, NVRAM->Delete, or Reset NVRAM to remove it.

  • Like 2
19 hours ago, 1Revenger1 said:

@tluck Old code made OpenCore write the version to NVRAM flash if writeFlash=true. New attribute only writes to NVRAM flash if ForceOcWriteFlash is enabled. Most people probably don't want it written to NVRAM flash though.
What you may be running into is that the Opencore version was written to flash in older versions, so the newer version does not appear when using newer OC versions. Either use the "nvram" utility, NVRAM->Delete, or Reset NVRAM to remove it.

tl;dr: cool. thanks for the speedy response. all good now with ForceOcWriteFlash=true

Ah... I missed this quirk: ForceOcWriteFlash=true - once I added that quirk and with nvram reset things are ok with new code. This was on my Lenovo T420 (10 years and still going!) so now using writeFlash=true and ForceOcWriteFlash=true

  1. ForceOcWriteFlash
    Type: plist boolean
    Failsafe: false
    Description: Enables writing to flash memory for all OpenCore-managed NVRAM system variables.

    Note: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. 

  • 2 weeks later...
4 minutes ago, etorix said:

Both type-A and type-C on an internal hub? That's unusual…

For a full type-A switch I would use "3" since it's used for external devices which will be plugged in and out.

Yep, 2 type-A and 1 type-C on 10GB external HUB. It is not full type-A, so unusefull, but thank you.

2 hours ago, Stefanalmare said:

Yep, 2 type-A and 1 type-C on 10GB external HUB. It is not full type-A, so unusefull, but thank you.

I switched to 3. All ports work type c type a, USB3 USB2 (also, with connector flipped). So, we have an answer for similar situation.

Edited by Stefanalmare
  • Like 1

Hello everybody,

 

A question please, if someone can explain. After installing Big Sur on GA Z490M Gaming X and fixing pretty much everything I noticed a few lines in OC Debug Log which don't make much sense to me.

Maybe its safe to ignore but I'd like to know what's going on and who's doing the patch, I guess its OC. It is Patching invalid size on 3 items.

52:264 00:167 OCAK: Local relocs 689 on FFFFFF8004041000
52:318 00:053 OC: Prelinked injection Lilu.kext (Lilu.kext) - Success
52:373 00:054 OCAK: Patching invalid size 2000 with 17FD000 for com.apple.iokit.IOACPIFamily
52:434 00:061 OCAK: Local relocs 503 on FFFFFF800406F000
52:488 00:053 OC: Prelinked injection VirtualSMC.kext (VirtualSMC.kext) - Success
52:538 00:050 OC: Prelinked injection USBPorts.kext () - Success
52:593 00:055 OCAK: Patching invalid size 29000 with 12D6000 for com.apple.iokit.IOPCIFamily
52:656 00:062 OCAK: Local relocs 1836 on FFFFFF8004089000
52:715 00:058 OC: Prelinked injection WhateverGreen.kext (WhateverGreen.kext) - Success
52:784 00:069 OCAK: Local relocs 5651 on FFFFFF8004109000
52:872 00:087 OC: Prelinked injection AppleALC.kext (AppleALC.kext) - Success
52:941 00:068 OCAK: Patching invalid size 17000 with 1562000 for com.apple.iokit.IONetworkingFamily
52:998 00:057 OCAK: Local relocs 656 on FFFFFF8004295000
53:043 00:045 OC: Prelinked injection IntelMausi.kext (IntelMausi.kext) - Success
53:085 00:042 OC: Prelink size 68546560 kext offset 65933312 reserved 2613248
53:128 00:042 OCAK: KC TEXT is 65536 bytes with 50152 Mach-O headers need 512
53:208 00:080 OCAK: 64-bit AppleIoMapper replace count - 1
53:250 00:042 OCAK: Patch success com.apple.iokit.IOPCIFamily AppleIoMapper
53:431 00:181 OC: Prelinked status - Success

If i remove IntelMausi for example, the line for com.apple.iokit.IONetworkingFamily is gone so no more patching invalid size for that item. OS works absolutely fine and there are no problems. I am just curios about this.

 

Thanks

  • 2 weeks later...
On 11/21/2021 at 6:43 AM, milanca said:

Maybe its safe to ignore but I'd like to know what's going on and who's doing the patch, I guess its OC. It is Patching invalid size on 3 items.

 

I'm content to ignore for my uses of OC, but if you want to investigate further, download the OC source from github and grep for 'Patching invalid size'

 

You'll find the code that reports this DEBUG statement in ./Library/OcAppleKernelLib/PrelinkedKext.c.  From there, you may be able to determine the conditions that result in this DEBUG statement.

Edited by tonyx86
  • Like 2
On 11/18/2021 at 2:46 AM, MifJpnAlphaPlus said:

Hello developer
There is something I don't understand.
Both OpenCore and Clover have this NVRAM item while running macOS.
In OpenCore, this is thought to be erased when macOS is finished.
However, if Clover does not have T2 settings, this NVRAM item will not appear.
It is strange that what remains in NVRAM even though macOS is not running is not ”Secure” (can something bad happen if macOS is not running?).

 In terms of design philosophy, is the idea to try to guarantee that NV-RAM is morally clean, regardless of what conditions may or may not occur?
I apologize if I didn't say it well.
 Please tell me.

 

I was wondering and I hope someone responds to your interesting post and the previous one about NVRAM, but maybe your assumption is embarrassing but right anyway or they don't have time for us. I read your question about NVRAM on the Clover thread and you obviously got an answer.  😉

Edited by Loloflat6
  • Thanks 1
18 hours ago, Loloflat6 said:

I read your question about NVRAM on the Clover thread and you obviously got an answer.  😉

True.  The CLOVER thread is still very active.  I visit it periodically because I'm so impressed that Slice, Jief_Machak and others are so attentive to the thread and so responsive to the questions.  If I hadn't switched to OC and wasn't too lazy to switch back to CLOVER, I'd be tempted by the appeal of the "CLOVER Family."  Something that never developed with OC.  OC is more of a "modern family."  Not a criticism - just a difference.

  • Like 3

The Dortania guide discusses boot-arg igfxfw=2 here: https://dortania.github.io/GPU-Buyers-Guide/misc/bootflag.html and indicates that the boot-arg is for "9th Gen chipset or newer (ie Z390)."  Googling 9th Gen Intel Chipset (and variations of that string) produces ambiguous results for me.  Z390 chipset supports 8th and 9th Gen Intel CPUs (as does the Intel Q370 Chipset).  Did the Dortania guide mean to say that igfxfw=2 is for 9th Gen and later Intel CPUs (not Chipsets)?  If the guide did mean to reference 9th Gen Chipsets, what are the 9th Gen Intel Chipsets?

  • Like 1
14 minutes ago, tonyx86 said:

The Dortania guide discusses boot-arg igfxfw=2 here: https://dortania.github.io/GPU-Buyers-Guide/misc/bootflag.html and indicates that the boot-arg is for "9th Gen chipset or newer (ie Z390)."  Googling 9th Gen Intel Chipset (and variations of that string) produces ambiguous results for me.  Z390 chipset supports 8th and 9th Gen Intel CPUs (as does the Intel Q370 Chipset).  Did the Dortania guide mean to say that igfxfw=2 is for 9th Gen and later Intel CPUs (not Chipsets)?  If the guide did mean to reference 9th Gen Chipsets, what are the 9th Gen Intel Chipsets?

It works on my x1 extreme, which is 8th gen. It doesn’t work on all other x1e1s though. I forget exactly what is supported, but support I’ve found is kind of weird and inconsistent.

  • Like 1
  • Thanks 1
1 hour ago, MifJpnAlphaPlus said:

Thank you for your reply.
It's hard to describe it well without glossing over it.
 First, I am honored to have participated in the intensive testing of Clover's OC integration.
 However, that doesn't mean that I want to decide which is better or worse in terms of their basic design approaches.
 I think the reason OpenCore is so security-sensitive is because hackintoshes are now available to everyone.
 And the people who do this hacking may not even think they are hackers. (If you are a hacker, you are obviously responsible for your own security yourself.)
 Therefore, even if it is a hacking bootloader, security is a moral good for everyone who uses it, which means that it should be checked to the maximum extent possible.
 That's just my thinking.
Thank you.

 

I read your posts past year when you participeted in the intensive testing of Clover's OC integration with other developers [ develop not only coding : but going forward too] (you have changed your avatar since then 😉 )

 

Yes we are here for many different reasons of using Hackintosh and if the people who do this hacking may not even think they are hackers, I think they do it knowingly for most of them but maybe the word hacker is embarrassing.

 

And of course our own safety must be covered and we must behave as responsible people, as you mentioned and OpenCore with its complexity and security is fine for that.

 

But for me Clover, with its own security, means the simplicity is peaceful.

 

Thank you.

 

 

 

Edited by Loloflat6
  • Like 1
33 minutes ago, 1Revenger1 said:

It works on my x1 extreme, which is 8th gen. It doesn’t work on all other x1e1s though. I forget exactly what is supported, but support I’ve found is kind of weird and inconsistent.

Thanks, @1Revenger1 !  What do you mean by "It works?"  Does that mean it doesn't crash your system, or do you notice a measurable change/improvement?

12 minutes ago, tonyx86 said:

Thanks, @1Revenger1 !  What do you mean by "It works?"  Does that mean it doesn't crash your system, or do you notice a measurable change/improvement?

Doesn’t crash. I think there was a bit of a power management change, but I really don’t remember that well. I’d have to switch back and forth and see what changes to give a good answer, and I don’t have time with finals next week lol.

×
×
  • Create New...