Missing Kernel after Upgrade

https://fedoraproject.org/wiki/Test_Day:2024-01-29_KDE_Plasma_6_Test_Week

You’ve been a good guide. I am relying on you. Villy Kruse raised an interesting point, too.

I read about secure boot. Apparently, it can only be disabled in the firmware (I have seen the switch there). However, the Fedora wiki secure boot page states:

It can be disabled permanently by running: sudo mokutil --disable-validation

Would I have to do both: disable in firmware and run this program?

What would be the impact? Would my system still run without taking further measures?

There is another thing I certainly would need to do, and that is reinstall grubby and get rid of sdubby. I would do this tomorrow, as soon as Fedora 40 is branched and the repos are active.

On the other hand, it is clear that Fedora is migrating to systemd-boot. After all, that is why grubby got replaced by sdubby. This change will certainly remain in Fedora 40 branched. Why would I want to revert? Is it because I have not done a clean install, but simply an upgrade to a newer release?

And the main problem remaining: how do I get rid of the ‘dead’ grub boot menu and get an active boot menu from the new systemd-boot method?

I will have a look at the article you reference.

What do you suggest? Revert or go with the flow to sdboot?

100% user choice. I have no opinion until after I try out the differences. At present I am comfortable with grub.

The mokutil tool is able to write to the uefi bios on most systems. Whether to use mokutil or directly make the change within bios is user choice. Note that mokutil is limited to performing functions related to ‘management of keys’ and does not intentionally make other changes within the bios.

There has been a new development. I deleted the Microsoft directories last night, as you recommended, and expanded /boot/efi to 600MiB. As you may recall, I also had a partition containing Fedora 38. I decided to increase it’s size, as you had recommended, into the space that had become vacant (I have 2 such partitions of equal size that I alternately use for root, so that I always have an older release on hand, just in case). I used the default KDE Partition Manager, as I am familiar with the program. I instructed the program to move it right after the newly expanded /boot/efi partition and expand in size to fill in half of the vacant area. I clicked apply and it gave me an error (it was unmounted). I tried again: same thing. I decided to reboot the computer and now everything was haywire: I was put into emergency mode and had to type ctrl-D and log in as root. I was instructed to check the journal and that the selinux context for /dev/tty1 was incorrect and permission was denied. I tried to reset the context: it failed. Then, I tried to relabel the entire system with .autorelabel and reboot, but to no avail. I went into the firmware and disabled Secure Boot. No matter what I tried, I could no longer boot the system. I was at wits end, when at last I remembered I might still have the Fedora 39 install image on the USB stick I use for installation. I was in luck and reinstalled Fedora 39 and did a reformat of /boot/efi (hence it is totally cleaned of any cruft). I am now off Rawhide, but have learned a little about what’s to come with sdboot in Fedora 40. I will likely do a clean install into the vacant partition, so hopefully I will have a choice between either grub2 or sdboot. My preference would be for the latter, but only if it is fully compatible with secure boot (or at least there are clear instructions on how to procede).

Needless to say, this was a harrowing experience. I stretched my knowledge to the utmost.

On the plus side, I learned about the /boot/efi partition, learned I could (and should?) reformat it when doing a new installation, got my other partitions resized and future-ready, and have some idea about both systemd-boot and Secure Boot.

I hope I am well prepared for Fedora 40, as sdboot/sdubby is new territory that I do not know how to traverse.

With sd-boot you lose the shim and the mok including mokutil. So disabling secure boot is only done in the UEFI firmware.

Don’t expect sd-boot to the default in Fedora 40.

I think it will be a massive improvement over grub once it is done. It makes sense to have the kernels grouped by machine-id. If you have numerous OSes they would likely be in their own directories. It looks streamlined and easy to understand.

I recall the switch from lilo to grub and the particularly rough transition from grub to grub2. I believe it didn’t support some filesystems in common use at first and also having to generate the boot menu by running another program.