I believe you, but... i didn't touch the grub2 code, this is just a rebuild against the newer fuse3 API. Can you open a bug against grub2?

Isn't grub2 one of those special packages that only select few people can build "correctly", otherwise it won't get signed for secure boot?

@lsandova

can't find the right FAS name for jstancek.

The serial console output fortunately captures this error, which doesn't appear in the pre-update boot, or in passed tests:

00BdsDxe: loading Boot0003 "Fedora" from HD(1,GPT,FCCD1E98-E89E-4571-A00F-02D3BB70E0D4,0x800,0x12C000)/\EFI\fedora\shimx64.efi
BdsDxe: starting Boot0003 "Fedora" from HD(1,GPT,FCCD1E98-E89E-4571-A00F-02D3BB70E0D4,0x800,0x12C000)/\EFI\fedora\shimx64.efi
error: ../../grub-core/kern/misc.c:grub_strtoull:606:unrecognized number.

GRUB version 2.12

BTW, rmdepcheck also found some things that you missed rebuilding, @spot :

Dependencies of other packages that would be BROKEN by the tested packages:
package: apfs-fuse-0-30.20200928gitee71aa5.fc43.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libfuse3.so.3()(64bit)
  libfuse3.so.3(FUSE_3.0)(64bit)
package: bindfs-1.18.3-1.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libfuse3.so.3()(64bit)
  libfuse3.so.3(FUSE_3.0)(64bit)

Added the missing deps. Still not touching grub.

thanks. indeed grub still broken. Guess we need the maintainers to figure out what they broke. Might need to ping them internally, not sure they read bodhi mail.

Note this update also has at least one conflict - gvfs - with the massive ffmpeg 8 rebuild that is currently in-flight. that one should land soon, so anything in that update that is also in this update will need to be re-done in this update so it's built against both ffmpeg 8 and fuse 3.17.4.

@adamwill sorry for missing the notifications on this one. Let me investigate what's going on

I did a new gvfs build.

@adamwill, as you pointed out, we missed several unbuilds commits but in case there is mundane reason[*]. BTW, scratch builds work fine [1] so this is confusing.

Below are the related commits and perhaps 2.12-42 or 2.12-46 may have introduced this issue but I am not seeing immediately how. The rest of the patches are not related at all but of course I have to prove it.

Besides the debug log provided in previous comments, is there other serial/console log to look?

• Tue Nov 04 2025 Tom Callaway spot@fedoraproject.org - 2.12-46

• rebuild for new fuse3

• Wed Oct 15 2025 Leo Sandoval lsandova@redhat.com - 2.12-45

• Include upstream blsuki related patches

• Mon Sep 15 2025 Leo Sandoval lsandova@redhat.com - 2.12-44

• Include function name on debug print function

• Fri Aug 29 2025 Nicolas Frayer nfrayer@redhat.com - 2.12-43

• gen_grub_cfgstub: Removed output messages

• Wed Aug 20 2025 Jan Stancek jstancek@redhat.com - 2.12-42

• move 55-set-boot-entry.install to 95
• Related: #2389020

[*] my fedpkg build hangs at some point and perhaps this has to do with my IP provider not support IPv6

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=138860636

All we really know is that after we install the grub2 update and reboot, the system (a UEFI VM) boots to the grub menu but the grub menu does not contain the expected boot menu entry for booting Fedora, instead it contains only the menu entry for running the UEFI firmware setup. And there's that strtoull error in the serial console log.

I can hack the test up to check whether the Fedora kernel entry is actually there in the grub/bls config - I suspect it is and the problem is that grub is choking on parsing it for some reason so it's not showing it, but I haven't checked for sure.

Beyond that, you'd have to let us know how to get grub to output more verbose debugging info, then we can hack up a test to do that. We can also try to reproduce in a local VM.

OK, so I can reproduce this in a local UEFI (non-SB) VM. Just do a minimal Rawhide install, download the update packages, update, and reboot.

The grub config file has the blscfg line which should generate entries from the BLS snippets, but obviously...isn't, somehow. The BLS snippets are there.

I can get to the grub console, but no idea what to do there to diagnose the problem. If I run blscfg nothing appears to happen - there's no output, either good or bad.

Please let me know what I can do to help diagnose the problem.

@adamwill

let me start debugging.

BTW, in case you want to debug it further, on a running system, at the prompt, type

$ grub2-editenv - set debug=all,-lexer,-scripting

then reboot. That indicates high verbosity except the parsing stuff. Expect lots of log.

I got some logs for @lsandova and it seems the problem is identified now, so hopefully a fix will come soon.

regenerated with a fixed (we hope) grub2.

ugh, now fuse-sshfs needs rebuilding again. doing it.

yay, tests are finally passing...

Hah, here's another dep we both missed:

DEBUG util.py:459:    - package s390utils-2:2.38.0-2.fc43.s390x from build requires s390utils-base = 2:2.38.0-2.fc43, but none of the providers can be installed
DEBUG util.py:459:    - conflicting requests
DEBUG util.py:459:    - nothing provides libfuse3.so.3()(64bit) needed by s390utils-base-2:2.38.0-2.fc43.s390x from build
DEBUG util.py:459:    - nothing provides libfuse3.so.3(FUSE_3.0)(64bit) needed by s390utils-base-2:2.38.0-2.fc43.s390x from build

looks like Dan happened to build a new version of that today, though, so that should go away in the next compose.