On Tue, Apr 30, 2019 at 8:12 PM Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Chris Murphy writes:
> On Tue, Apr 30, 2019 at 9:53 AM Sjoerd Mullender <sjoerd(a)acm.org> wrote:
> > Now that the release announcement has been done, I can say that
> > upgrading for me (on a VM) also failed. After the final reboot, I just
> > got a grub prompt.
> It could be this:
If I deciphered this correctly: the default configuration of grub2 is that
it now reads its configuration from someplace else, and not
/boot/grub2/grub.cfg. The F30 grub2 package no longer installs
/boot/grub2/grub.cfg, so it gets renamed to grub.cfg.rpmsave on the upgrade,
but if grub2-install was never executed, the actual bootloader was never
updated, so the older grub2 that's actually still booting the system is
still looking for /boot/grub2/grub.cfg, hence the regression.
On Fedora 29 and older, grub2 did not install /boot/grub2/grub.cfg -
that file was created during installation by grub2-mkconfig invoked by
Anaconda, and then the grub.cfg was maintained by grubby which would
edit the menu entries.
On Fedora 30, the grub.cfg is still created and used, but it's a
static file that points to /boot/loader/entries for individual menu
entry files (BLS snippets if you will). That's described in this
Fedora 30 feature:
The bug happens when a sufficiently old BIOS GRUB is present, I'll
call it "grub installed" in contrast to "RPM installed". That's
because the actual binaries that execute after POST are never updated
by RPM updates; so you can have a current GRUB "RPM installed" but not
"grub installed" unless you manually invoke 'grub2-install'. A too old
GRUB somehow fails to load the blscfg.mod, a new GRUB module to
support reading BLS snippets.
The grub.cfg.rpmsave is a copy of the original grub.cfg before the
upgrade, and will still work (of course it'll boot a Fedora 29 kernel
rather than a Fedora 30 kernel but that's OK). The new grub.cfg after
a Fedora 30 upgrade conforms to the Bootloaderspec feature, meaning
it's a fairly static file that doesn't get updated as kernels are
installed/removed, instead the kernel RPM runs a script that
creates/removes the BLS snippets found in /boot/loader/entries.
But something is still updating /boot/grub2/grub.cfg, since my
timestamps are from the last F29 kernel update.
On Fedora 29, grub.cfg is modified by grubby (the real one, not the
wrapper script on Fedora 30).
I just ran grub2-install on my up-to-date F29 system, and rebooted.
Everything on F29 still seems to be in order, the grub menu is the same. If
another kernel update gets installed before I attempt an upgrade to F30,
will I still see /boot/grub2/grub.cfg getting updated with the newer kernel,
or it'll just update whatever the actual grub2 reads, at boot time?
The former. A Fedora 29 kernel update will act just as it always has,
grubby will modify the grub.cfg to include a new menu entry for the
During Fedora 30 upgrade, there's a conversion script that will
extract existing menu entries from grub.cfg, create the individual BLS
snippets in /boot/loader/entries, rename the old grub.cfg to
grub.cfg.rpmnew, and create a new grub.cfg that conforms to the BLS
feature being enabled.