Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8755 posts in this topic

Recommended Posts

Riley Freeman
Riley Freeman
Posted
Posted (edited)
1 hour ago, Andrey1970 said:

The safe mode works only with supported Mac-models.

-no_compat_check won't help with safe mode and with install.

 

I'm using MP6,1 which I'm assuming is supported.

 

Here's the verbose output behind the screen. After this displays for a short while it drops back to the OC bootpicker.

 

In this boot I tried setting securebootmodel to default (I had it disabled up to now) to see if it made any difference. It didn't. And booting with securebootmodel set to disabled gives similar output (minus the middle KernelCollections section).

 

kp.thumb.jpg.4a2da3e4495e5eb82e89873fbc591ae1.jpg

Edited by Riley Freeman
Riley Freeman
Riley Freeman
Posted
Posted
11 hours ago, 5T33Z0 said:

Try iMac13,2 in combination with these Patches: https://github.com/5T33Z0/OC-Little-Translated/tree/main/09_Board-ID_VMM-Spoof

 

This way, you can use a natively supported smbios for your 3rd Gen Core I7 on Big Sur and Monterey.

 

Thanks, but that seems like a lot of work just to fix safe mode. Why is that broken when I can boot into regular Big Sur just fine? Monterey isn't an option for either machine due to them having Kepler cards.

 

This is actually the reason I was trying to get into safe mode in the first place. I set up a Big Sur install on the Z68 which is connected to the display via DP. When I brought it over to the X79 which uses DVI I got stuck on a black screen with mouse cursor in place of the login window. I read that booting into safe mode could fix this so I wanted to give that a try.

Andrey1970
Andrey1970
Posted
Posted (edited)
21 hours ago, Riley Freeman said:

I'm using MP6,1 which I'm assuming is supported.

Probably at you Automatic = No and board-id and other in PlatformInfo don't correspond MacPro6,1
Recommend to use Automatic = Yes

Edited by Andrey1970
  • Like 1
Maccer
Maccer
Posted
Posted (edited)

I thought maybe this would be the right place to ask the question because I've asked around and no one seems to be able to give me an answer not to mention a solution.

 

I, and pretty much everyone else using an external audio interface for making music in macOS, needs vt-d to be enabled in BIOS. Without it being enabled, the audio interface doesn't show up in the system.

It has something to do with how macOS prioritizes kexts or drivers (I'm not an expert) during launch. The audio drivers need to be first in line when booting and that isn't happening for some reason in hackintosh.

The drivers need a certain size portion of memory or something allocated to them and it isn't happening.

 

The general advice is to then disable IOMAPPER if you need vt-d enabled. But then of course you don't get the effects you need from vt-d as IOMAPPER basically disables it.

I have a Gigabyte MB, and if enable vt-d and don't disable IOMAPPER, my audio interface works, but my ethernet and wifi stop working.

 

In the newest Dortania guide for 0.7.7 it says:

 

Disable IOMAPPER

 

Description: Disables IOMapper support in XNU (VT-d), which may conflict with the firmware implementation.

Note 1: This option is a preferred alternative to deleting DMAR ACPI table and disabling VT-d in firmware preferences, which does not obstruct VT-d support in other systems in case they need this.

Note 2: Misconfigured IOMMU in the firmware may result in broken devices such as ethernet or Wi-Fi adapters. For instance, an ethernet adapter may cycle in link-up link-down state infinitely and a Wi-Fi adapter may fail to discover networks. Gigabyte is one of the most common OEMs with these issues.

 

The thing mentioned in Note 2 is exactly what is happening on my system. Is there a way around this?

I tried dart=0 in boot args instead of disable IOMAPPER, and got my audio interface to work, until the next boot and it was gone again. But for one boot, I had my audio interface working and my ethernet and wifi as well.

I guess I could try dropping dmar in the ACPI, but I can't find a clear instruction on how to add that to my plist.

 

Is there a way to configure the IOMMU properly in the firmware so that I could have vt-d enabled without disable IOMAPPER?

Or is there another way around this problem. I know there are thousands of people with this problem since updating to Monterey, or there is about to be when they update to the newest macOS.

 

Oh yeah, I forgot to mention the most important thing, this problem started with Monterey. Though I can't say for sure for Big Sur as I jumped from Catalina.

Before, when I was in Catalina, I had vt-d enabled in BIOS, I didn't have IOMAPPER disabled, and my audio interface was working and so was my ethernet and wifi. So something happened in Monterey that made these problems surface.

Man I hope someone knows.

 

 

EDIT:

 

I don't want to make unnecessary extra posts so I came here to edit.

 

Thank you guys so much for your help. I dropped DMAR and replaced it with an edited one and now everything works beautifully. You have no idea how thankful I am. I've been banging my head against the wall for two months, while people have just been parroting to me to disable IOMAPPER even though I couldn't have.

 

And I learned something new and valuable. So happy now!

Edited by Maccer
To give extra thanks!
Riley Freeman
Riley Freeman
Posted
Posted
1 hour ago, vit9696 said:

I do not think it has anything to do to SMBIOS judging from the screenshots. But to tell more need OpenCore DEBUG log from master with AppleDebug log also enabled. Also need EFI.

 

I booted the X79 with the debug version of 0.7.6. Attached is the efi folder and the boot log file. Hope this is enough.

x79-debug-efi.zip

Stefanalmare
Stefanalmare
Posted
Posted
35 minutes ago, Maccer said:

I thought maybe this would be the right place to ask the question because I've asked around and no one seems to be able to give me an answer not to mention a solution.

 

I, and pretty much everyone else using an external audio interface for making music in macOS, needs vt-d to be enabled in BIOS. Without it being enabled, the audio interface doesn't show up in the system.

It has something to do with how macOS prioritizes kexts or drivers (I'm not an expert) during launch. The audio drivers need to be first in line when booting and that isn't happening for some reason in hackintosh.

The drivers need a certain size portion of memory or something allocated to them and it isn't happening.

 

The general advice is to then disable IOMAPPER if you need vt-d enabled. But then of course you don't get the effects you need from vt-d as IOMAPPER basically disables it.

I have a Gigabyte MB, and if enable vt-d and don't disable IOMAPPER, my audio interface works, but my ethernet and wifi stop working.

 

In the newest Dortania guide for 0.7.7 it says:

 

Disable IOMAPPER

 

Description: Disables IOMapper support in XNU (VT-d), which may conflict with the firmware implementation.

Note 1: This option is a preferred alternative to deleting DMAR ACPI table and disabling VT-d in firmware preferences, which does not obstruct VT-d support in other systems in case they need this.

Note 2: Misconfigured IOMMU in the firmware may result in broken devices such as ethernet or Wi-Fi adapters. For instance, an ethernet adapter may cycle in link-up link-down state infinitely and a Wi-Fi adapter may fail to discover networks. Gigabyte is one of the most common OEMs with these issues.

 

The thing mentioned in Note 2 is exactly what is happening on my system. Is there a way around this?

I tried dart=0 in boot args instead of disable IOMAPPER, and got my audio interface to work, until the next boot and it was gone again. But for one boot, I had my audio interface working and my ethernet and wifi as well.

I guess I could try dropping dmar in the ACPI, but I can't find a clear instruction on how to add that to my plist.

 

Is there a way to configure the IOMMU properly in the firmware so that I could have vt-d enabled without disable IOMAPPER?

Or is there another way around this problem. I know there are thousands of people with this problem since updating to Monterey, or there is about to be when they update to the newest macOS.

 

Oh yeah, I forgot to mention the most important thing, this problem started with Monterey. Though I can't say for sure for Big Sur as I jumped from Catalina.

Before, when I was in Catalina, I had vt-d enabled in BIOS, I didn't have IOMAPPER disabled, and my audio interface was working and so was my ethernet and wifi. So something happened in Monterey that made these problems surface.

Man I hope someone knows.

Block original DMAR and use this one. With VTD enabled.

SSDT-DMAR.aml

  • Like 2
Riley Freeman
Riley Freeman
Posted
Posted
4 hours ago, joevt said:

I used OCLP to add Kepler support for my GTX 680 in a MacPro3,1 running Monterey. I'm not sure what the procedure is for hackintosh.

 

Thanks. I'm aware it's possible. I tried it once when I was running the Monterey beta on my Z68 but I like to keep my systems as vanilla as possible and having to hack in drivers after every update was just too much fuss for me.

aben
aben
Posted
Posted
25 minutes ago, pkdesign said:

Did I miss something or will there not be an update this month?


2022.01 release delayed by a week to account for end of year holidays as per @vit9696. Updates can be followed here: https://github.com/acidanthera/bugtracker/issues/1885

  • Like 2
MacKonsti
MacKonsti
Posted
Posted (edited)

Hello everyone, happy new year from me too!

 

I would like to ask for those more experienced to kindly provide your ideas/feedback on a couple of issues faced in using OpenCore 0.7.6 on my Intel NUC8 running Catalina 10.15.7 successfully all this time with Clover.

 

1. I based my config on the successful setup of my other NUC10 that runs OpenCore and BigSur; with a triple-checked config, OpenCore would not see or start booting Catalina on NUC8 for some reason; I found out that UEFI->APFS->MinDate and MinVersion must both be set to -1 to load Catalina, which was then successful. Is this the correct way?

 

2. With basic settings for NUC8, I was able to boot to Catalina with Misc->Security->SecureBootModel set to Disabled but when I switched it to Default, picker would not even show! With debug version of OpenCore I saw that the last entry in the log writes: 

00:293 00:007 OC: Automatic SB model j174 from model Macmini8,1
00:300 00:007 OC: Loading Apple Secure Boot with j174 (level 1)
00:311 00:010 OC: Failed to bootstrap SB NVRAM values - Invalid Parameter

This is not normal, as the model defined in PlatformInfo -> Generic is indeed Macmini8,1

OpenCore halted at that stage.

This was harder to solve; any idea why Default does not boot and freezes OpenCore ? My BIOS is rather modern UEFI but just that Secure Boot setting (e.g. like Windows) is disabled in BIOS.

 

Thank you for your help especially on #2.

config-sanitized.plist

Edited by MacKonsti
Henties
Henties
Posted
Posted

I am booting into Ubuntu LTS 20.04.3 via opencore 0.7.6 with the ext4_x64.efi and OpenLinuxBoot.efi drivers installed in order to bypass the Linux grub boot loader.

The Linux title that is assigned to the selection icon by the opencore boot loader is Ubuntu LTS 20.04.3 yet when I interrogate the kennel version from the command line with "uname -a" it tells me that Ubuntu LTS 20.04.2 is active.

 

Trying to then update Linux I get the message that I am already on the latest version.

 

Anybody able to explain this kernel version discrepancy between what opencore and "uname -a" reflects?

 

RX-6800XT amdgpu drivers are available for both Ubuntu 20.04.2 as well as 20.04.3, making it rather difficult to pick the correct one for installation.

 

Greetings Henties

MacKonsti
MacKonsti
Posted
Posted (edited)
17 hours ago, 5T33Z0 said:

Perform an NVRAM reset

Thank you @5T33Z0 ! That worked, unknown why... I booted from USB with OC Debug and SecureBootModel set to Disabled, I was able to see Picker and selected Auxiliary Tool to clean NVRAM, and then let it reboot from my SSD that had SecureBootModel set to Default...

 

a) Anyone knows if Clover and OpenCore access the same NVRAM regions? Could it be some data stored by Clover that OC did not like, hence producing this error/halting operation?

b) Anyone can confirm the correct settings in running Catalina via OC 0.7.6? Do we only set UEFI->APFS->MinDate and MinVersion both to -1 to load Catalina?

 

Edited by MacKonsti
  • Like 1
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

@MacKonsti About b:) welll both use the same physical NVRAM, since every system has only one. But if it's the same parameters that I don't know. You would have ask the devs about that.

 

But if you switch back and forth between Clover and OC and installed clover via the pkg installer (the one with the GUI) you should uninstall it's support files from the disk and just keep the Clover EFI Folder: https://github.com/dortania/OpenCore-Install-Guide/tree/master/clover-conversion#cleaning-the-clover-junk-in-macos

 

I am using Bootloader Chooser to switch betweeen Clover and OC which is pretty cool since you can mess with one bootloader and if doesen't work you can recover from it just by booting from a differen OC oder Clover folder.

miliuco
miliuco
Posted
Posted (edited)

@MacKonsti

UEFI->APFS->MinDate and MinVersion both to -1 is valid for Catalina and for any other macOS since it disables APFS driver minimal version check.

But you can also set them to the values corresponding to each macOS version (this increases the security), e.g.:

  • MinDate and MinVersion 0 is default (currently Big Sur), leave this value if you are using Big Sur or Monterey
  • MinDate=20200306 and MinVersion=1412101001000000 is for Catalina 10.15.4 (19E287)
  • MinDate=20190820 and MinVersion=945275007000000 is for Mojave 10.14.6 (18G103)
  • MinDate and MinVersion -1 is disabled (not recommended).
  • It's required to change MinDate and MinVersion in the APFS section for macOS versions older than Big Sur.

 

Edited by miliuco
  • Like 2
vit9696
vit9696
Posted
Posted
On 1/4/2022 at 10:45 PM, Riley Freeman said:

 

I booted the X79 with the debug version of 0.7.6. Attached is the efi folder and the boot log file. Hope this is enough.

x79-debug-efi.zip 5.65 MB · 2 downloads

Looks like EnableSafeModeSlide may be broken for your boot.efi. File a bug report attaching it I guess.

On 1/7/2022 at 11:14 AM, Henties said:

I am booting into Ubuntu LTS 20.04.3 via opencore 0.7.6 with the ext4_x64.efi and OpenLinuxBoot.efi drivers installed in order to bypass the Linux grub boot loader.

The Linux title that is assigned to the selection icon by the opencore boot loader is Ubuntu LTS 20.04.3 yet when I interrogate the kennel version from the command line with "uname -a" it tells me that Ubuntu LTS 20.04.2 is active.

 

Trying to then update Linux I get the message that I am already on the latest version.

 

Anybody able to explain this kernel version discrepancy between what opencore and "uname -a" reflects?

 

RX-6800XT amdgpu drivers are available for both Ubuntu 20.04.2 as well as 20.04.3, making it rather difficult to pick the correct one for installation.

 

Greetings Henties

File a bugreport and attach a boot log. But it might be just an overlook on Ubuntu side, e.g. they could have forgotten to update the version string.

  • Like 1
Henties
Henties
Posted
Posted

@vit9696 Thank your for responding. I now checked what "About Ubuntu" is displaying and discovered that it returns Ubuntu 20.04.3 LTS, which is in line with what opencore reflects in the title of the Ubuntu Icons. I therefore agree that the discrepancy is local to Ubuntu. A future Ubuntu should hopefully rectify this anomaly.

 

Greetings Henties

sgrunt12002
sgrunt12002
Posted
Posted (edited)

This is my first post. I follow this forum and learn much for many years

I dont know if this is the right thread.

I have a working multiboot system with Opencore. Today I update Linux and at the next restart I see another entry in Opencore Gui "NO NAME".

To show Linux I use the method with OpenLinuxBoot.efi in drivers. I have looked at my config.plist well but I don't find anything strange. How can I remove "NO NAME" from the Opencore GUI?

 
boot.png

in BlessOverride I have nothing. Thanks for your help
 

 

Edited by sgrunt12002
miliuco
miliuco
Posted
Posted

@sgrunt12002

I think it can be an EFI partition. What happens if you click on it?

If it's the case, you can skip EFI partitions to be displayed in the picker playing with ScanPolicy in config.plist. Do you have 0 now? Check here to tune this property:

https://oc-scanpolicy.vercel.app

 

  • Like 2
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted (edited)

Some remarks about the explanations of the dB scale used in the Documentation.pdf, since it is inaccurate.

  • In the world of audio, various kinds of dB exist. When we are talking about the sound of an airplane taking of, we are talking about dB SPL (Sound Pressure Level).
  • But when we are talking about dB in the digital realm, we are referring to dBFS (full scale). These 2 scales are weighted differently and cannot be compared directly, since one describes sound in the air, the other one describes sound represented by digital values.
  • The dBFS scale is defined by the bit depth of the system, whereas 1 bit represents a range of 6 dB. If your Audio hardware supports 24 bit, from the noise floor all the way up to the maximum output (0 dbFS), is 24 x 6 dB = 144 dBFS (that's the dynamic range). In other words, the system can go much much quieter than -60 dB. If you still hear sound or not is a different story.
  • Minus 60 dB is a nice level because at this stage, if you have a signal which dropped by 60 dB, this  means it's now only 1/1000th of the original level. Reverb manufactures use this threshold to define the time until a reverb tail has fallen by 60 dB, depending on the dimensions of the room and the  used materials. it's called reverb time 60 (short: RT 60).
  • Long story short: -60 dB doesn't mean that this defines the lower limit of the audio level.
Edited by 5T33Z0
 Share
Go to topic listing
×
×
  • Create New...