OpenCore General Discussion

[arsradu]

8 minutes ago, insanefrancis said:

 

I don't have a Windows entry in my config.plist and Windows appears in the Startup Disk preference pane. But I am not able to restart to Windows with it.

 

On the Windows side, I can boot to macOS using the Bootcamp app which I installed using brigadier. But to be honest I don't know if it is really working as intended because it's still goes to the boot picker in which I have set macOS as default and waits for the 5 second delay.

 

The boot back into OC picker I think is intended.

The issue you're getting on MacOS however is not.

 

I just tried to set BOOTCAMP Windows from Startup Disk and after reboot, it went to Windows, as intended. And from Windows, set it back to MacOS, and after reboot, it went straight to Mac, as intended.

I don't have anything set up for Windows in Config.plist, my Windows installation is also on a different drive. So...not sure what could be the cause for the issue you're seeing in MacOS when trying to select Windows as your default boot partition.

[insanefrancis]

1 minute ago, arsradu said:

 

The boot back into OC picker I think is intended.

The issue you're getting on MacOS however is not.

 

I just tried to set BOOTCAMP Windows from Startup Disk and after reboot, it went to Windows, as intended. And from Windows, set it back to MacOS, and after reboot, it went straight to Mac, as intended.

I don't have anything set up for Windows in Config.plist, my Windows installation is also on a different drive. So...not sure what could be the cause for the issue you're seeing in MacOS when trying to select Windows as your default boot partition.

 

Ok so if I don't have a default entry set in boot picker, the boot back to any OS will correctly select the OS on the picker? But still it has to go thru the boot picker delay? 

How reliable is the keyboard keys to trigger the boot picker if you have showpicker = false ?

 

Windows is also on a different drive for me and I didn't do anything to my config.plist and on macOS which is related to Windows. I also tried the suggestion of repairing disk under Disk Utility but it errors out as well. What could be causing this error for me?

 

[arsradu]

56 minutes ago, insanefrancis said:

 

Ok so if I don't have a default entry set in boot picker, the boot back to any OS will correctly select the OS on the picker? But still it has to go thru the boot picker delay? 

How reliable is the keyboard keys to trigger the boot picker if you have showpicker = false ?

 

Windows is also on a different drive for me and I didn't do anything to my config.plist and on macOS which is related to Windows. I also tried the suggestion of repairing disk under Disk Utility but it errors out as well. What could be causing this error for me?

 

 

If you don't have anything set as default boot, it will select the first one. Whichever that is. The boot picker delay can be adjusted for as far as I know. Mine for example is set to 8s (in Misc -> Boot -> Timeout).

I don't know about keyboard shortcuts with picker off... I don't know if they're all implemented yet. I know for example in 0.5.8, setting a default boot drive with Ctrl+Enter was not functional. But it works with 0.5.9. So...I don't know. I could be wrong though. Also, my Picker is set to Show (enabled), aaand I'm also using External Picker Mode (OpenCanopy).

 

Is your Windows drive an older drive? Probably formatted as MBR?

Cause, for what I could read online, the reason for that error is because Windows is installed in Legacy Mode. If that's Windows 8 or above, I would recommend using Windows in UEFI mode and formatting the drive as GPT (in case it's not).

Edited May 19, 2020 by arsradu

[insanefrancis]

42 minutes ago, arsradu said:

 

If you don't have anything set as default boot, it will select the first one. Whichever that is. The boot picker delay can be adjusted for as far as I know. Mine for example is set to 8s (in Misc -> Boot -> Timeout).

I don't know about keyboard shortcuts with picker off... I don't know if they're all implemented yet. I know for example in 0.5.8, setting a default boot drive with Ctrl+Enter was not functional. But it works with 0.5.9. So...I don't know. I could be wrong though. Also, my Picker is set to Show (enabled), aaand I'm also using External Picker Mode (OpenCanopy).

 

Is your Windows drive an older drive? Probably formatted as MBR?

Cause, for what I could read online, the reason for that error is because Windows is installed in Legacy Mode. If that's Windows 8 or above, I would recommend using Windows in UEFI mode and formatting the drive as GPT (in case it's not).

To be clear, if I don’t have a default boot set, and I use BootCamp from Windows to reboot to OSX, it will select OSX even if it’s the second on the list? 
 

I have set the default boot using Ctrl+Enter on my OC 0.5.8. Can confirm its functional. 
 

I have Windows on a new SSD. I installed Windows using another computer since I cannot install it on my hack without disconnecting my macOS drive which is not possible for me. I’m pretty sure I installed it as UEFI because I made sure from the BIOS. I basically disabled all Legacy options before installing. After installation, I just plugged it in on my hack and OC detected it.

[arsradu]

29 minutes ago, insanefrancis said:

To be clear, if I don’t have a default boot set, and I use BootCamp from Windows to reboot to OSX, it will select OSX even if it’s the second on the list? 
 

I have set the default boot using Ctrl+Enter on my OC 0.5.8. Can confirm its functional. 
 

I have Windows on a new SSD. I installed Windows using another computer since I cannot install it on my hack without disconnecting my macOS drive which is not possible for me. I’m pretty sure I installed it as UEFI because I made sure from the BIOS. I basically disabled all Legacy options before installing. After installation, I just plugged it in on my hack and OC detected it.

 

If you select MacOS from Windows BootCamp, then MacOS will become your default boot and it should boot into it, yes. If it's still set to Windows, then it will just boot back into Windows, since that's the default boot option.

 

If you don't select anything and reset NVRAM, the default option will be the first one in your boot picker. Could be wrong, but this was the case in my experience.

 

As for Windows...I don't know. I never tried installing it this way. So...it could be fine.

 

You can check it out from Terminal, by typing:

diskutil list

I think there's a way from Windows, as well. Disk Manager or something like that. Or third party solutions like Partition Wizard.

 

But if you're already on the Mac, I guess diskutil might be the closest option. You can post the output here, if you want.

Edited May 19, 2020 by arsradu

[MacNB]

24 minutes ago, eSaF said:

 

My findings also, I tried every kind of permutations as far as Audio Setting are concerned in 0.5.9 and the results are the same each time. Reload EFI Folder from 0.5.8 and Boot-Chime returns. Copy and paste Audio driver and Resources Folder from 0.5.8 to 0.5.9 and no chime. Compile new 0.5.9, all fresh files still nothing, I have now spent roughly 6 hrs chasing this elusive feature in the latest commit because I have nothing better to occupy my time but I am not bitter just disappointed and brain dead as I won't be getting a congratulatory response from my hero  C'est la vie.

 

So...while in isolation....with some time... I built 0.5.9.

Bootchime works fine for me using the newly generated AudoDxe.efi.

I tried to break it by changing the .efi driver order (I put AudioDxe.efi last in the list of Drivers) but it still produced a chime.

I was using the DEBUG version. 

Have not tried the RELEASE version (yet).

[markl18]

On 5/18/2020 at 3:33 PM, markl18 said:

hi I ma trying my hardest to figure out how to boot my windows machine from bootable iso same one you got except the Russian version 

hi I have this and my iso file doesn't want to be found

sudo /usr/local/bin/qemu-system-x86_64 \

    -m 8G \

    -machine q35 \

    -cpu max \

    -smp 4,cores=2,threads=2,sockets=1 \

    -usb \

    -serial mon:stdio \

    -vga vmware \

    -device qemu-xhci \

    -device usb-kbd \

    -device usb-mouse \

    -bios "$HOME"/ovmf/x64/bios.bin \

    -drive format=raw,if=ide,file=/dev/disk0s3 \

    -cdrom "$HOME"/Downloads/windows.iso \

    -boot c

 

 

 

 

[markl18]

what does this error mean I never even saw this unable to get update memory

[makk]

in need of help with legacy schema.  getting message on boot 

not set 

 

legacy boot laptop.  Asus. PS2 Touchpad with controller not the Voodoo version causes crash.  searched for Apple

 

keyboard does not function.  

 

picker shows Tools not Drives

 

0.5.9 Version

 

all these changes and no instructions.  Go figure.

 

the new guide explains to not Use DSDT.aml in config.plist because the secret hidden place for these are in the board. But guess what?

If you don't use them, you can't get the hacks you made with Clover to work.  Go figure?

 

Created SSDT's for this and that to avoid DSDT as mentioned. But the FNkeys fail.  I don't use Voodoo stuff, because it breaks my keys and causes other failures.

 

It is a good thing though to not have to use extracted and hacked DSDT.  but still a long ways off till this happens. 

 

 

Log message:

 

00:000 00:000 Dependency com.apple.iokit.IOHIDSystem fallback to com.apple.iokit.IOHIDFamily succeeded. Please fix your kext!
00:047 00:047 Dependency com.apple.iokit.IOHIDSystem fallback to com.apple.iokit.IOHIDFamily succeeded. Please fix your kext!
00:128 00:081 Dependency com.apple.iokit.IOHIDSystem fallback to com.apple.iokit.IOHIDFamily succeeded. Please fix your kext!
 

 

IOHIDSystem is a plugin in IOHIDFamily << ???

 

Edited May 20, 2020 by makk

[vit9696]

@arsradu@eSaF, it is not clear to me from the description of what is broken AudioDxe or OpenCore. Does older AudioDxe work with OpenCore from master?

 

From your reports I am starting to suspect that you have your audio codec not resetting across the reboots, and thus you get random audio failures. This is what you can try to troubleshoot by multiple reboots and/or cold resets (full poweroff and then power up).

 

@makk, regarding your last question, IOHIDSystem is a plist-only kext commonly used instead of IOHIDFamily. The warning is rather harmless, but it is indeed best to fix the kext to contain IOHIDFamily instead of IOHIDSystem, as the former is not in kernelcache, and OpenCore has to workaround it.

Edited May 20, 2020 by vit9696

[makk]

@makk, regarding your last question, IOHIDSystem is a plist-only kext commonly used instead of IOHIDFamily. The warning is rather harmless, but it is indeed best to fix the kext to contain IOHIDFamily instead of IOHIDSystem, as the former is not in kernelcache, and OpenCore has to workaround it.

Edited 4 minutes ago by vit9696

 

I need some coaching on this.  What is it asking?  IOHIDSystem is plugin to IOHIDFamliy

do I remove it and put in /Library/Extensions OR /System/Library/Ext.?

 

UPDATE:

Removed the IOHIDSystem.kext and placed in SLE, still getting that message.  What should I do?

 

 

UPDATE:

questions: how to get the Boot part, to show the Mac Icons?  <Picker

I'm seeing only Tools:  kicker, reset, cleanNvram, so forth,  

<<Solved

deleted not needed Tools from config.plist and I see my startup drive.

 

 

--I have to use Legacy Boot and the Legacy Schema have no idea how to remedy this.  using 5.8 I was able to not see this message. No Schema

 

Using NVRAM Emulation

nvram.plist

nvram.mojave

 

--also no keyboard function in Picker

 

I tried using AptioInputfix.efi, AppleGenericInput.efi, tried several things, and still no keyboard.  

PS2 laptop.

 

Boots up fine runs.  5.8 ran faster for me. It was quick.  but I followed instructions for FileVault and could no longer boot up, forgot to turn on file vault before rebooting.  Spent hours getting it to boot just to forget to turn on that thing. gave up after 12 hours.  so today I built the OC from Internet using the OC builder and build the kexts tool. Tried to use AsusSMC.kext but would not work on a few FN keys, reverted back to AsusNBFkeys from emilydinesh along with the ApplePS2Touchpad.kext.  works like a charm once I hacked the DSDT to correct the inputs. 

 

 

Thanks Vit

 

 

config.plist.zip

Edited May 20, 2020 by makk

[baddles]

https://youtu.be/ZMu5QmsbvU4

Is it just me or LapicKernelPanic doesn't work? The situation is that I am trying to boot OpenCore on 10.9.5, but can't get around that screen. Seems like the patch was found and patched (can verify in the video in the booter stage). Tried lapic_dont_panic=1 but seems like this is a boot-arg on newer OS (can verify with 10.13).

 

This is on an Arrandale laptop:
HP Pavilion DM4-1265DX, i5-460M, 4GB RAM.

[arsradu]

6 hours ago, markl18 said:

what does this error mean I never even saw this unable to get update memory

 

Are you booting off of an USB drive? What's your system hardware configuration? Can you add some details to your signature so we know what we're talking about.

 

If you're on a newer system, try to see if you have a driver called XhciDxe.efi in your Drivers folder and remove it. You don't need it for newer systems. I think this is for Ivy Bridge.

[arsradu]

2 hours ago, vit9696 said:

@arsradu@eSaF, it is not clear to me from the description of what is broken AudioDxe or OpenCore. Does older AudioDxe work with OpenCore from master?

 

From your reports I am starting to suspect that you have your audio codec not resetting across the reboots, and thus you get random audio failures. This is what you can try to troubleshoot by multiple reboots and/or cold resets (full poweroff and then power up).

 

You have a valid point.  We still need to determine whether it's AudioDxe or OpenCore. For what I can tell, I'd say it's AudioDxe. 

 

And, for what I can tell, this doesn't look random. In fact, with AudioDxe from AppleSupport 2.1.7 (the one I posted above, the one I was using with 0.5.8) combined with latest OC 0.5.9, I DO have boot sound. Reliably. 5 consecutive restarts with NVRAM reset in between. And no change to anything else.

 

The only thing I'm noticing (but that might be normal), is a slight delay in playing the sound immediately after NVRAM reset. If you fully boot up and then restart, it doesn't occur. But just after reset NVRAM, you will likely only hear the last part of the boot chime, right before the picker is displayed.

 

But as I said, it could be normal. Or could be something specific to my machine. And also, it's still better than the AudioDxe from 0.5.9, which, in my tests, doesn't play at all.

 

I did not try debug version of 0.5.9... Not sure why that would be any different. But I can try, and come back with more details.  

 

Also, I tried to narrow down the issue to a specific commit of AppleSupportPkg, but...just like with OpenCore, I can't build older commits... So, the only thing I can tell is that something happened from May 4th (the date of the 2.1.7 AppleSupport pkg, which, at least for me, when it comes to AudioDxe, works fine, including with OpenCore 0.5.9) and today.

 

I saw a few commits regarding AudioDxe in this timeframe. So...maybe one of those breaks something. But, as I said, I can't build, so I can't test.

 

UPDATE:

 

Looks like @MacNB was right. It does make a difference whether it's AudioDxe DEBUG or RELEASE. The Debug version works, indeed. But the Release one does not.

 

Here's the test results (all tests are using only the latest OC 0.5.9, just mixing Debug with Release):

 

OC release + AudioDxe release - doesn't work (no boot sound)

OC debug + AudioDxe debug - works
OC debug + AudioDxe release - doesn't work (no boot sound)
OC release + AudioDxe debug - works
 

Edited May 20, 2020 by arsradu

[vit9696]

@arsradu, actually, it is even more interesting. When I merged AudioDxe to OpenCorePkg a couple days ago, I did not merge the latest changes to AudioDxe. So AudioDxe version built from master a few minutes ago was exactly the one you got from AppleSupportPkg 2.1.7 release.

 

There were exactly four changes to AudioDxe:

https://github.com/acidanthera/AppleSupportPkg/commit/b0fd9471c9a1a3967875f3260631e91e6fc860c0 (no-op for XCODE5)

https://github.com/acidanthera/OpenCorePkg/commit/fd7cc9e325fce98528d438cdebc59954ef0a121d (new constants, basically no-op for old code)

https://github.com/acidanthera/AppleSupportPkg/commit/4225cc346914d0292f219da83bba027fdf2a8db0 (not present in master before 2020-05-20 10:53 MSK)

https://github.com/acidanthera/AppleSupportPkg/commit/5a698b8cb8a876c916c933f876477a5e75e97c98 (not present in master before 2020-05-20 10:53 MSK)

 

Here is where merged the last two AudioDxe changes into master:

https://github.com/acidanthera/OpenCorePkg/commit/3b051a797a60b79627437206fa6eec3238e68350

 

For this reason I am afraid it is your compilation setup that is broken. Are you sure that you use macbuild.tool (now named build_oc.tool) and Xcode 11.4.1? Perhaps testing my compiled version will be more practical.

 

 

 

AudioDxe-REL-3b051a79-edk2.zip

Edited May 20, 2020 by vit9696

[arsradu]

5 minutes ago, vit9696 said:

@arsradu, actually, it is even more interesting. When I merged AudioDxe to OpenCorePkg a couple days ago, I did not merge the latest changes to AudioDxe. So AudioDxe version built from master a few minutes ago was exactly the one you got from AppleSupportPkg 2.1.7 release.

 

There were exactly four changes to AudioDxe:

https://github.com/acidanthera/AppleSupportPkg/commit/b0fd9471c9a1a3967875f3260631e91e6fc860c0 (no-op for XCODE5)

https://github.com/acidanthera/OpenCorePkg/commit/fd7cc9e325fce98528d438cdebc59954ef0a121d (new constants, basically no-op for old code)

https://github.com/acidanthera/AppleSupportPkg/commit/4225cc346914d0292f219da83bba027fdf2a8db0 (not present in master before 2020-05-20 10:53 MSK)

https://github.com/acidanthera/AppleSupportPkg/commit/5a698b8cb8a876c916c933f876477a5e75e97c98 (not present in master before 2020-05-20 10:53 MSK)

 

Here is where merged the last two AudioDxe changes into master:

https://github.com/acidanthera/OpenCorePkg/commit/3b051a797a60b79627437206fa6eec3238e68350

 

For this reason I am afraid it is your compilation setup that is broken. Are you sure that you use macbuild.tool (now named build_oc.tool) and Xcode 11.4.1? Perhaps testing my compiled version will be more practical.

 

 

AudioDxe-REL-3b051a79-edk2.zip

 

Well, I am sure I used build_oc.tool... Xcode is 11.4.1 indeed. But I built it yesterday. :)) So...it doesn't have the commits you made today.

 

I'll try the AudioDxe from attachment and let you know.  

Edited May 20, 2020 by arsradu

[vit9696]

@makk, sorry if that was unclear. I meant you can edit Info.plist of VoodooPS2-related kexts. Like this: https://github.com/acidanthera/VoodooPS2/commit/535e81517355d1b6d2aaaaf24e6972de15006265

[arsradu]

@vit9696 the AudioDxe you attached DOES work. Including with my previous compilation of OC (I used release version, since that doesn't seem to make any difference anyway). So basically yesterday's OC with today's AudioDxe. And it does work.  

 

I'll also try building with today's updated sources to see if there's any difference compared to your attached AudioDxe. I'm assuming there won't be. 

 

Speaking of which.

 

Here's a side-by-side comparison between AudioDxe debug and release from Yesterday. Both compared with AudioDxe Release from AppleSupportPkg 2.1.7 downloaded a while ago.

 

From left to right: AudioDxe from AppleSupport 2.1.7 -> AudioDxe from yesterday's 0.5.9 RELEASE -> AudioDxe from yesterday's 0.5.9 DEBUG.

They're all different sizes. Which makes me think their content is probably also pretty different, too.

 

[vit9696]

@arsradu please upload your compiled release binary from master if it does not work for you.

[arsradu]

11 minutes ago, vit9696 said:

@arsradu please upload your compiled release binary from master if it does not work for you.

 

Testing in progress... MD5 hash is identical to the one of your build. So I'm assuming the result will be the same.

 

MD5 (/Desktop/AudioDxe.efi) = f61d54819a4b38315ffd9550c375d638

MD5 (/Desktop/OpenCorePkg-master/Binaries/OpenCore-0.5.9-RELEASE/EFI/OC/Drivers/AudioDxe.efi) = f61d54819a4b38315ffd9550c375d638

 

I'll update you with the results in a few minutes.  

Edited May 20, 2020 by arsradu

[insanefrancis]

10 hours ago, arsradu said:

 

If you select MacOS from Windows BootCamp, then MacOS will become your default boot and it should boot into it, yes. If it's still set to Windows, then it will just boot back into Windows, since that's the default boot option.

 

If you don't select anything and reset NVRAM, the default option will be the first one in your boot picker. Could be wrong, but this was the case in my experience.

 

As for Windows...I don't know. I never tried installing it this way. So...it could be fine.

 

You can check it out from Terminal, by typing:

diskutil list

I think there's a way from Windows, as well. Disk Manager or something like that. Or third party solutions like Partition Wizard.

 

But if you're already on the Mac, I guess diskutil might be the closest option. You can post the output here, if you want.

 

I have confirmed that my Windows installation is in UEFI mode.

 

I have noticed as well that in Windows, some of the informations are coming from the macOS settings. See first image. Is this normal? Does it have any effect on Windows part?

[arsradu]

@vit9696 test completed. Results below.

 

Scenario 1:

AudioDxe from today's Release version (identical to yours) + OC from yesterday (also Release version) = all good

 

Scenario 2:

everything (AudioDxe + OC) from today = all good.

 

Test PASSED.

 

Also, I have a question, which is not related to AudioDxe in any way, but it could be related to OC, although I think SMBIOS might have something to do with this, as well...

 

When booting, it stays a lot (for about 10 seconds - update: 17s to be exact, from the time it reaches the middle, till the time it moves on to second stage) with loading bar in the middle, before switching to second stage and booting to Desktop. Any idea why? Booting off of SSD, by the way. Not NVMe SSD. SATA. But still SSD.

 

Does the SMBIOS have anything to do with it? I'm using iMac14,2 now. But I don't remember having this issue with iMacPro1,1... I mean, it wasn't crazy fast. But...I don't think it was this slow either.

 

Again, not sure this has anything to do with OC itself...or maybe something else. Just curious if you had different results in boot times between one SMBIOS and the other.

 

 

Edited May 20, 2020 by arsradu

[MacNB]

20 minutes ago, insanefrancis said:

 

I have confirmed that my Windows installation is in UEFI mode.

 

I have noticed as well that in Windows, some of the informations are coming from the macOS settings. See first image. Is this normal? Does it have any effect on Windows part?

 

Windows System info displayed is correct. It's what OC passes to Windows (just like on a real Mac).

In the Config file if you set SpoofVendor=YES, you will see ACIDANTHERA, if you set it NO then the BIOS DATA (MSI, etc) will be displayed for the System Manufacturer. The other data will be the same.

 

Your Windows drive has it's EFI partition as partition 2 which is strange. Normally for GPT type partition scheme, EFI partition is the first partition.

[arsradu]

I agree. Partition order seems off. Also, your EFI is named "NO NAME" instead of EFI. And it's smaller than usual. Should be around 200MB, yours is around 100MB.

 

For comparison, this is what my BootCamp Windows drive looks like (you can ignore the Backup partition I made).

 

[viorel]

AdviseWindows
Type: plist boolean
Failsafe: false
Description: Forces Windows support in FirmwareFeatures.
Added bits to FirmwareFeatures:
• FW_FEATURE_SUPPORTS_CSM_LEGACY_MODE (0x1) - Without this bit it is not possible to reboot to Windows
installed on a drive with EFI partition being not the first partition on the disk.
• FW_FEATURE_SUPPORTS_UEFI_WINDOWS_BOOT (0x20000000) - Without this bit it is not possible to reboot to
Windows installed on a drive with EFI partition being the first partition on the disk.