On Sat, May 8, 2021 at 6:52 AM Björn Persson <Bjorn@rombobjörn.se> wrote: > > I used yum system-upgrade to upgrade from Fedora 32 to Fedora 34. Now > Grub complains about not finding some theme files, and then displays a > menu with two kernels from Fedora 29 and a rescue entry from Fedora 28. Does /etc/default/grub contain GRUB_ENABLE_BLSCFG=false ? > If I choose one of the Fedora 29 entries, then Grub unsurprisingly > fails to find the kernel. The rescue entry actually boots to some kind > of shell, after printing lots of timeout messages, but getting from > there to a working system will be a major research project for me. The rescue entry points to a "no host-only" initramfs that has more kernel and dracut modules baked in than the usual "host only" initramfs. This kernel+initramfs pair are created during a clean install. There is no automatic mechanism to ever update them. By design they go stale. Once the /usr modules are removed, this rescue entry almost certainly cannot complete a startup and you get dropped to a dracut shell. You can delete the pair, and at next kernel installation time, they'll be recreated and based on the kernel being installed. A worthwhile feature would be to enhance the rescue entry: * pin this kernel's rpm, so that the /usr modules stick around for a release lifecycle; or * make the initramfs even bigger so that it contains everything plausibly needed to do graphical boot * include the overlayfs, and LiveOS dracut modules (possibly themselves needing some enhancement) so that we can boot a read-only sysroot with a read-write overlay using /run (it'd be a volatile overlay just like a LiveOS boot) But this hypothetical rescue feature should get it's own thread for discussion. > The menu also has entries for "advanced flags" (or something like that; > not sure what it would be in English) and "tboot". Both lead to other > menus with boot entries from Fedora 25. > > The boot partition contains three sets of vmlinuz, initramfs, config > and System.map files – one fc34 set and two fc32 sets as expected – but > Grub has apparently reverted to a years-old boot menu program. There have been two big GRUB changes and if you followed them without any intervention or customizations, you get upgraded correctly. If you make customizations or opt out, then those are pretty much not tested by anyone. So you've probably discovered a bug. If you have BLS disabled, enable it. Recreate /boot/grub2/grub.cfg (this is now the correct location on UEFI and BIOS). If you've accidentally stepped on the forwarding /boot/efi/EFI/fedora/grub.cfg then right now you have to manually recreate it. There isn't a script to fix this once it's been obliterated. Fortunately it's simple: search --no-floppy --fs-uuid --set=dev $UUID set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg Use lsblk -f to find the UUID for /boot and substitute that UUID for $UUID above. This assumes a dedicated ext4 volume for /boot, which is the Fedora default. If you have a different configuration you might need to specify a different UUID for the file system containing /boot/grub2/grub.cfg which might also need a modified line 2 to point to a boot directory, i.e. ($dev)/boot/grub2 -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
