I saw the update had landed in rawhide, so I tested it in one of my use cases: network booting. I tried from VMs configured for BIOS-TFTP, UEFI-TFTP, and UEFI-HTTP (UEFI with Secure Boot enabled and disabled). All fail. With BIOS, it loads core.0 via TFTP, prints "Welcome to GRUB!" (in reverse video), and stops. With UEFI (TFTP or HTTP, with shimx64.efi first), it loads grubx64.efi, prints "dynamic_load_symbols 0x7d97e000", although the number is different for different methods (guess it's an address?), and stops. This is with files from grub2-2.12-3.fc41 and shim-x64-15.8-3. Changing back to the files from grub2-2.06-119.fc40 works. Reproducible: Always
(In reply to Chris Adams from comment #0) > I saw the update had landed in rawhide, so I tested it in one of my use > cases: network booting. I tried from VMs configured for BIOS-TFTP, > UEFI-TFTP, and UEFI-HTTP (UEFI with Secure Boot enabled and disabled). All > fail. > > With BIOS, it loads core.0 via TFTP, prints "Welcome to GRUB!" (in reverse > video), and stops. > > With UEFI (TFTP or HTTP, with shimx64.efi first), it loads grubx64.efi, > prints "dynamic_load_symbols 0x7d97e000", although the number is different > for different methods (guess it's an address?), and stops. > > This is with files from grub2-2.12-3.fc41 and shim-x64-15.8-3. Changing back > to the files from grub2-2.06-119.fc40 works. > > Reproducible: Always Hi Chris, We are aware of these issues and currently working to solve them. I let you know any update.
Sounds good! I know this was a big change, let me know if there's anything I can do to help with testing (debugging GRUB code itself is probably beyond my ability unfortunately).
(In reply to Chris Adams from comment #2) > Sounds good! I know this was a big change, let me know if there's anything I > can do to help with testing (debugging GRUB code itself is probably beyond > my ability unfortunately). Indeed, a big change. So far we have this issue and two reported by bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2024-a067416d33
team, latest fedora rawhide has been update with patch fixes [1], please re-test using [2]. Internally we have tested several netboot scenarios (pxe, http, ipv4, ipv6, with and without secure-boot, on all supported archs) and all passing fine. In case any issue, please report it. [1] https://src.fedoraproject.org/rpms/grub2/pull-request/104# [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=122703223
I tested BIOS, UEFI-PXE, and UEFI-HTTP (all over IPv4) successfully. Secure Boot failed with a security error (I guess this scratch build isn't signed with a key Fedora's shim recognizes).
Also hit this when doing a PXE installation of the Fedora 41 Beta on AArch64 (grub2-efi-aa64-2.12-4.fc41), updating to grub2-efi-aa64-2.12-6.fc42 worked as expected.
Leo, that build is a scratch build. There doesn't seem to have been an official build since 2.12-4 for F41 or Rawhide. Is there a plan to do official builds with the fix? Thanks.
Huh, it seems like there was a 2.12-6.fc42 build done - https://koji.fedoraproject.org/koji/buildinfo?buildID=2543243 - but somehow it was never submitted as an update, and is tagged only for garbage collection. Not sure how that happened. Was it built on a side tag?
(In reply to Adam Williamson from comment #8) > Huh, it seems like there was a 2.12-6.fc42 build done - > https://koji.fedoraproject.org/koji/buildinfo?buildID=2543243 - but somehow > it was never submitted as an update, and is tagged only for garbage > collection. Not sure how that happened. Was it built on a side tag? The problem was that I did not have permissions to launch official build as seen here https://koji.fedoraproject.org/koji/taskinfo?taskID=123164869 but now I have access and just launched one, triggering the corresponding update https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb38ed83cb
ohhh, right, of course, somehow I did not link up that conversation in my head :D
(In reply to Leo Sandoval from comment #9) > (In reply to Adam Williamson from comment #8) > > Huh, it seems like there was a 2.12-6.fc42 build done - > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2543243 - but somehow > > it was never submitted as an update, and is tagged only for garbage > > collection. Not sure how that happened. Was it built on a side tag? > > The problem was that I did not have permissions to launch official build as > seen here https://koji.fedoraproject.org/koji/taskinfo?taskID=123164869 but > now I have access and just launched one, triggering the corresponding update > https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb38ed83cb Adam, my bad, last update went for ELN but not f41 because the latter failed https://koji.fedoraproject.org/koji/taskinfo?taskID=123550898 . We (well, nfrayer) are planning to merge soon another patch on rawhide which would bump the spec version, following by an official build.
FEDORA-2024-2e76a9ff56 (grub2-2.12-9.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-2e76a9ff56
Since there's only five days to Final freeze, proposing this as an FE in case it doesn't make it to stable by then. Fixing netboot issues is obviously a good thing to have in release if possible.
FEDORA-2024-2e76a9ff56 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2e76a9ff56` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2e76a9ff56 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-2e76a9ff56 (grub2-2.12-9.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.