-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenCore default boot selection doesn't work with OVMF. #1050
Comments
No log — no bug. |
Not sure what kind of log you would need for this, but I will upload a Debug OpenCore log I guess. |
Yes, need a debug OpenCore log after the selection and EFI folder. |
Here you go.... |
Here is the EFI folder. |
Not all the drivers are debug, so the log is incorrect. |
Compiled it again and updated all the drivers except HFSPlus.efi to the Debug build ones because I can not find a Debug version of HFSPlus. Switch to |
macOS has:
OVMF has:
NVMe/SasEx we do fix, but PciRoot 1/0 are still different. Did you reconfigure your VM between choosing the operating system and saving the log? It looks like the order of PCI controllers changed to me. |
I did not, I compiled the Debug version of OpenCorePkg and updated my EFI with the Debug drivers and went to System Preferences > Startup Disk and selected MacOS then when it asked to restart I clicked Restart. On reboot, I hit F2 for OVMF boot menu and selected the USB drive with the Debug OpenCore EFI on it and booted it, then once OpenCore boot menu loaded, It still defaulted to the first in the list which was my EFI on my actual drive and had to manually select MacOS from the boot menu to boot into macOS. |
Is this the latest version of OVMF? Below I attached the latest NOOPT version and the latest NOOPT version with serial output. Please check whether the issue is reproducible in the first version and provide the boot log with the second version. Also, please provide the configuration you use for your virtual machine. Do you use multiple PCI bridges? What is the reason for this? |
Checking the OVMF version you upload but here is the vm.conf file settings.
|
Could you attach not the vm.conf, but the resulting arguments passed to QEMU? Also, please make SysReport with ACPI tables. |
I think this is what you are talking about....
|
When I try to use either one of these OVMF_CODE.fd and OVMF_VARS.fd, I do not get any display. |
Nevermind I figured it out on the no display thing, issue was reproduced with NOOPT version and here is the debug log got the NOOPT-Serial version. |
Here is the SysReport with ACPI tables. |
Serial, I mean prior to OpenCore. When it boots it prints stuff to stdout. E.g. you can add an argument to log serial to file like -serial /path/to.txt |
Here is the output with NOOPT-Serial and using Debug OpenCore after selecting macOS as the Startup Disk. |
OVMF gets ACPI tables straight from QEMU: sb_scope = aml_scope("_SB");
dev = aml_device("PCI0");
aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
aml_append(dev, aml_name_decl("_UID", aml_int(1)));
aml_append(dev, build_q35_osc_method()); This is obviously wrong, as dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A06")));
aml_append(dev,
aml_name_decl("_UID", aml_string("CPU Hotplug resources"))
); All in all, replacing the line in the first code snippet (twice) by UID 0 and recompiling QEMU should solve the issue: aml_append(dev, aml_name_decl("_UID", aml_int(0))); Given all that we need to decide:
@pavo, try this change and report whether it works for you. |
This is now a confirmed bug in QEMU, tracked in the mailing list here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg724254.html We need to provide them the details whether the suggested fix works to get this merged into the next version of QEMU. @Pavo-IM, do you need extra help with rebuilding QEMU with this change? |
I will try but it might take sometime since I have never built Qemu before, I am reading the docs as we speak. |
Rebuilding QEMU is straightforward, you just run configure and specify --prefix argument to the installation directory. However, if you have a specific Linux distribution, like Debian or Ubuntu, I believe you may be able to utilise easier way to customise the build process. See this link for an example: https://unix.stackexchange.com/questions/324680/how-to-apply-a-patch-in-a-debian-package If you tell us the exact distribution you use we could try to help further. |
Roger, the exact distro I am using is Debian 10 (Buster). |
Try this please (you will need to replace system-installed binary, in /usr/bin I guess). |
Getting this error after replacing the
|
Are you sure you have the latest version of Debian? Please run |
Yeah, Proxmox is a custom made Debian 10 distro, it is using |
If you upload qemu-system-x86-64 original binary, I can modify it similarly. |
Here is the original binary. |
@vit9696 The patched binary worked beautifully. Default boot selection is working as intended now, thank you so much. I will submit this patch to Proxmox devs so they can add it to their upstream repo. |
It will be good indeed if they backport these changes to your distro. We will report it to QEMU team, so that the change lands to master. We found a similar issue with Intel G33, and might actually add a workaround to OpenCore as well, but this is out of the scope of this issue. Closing. |
macOS uses ACPI UIDs to build the DevicePath for NVRAM boot options, while OVMF firmware gets them via an internal channel through QEMU. Due to a bug in QEMU ACPI currently UEFI firmware and ACPI have different values, and this makes the underlying operating system unable to report its boot option. The particular node in question is the primary PciRoot (PCI0 in ACPI), which for some reason gets assigned 1 in ACPI UID and 0 in the DevicePath. This is due to the _UID assigned to it by build_dsdt in hw/i386/acpi-build.c Which does not correspond to the primary PCI identifier given by pcibus_num in hw/pci/pci.c Reference with the device paths, OVMF startup logs, and ACPI table dumps (SysReport): acidanthera/bugtracker#1050 In UEFI v2.8, section "10.4.2 Rules with ACPI _HID and _UID" ends with the paragraph, Root PCI bridges will use the plug and play ID of PNP0A03, This will be stored in the ACPI Device Path _HID field, or in the Expanded ACPI Device Path _CID field to match the ACPI name space. The _UID in the ACPI Device Path structure must match the _UID in the ACPI name space. (See especially the last sentence.) Considering *extra* root bridges / root buses (with bus number > 0), QEMU's ACPI generator actually does the right thing; since QEMU commit c96d928 ("i386/acpi-build: more traditional _UID and _HID for PXB root buses", 2015-06-11). However, the _UID values for root bridge zero (on both i440fx and q35) have always been "wrong" (from UEFI perspective), going back in QEMU to commit 74523b8 ("i386: add ACPI table files from seabios", 2013-10-14). Even in SeaBIOS, these _UID values have always been 1; see commit a4d357638c57 ("Port rombios32 code from bochs-bios.", 2008-03-08) for i440fx, and commit ecbe3fd61511 ("seabios: q35: add dsdt", 2012-12-01) for q35. Cc: qemu-stable@nongnu.org Suggested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Vitaly Cheptsov <vit9696@protonmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Currently using Proxmox which uses Qemu+KVM and selecting Default boot disk in macOS does not set the default boot item in OpenCore boot menu. It always defaults to the first item in the list no matter the order.
The text was updated successfully, but these errors were encountered: