Bug 2259197

Summary:	dnf install /usr/sbin/grubby installs sdubby, even on a non-EFI GRUB 2 system
Product:	[Fedora] Fedora	Reporter:	Alexander Sosedkin <asosedki>
Component:	sdubby	Assignee:	Jeremy Linton <jeremy.linton>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	39	CC:	cllang, jeremy.linton, jpazdziora, omosnacek
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-03-28 21:07:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexander Sosedkin 2024-01-19 13:04:07 UTC

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.

Comment 1 Jeremy Linton 2024-01-19 20:56:49 UTC

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?)

Comment 2 Alexander Sosedkin 2024-01-22 09:58:45 UTC

`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.

Comment 3 Ondrej Mosnáček 2024-01-23 08:51:44 UTC

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

Comment 4 Jeremy Linton 2024-02-10 01:13:45 UTC

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.

Comment 5 Jan Pazdziora (Red Hat) 2024-03-18 10:26:59 UTC

It seems as of today even grubby (package name) is affected: bug 2269992.

Comment 6 Jeremy Linton 2024-03-28 21:07:49 UTC


*** This bug has been marked as a duplicate of bug 2269992 ***