On Mon, May 6, 2019 at 8:25 AM François Patte <francois.patte@xxxxxxxxxxxxxxxxxxxx> wrote: > > Le 05/05/2019 à 23:20, Ranbir a écrit : > > Hi Everyone, > > > > I started an update of my F29 system today. Everything seemed to be > > going fine until the system locked up. I waited for a few minutes and > > then, hesitantly, I power cycled the computer. Sure enough, the boot > > didn't start and instead dropped into the grub shell. :/ > > I have a similar problem since the kernel update uses grubby instead of > grub2-mkconfig: systematically, grubby chooses a wrong partition as the > / partition and I have to run manually grub2-mkconfig if I want to boot > my machine after a kernel update. > > Is there a way to tell dnf (or whatever...) to use grub2-mkconfig > instead of grubby when there is a kernel update... > No, it's not dnf that does this, it's the kernel post-install scripts. And I think it runs grubby twice with different arguments, once for kernel and once for initramfs. So you'd need to replace grubby with a wrapper script of your own design to ignore the first grubby invocation, and upon second invocation to instead just call grub2-mkconfig and output to the EFI system partition. Alternatively upgrade to Fedora 30, where grubby is no longer used, and chance are you won't have this problem anymore. The grubby upstream package is replaced by a grubby wrapper script strictly for compatibility purposes for users mainly, it's not the real deal, and isn't normally used anymore. Instead, kernel post-install scripts write out per kernel bootloaderspec compatible snippets into /boot/loader/entries The only failure I'm aware of for grubby on Fedora 29 and older is when /boot is on btrfs *and* the top level subvolume is mounted somewhere at the time grubby runs. If you make sure the top level of the Btrfs volume isn't mounted when doing kernel updates, the problem is avoided. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
