On Tue, Sep 9, 2025, at 11:06 AM, Matthew Jenkins via desktop wrote: > Hi Workstation Sig, > > Not sure where this should go but I figure the people most likely to > need this are desktop/workstation users. > > Problem statement: > The 'rescue' kernel image breaks after distro upgrades or so many > kernel upgrades. > > The rescue kernel relies on the file system outside boot to be in a > state consistent with the rescue image itself. These files are > regularly cleaned up when kernel rpm upgrades are completed. Thus after > so many distro upgrades or just kernel upgrades, the rescue image no > longer works. There is currently no automated way to regenerate the > rescue image. And good luck telling grandma when her PC fails to boot > 'You should have regenerated your rescue image every n-th kernel > upgrades'. Just for a bit of background for all readers: During installation, in the post-install phase, the /boot/vmlinuz file is duplicated, resulting in: vmlinuz-$version.$release.$arch vmlinuz-0-rescue-$machineid Two initramfs images are created: Host only: initramfs-$version.$release.$arch.img No host only: initramfs-0-rescue-$machineid.img And two GRUB menu entries that, in effect, only differ in which initramfs is used. By default Fedora keeps 3 kernel versions installed at once. Upon the installation of the 4th kernel version, the 1st is removed. The no host only initramfs is quite large, but still doesn't contain all loadable kernel modules found in /usr, so reduced functionality is possible because the matching kernel module files are now uninstalled. I'm pretty sure once switchroot happens, the initramfs (the initial file system) is no longer available, therefore any kernel modules that might be needed after switch root probably can't be loaded. I don't know to what degree the kernel tolerates loading different versioned modules, or if it even looks for them, - but we probably can't depend on it. --- > Proposed solution 1: > Complete the current feature - > * You could put the required files external to boot in something like > /usr/lib/kernel/rescue or some place else that does not get cleaned up > in normal kernel rpm upgrades. > * You could modify the current rpms to regenerate rescue image to a > previously working kernel that isn't being cleaned up. > * Have 2 rescue versions where distro upgrades create a new rescue > kernel and remove ones older than n-1. So you might have > /usr/lib/kernel/rescue-41 and /usr/lib/kernel/rescue-42. And on upgrade > to f43 it adds /usr/lib/kernel/rescue-43 and removes /boot/*rescue-41* > and /usr/lib/kernel/rescue-41 It might be possible to "pin" the initially installed kernel so it's not removed. This seems a tolerable risk for a given Fedora release, but I think it needs to be replaced for the next Fedora release (system upgrade). I think the idea of a rescue kernel/initramfs pair is that it's being given pretty broad testing on a wide assortment of hardware during pre-release testing. I think that kernel makes a better candidate for this use case than local user testing with limited hardware. The idea is the rescue option permit boot even if there's been a significant hardware change. > Proposed solution 2: > Replace the current feature - > * Use a paired down iso as the rescue image. It can be completely self > contained and thus doesn't matter how many kernels or distro upgrades > are done. You would want scripts to automate some tasks like mounting > sysroot to make repairs by less sophisticated users easier. This has been discussed. It's a pretty big effort. Fedora's downstreams and OEMs have expressed interest. The difficulty always is that it requires a lot of different disciplines and esoteric knowledge. The changes and on-going support would touch many components. any time it departs from the normal means of booting, the less testing it's getting on a regular basis. And this image needs to be updated from time to time, that needs a design and implementation of its own. The ISO's are now roughly 3.5GiB. So where do we put it? If it's on a dedicated partition, how big do we make it? Is there an opt out for those who don't want to give up that much space for possibly a never encountered rescue? Could we leverage Btrfs dedup or snapshots to reduce the footprint while still having the desired functionality? But then what about non-Btrfs installations? Maybe old is new again - boot fedora org. A package that supplies a rescue kernel/initramfs pair whose sole job is to locate, on the internet, a Fedora rescue image to download and startup from. It might just be easier to recommend and expect users keep a USB stick imaged with a Fedora installer handy, just in case. -- Chris Murphy -- _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
