dnf install /usr/sbin/grubby installs sdubby, even on a non-EFI GRUB 2 system Reproducible: Always Steps to Reproduce: 1. Take a Fedora 39 machine installed without EFI, using GRUB 2 to boot 2. dnf -y install /usr/sbin/grubby 3. have updateloaderentries symlinked as /usr/sbin/grubby 4. try to do something with grubby, say, fips-mode-setup --enable Actual Results: I get a bootloader I haven't asked for and grubby is actually sdubby printing weird messages like Couldn't find EFI system partition. It is recommended to mount it to /boot or /efi. Alternatively, use --esp-path= to specify path to mount point. grep: boot=UUID=bab8e025-3ac8-442f-9d3e-56aa6f2846ad: No such file or directory Expected Results: I get grubby and grubby works, supporting the bootloader I actually use and all 24 options of grubby instead of just 3 I'm very much not against systemd-boot, it's awesome. I'm also glad sdubby exists and provides limited compatibility with grubby. I'm probably also OK with having a way to have sdubby invokable as grubby, it makes sense for systems that are actually using systemd-boot. But dnf sneaking in sdubby over actual grubby, on a system using GRUB 2, IMO, a bug.
I'm guessing this has something to do with the provides stanza which was bumped to fix sddm and dnf is picking it over grubby even though its not marked as obsoleting grubby.. hmmm. Let me spend some time looking at it. Presumably instead of `dnf -y install grubby` its fully qualified (ex `dnf install grubby-8.xx-yy it works?)
`dnf -y install grubby` installs grubby, and so does `dnf -y install grubby-8.40-73.fc39`. It's that the `dnf -y install /usr/sbin/grubby` prefers sdubby, and, given the choice between the two, I'd really prefer dnf to either pick one that matches the bootloader I have installed or just unconditionally install the real deal.
The problem with [1] is that there is not (yet) grubby 8.41+ in rawhide. The latest version is grubby-8.40-74.fc40, so it seems that sdubby sometimes takes precedence. anaconda-core conflicts with 'grubby < 8.40-10', so this issue should be mitigated by sdubby providing just a slightly higher version. For example 'Provides: grubby = 8.40-10.sdubby'. [1] https://src.fedoraproject.org/rpms/sdubby/c/a1471ab43e366ab23d8cd91ed650175f13d41776?branch=rawhide
Just as a comment, the best plan is probably just to bump the grubby release, backing sdubby down will probably cause more problems. I've been planning on opening a "bump the grubby" PR this week, I should get to it in the next day or two.
It seems as of today even grubby (package name) is affected: bug 2269992.
*** This bug has been marked as a duplicate of bug 2269992 ***