Fedora-Server-dvd-x86_64-40-20240314.n.0.iso installs sdubby by default whereas Fedora-Server-dvd-x86_64-39-1.5.iso still installs grubby. Reproducible: Always Steps to Reproduce: 1. Use Fedora-Server-dvd-x86_64-40-20240314.n.0.iso to install a system 2. rpm -qa | grep grubby Actual Results: "rpm -qa | grep grubby" shows empty result. Expected Results: "rpm -qa | grep grubby" shows installed grubby. All beakers jobs have sdubby installed by default for both F39, F40 and F41.
Ugh. Will check tomorrow, but I can believe it, especially since sdubby provides grubby, and at a higher version than the real grubby: [root@xps13a adamw]# dnf repoquery --provides sdubby Last metadata expiration check: 1:16:23 ago on Sun 17 Mar 2024 10:18:46 PM. config(sdubby) = 1.0-6.fc40 grubby = 8.41 sdubby = 1.0-6.fc40 [root@xps13a adamw]# dnf repoquery --provides grubby Last metadata expiration check: 1:16:28 ago on Sun 17 Mar 2024 10:18:46 PM. grubby = 8.40-75.fc40 grubby(x86-64) = 8.40-75.fc40 this seems like a problem :/ we may have to kick it off the media entirely again, I guess. Jeremy, thoughts?
*Why* does sdubby provide grubby, anyway? It seems unnecessary. The only thing in the distro which unconditionally requires "grubby" is ec2-hibinit-agent .
Hello, this change impacted our CI heavily. Is there a chance it would be reverted?
See also #2259197, where sdubby providing grubby breaks fips-mode-setup. This broke our test setup for FIPS in January. Maybe sdubby should just stop providing grubby, considering this is the second time things fail because of it.
This is also affecting arm images. I think this is actually a blocker.
`sdubby` was also excluded from `fedora-kickstarts` a few months ago, likely due to the same problem raised here [1] and we removed it in image builder as well as it was breaking our builds there too [2]. [1]: https://pagure.io/fedora-kickstarts/c/ffd1a4f38781d73345c517c2fa2a1e8d17b77fc5?branch=main [2]: https://github.com/osbuild/images/pull/187/commits/eb0a31f02067cd919b4c399269869fdab2b589a4
For context, this bug is a follow-on from the very longstanding https://bugzilla.redhat.com/show_bug.cgi?id=2243872 , where the current situation was planned out. The intent was that having sdubby not in kickstarts but in the core comps group but only as an 'optional' component would produce the desired situation, but I suspect this provision is screwing things up.
(In reply to Adam Williamson from comment #7) > For context, this bug is a follow-on from the very longstanding > https://bugzilla.redhat.com/show_bug.cgi?id=2243872 , where the current > situation was planned out. The intent was that having sdubby not in > kickstarts but in the core comps group but only as an 'optional' component > would produce the desired situation, but I suspect this provision is > screwing things up. If it's explicitly pulled in via comps, it shouldn't then need/have a provides for grubby, and the provides is wrong as it's not really compatible (I've not looked at actual provides, as I would have thought that would be pulled in for standard upgrades too).
IIUC, rpm/libsolv use different logic on update compared to first install. The idea is that on first install they should try and pull in the "best" candidate, but once you have a package providing a capability installed, they assume you want to keep that one installed, even if it's not their idea of the "best" choice (on the grounds you probably chose it yourself for a reason). sdubby's current status in comps is that it's in anaconda-tools, but only as 'optional'. The intent is to ensure it winds up on the Server DVD repo (so you can use `inst.sdboot` with Server DVD) but doesn't actually get installed into live images as part of that group (because on things like live images we can only have one of the two, not both).
It also caused complications in the kiwi descriptions, which I implemented a workaround: https://pagure.io/fedora-kiwi-descriptions/c/31f9f8a7437ffe6cb5a9a761dfac62949f8b07ff
So on the package review - https://bugzilla.redhat.com/show_bug.cgi?id=2134972 - Zbigniew wrote that lots of things depend on grubby, which seems to be why this provide was added. I asked him about that comment and he wrote: "At some point, kexec-tools had a hard requirement on grubby, and systemd had a dependency on kexec-tools (for /usr/sbin/kexec). This was dropped at some point. So yeah, now it's much less." given that, and all the problems people are having with this, I'm inclined to do a new build of sdubby without the provide of grubby and roll that into a new candidate compose. Would be good to have Neil's opinion first, if possible, though.
For the record, the dep in kexec-tools was changed to "recommends" in August 2021.
Discussed during the 2024-03-18 blocker review meeting: [1] The decision to classify this bug as a AcceptedFreezeException (Beta) was made: "It's clearly not intended behaviour and cannot be fixed with a post-release update, we want Beta installs to get grubby not sdubby unless they're using inst.sdboot." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-03-18/f40-blocker-review.2024-03-18-16.01.log.html
FEDORA-2024-6c96f55fbd (sdubby-1.0-7.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6c96f55fbd
FEDORA-2024-6c96f55fbd has been pushed to the Fedora 40 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-6c96f55fbd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6c96f55fbd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
We need to test installs (and any other affected workflows) with Beta-1.9 and see how this goes - https://kojipkgs.fedoraproject.org/compose/40/Fedora-40-20240319.2/compose/ . Note the change is not yet pushed *stable* so tests that use 'F40 stable' will still get the old sdubby.
Figured out a wrinkle with this: it seems to affect only *BIOS* installs of Server. A Server install of 20240314.n.0 nightly to UEFI gets grubby. One to BIOS gets sdubby. Now I've worked that out, I can check if it's fixed in Beta-1.9.
(In reply to Adam Williamson from comment #17) > Figured out a wrinkle with this: it seems to affect only *BIOS* installs of > Server. A Server install of 20240314.n.0 nightly to UEFI gets grubby. One to > BIOS gets sdubby. Now I've worked that out, I can check if it's fixed in > Beta-1.9. That doesn't sound right, aarch64 doesn't support BIOS and only supports UEFI yet we got sdubby, and systemd-boot doesn't actually support BIOS, it only supports UEFI.
I'm only considering x86_64 here. I have no opinion on whether it sounds right or not, but it is definitely what happens. The anaconda bootloader code is laughably complicated, probably just some different path it goes down winds up with this result somehow. I've no idea what happens on aarch64.
(In reply to Adam Williamson from comment #19) > I'm only considering x86_64 here. I have no opinion on whether it sounds > right or not, but it is definitely what happens. I wonder if there's some inverted logic somewhere.
Not sure, but this does seem to have fixed it. A BIOS install of Beta-1.9 Server DVD has grubby, not sdubby. I also confirmed that a Beta-1.2 BIOS install had sdubby.
I'm curious to ask why sdubby gets installed when it Provides grubby. My naive thinking is somewhere grubby is requested but in this case, shouldn't grubby be preferred over sdubby?
(In reply to Peter Robinson from comment #8) > (In reply to Adam Williamson from comment #7) > > For context, this bug is a follow-on from the very longstanding > > https://bugzilla.redhat.com/show_bug.cgi?id=2243872 , where the current > > situation was planned out. The intent was that having sdubby not in > > kickstarts but in the core comps group but only as an 'optional' component > > would produce the desired situation, but I suspect this provision is > > screwing things up. > > If it's explicitly pulled in via comps, it shouldn't then need/have a > provides for grubby, and the provides is wrong as it's not really compatible > (I've not looked at actual provides, as I would have thought that would be > pulled in for standard upgrades too). Thinking this through a little more sdubby should have never provided grubby, what they both should do is provide system-kernel-updater (or something like that) which then anaconda/kexec/etc then require so that something gets pulled in but if one is in the requires list it wins over.
yes, but that's all water under the bridge at this point. coiby: figuring that out gets complicated, and since it seems fairly clear this change fixes it, I'm not really inclined to dig deeper into it at this point.
FEDORA-2024-6c96f55fbd (sdubby-1.0-7.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
This is a duplicate of 2249197, although it sounds like its grown. And the provides was added to fix 2250498, which is the initial setup on machines using initial-setup-gui which has a grubby dependency.
The duplicate is: https://bugzilla.redhat.com/show_bug.cgi?id=2259197 Which, yes this should only happen on platforms that don't explicitly require grubby (aka BIOS because its not in the anaconda request list) which is a anaconda bug because I only put grubby in the EFI platforms lists.
Jeremy: I don't think 2250498 is why the provides was *added*. It's why the provide was *versioned*.
Right, the provides was added initially because there were various packages that needed grubby, but I updated it with a "hacky" version get around the the anaconda conflicts issue. But as you pointed out elsewhere the situation has changed over the past couple years and there are few packages requiring grubby anymore, so its not a problem. And so it seems, your right just dropping the provides is likely going to work fine.
*** Bug 2259197 has been marked as a duplicate of this bug. ***