Le lundi 11 février 2019 à 12:52 -0700, Chris Murphy a écrit :
On Mon, Feb 11, 2019 at 5:40 AM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> Le 2019-02-10 20:05, Chris Murphy a écrit :
> > On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas
> > Between this feature for F30, and the F29 feature to hide the grub
> > menu which comes with boot success+fail marking by using the
> > grubenv,
> > there are substantial changes in bootloading on Fedora that exist
> > no
> > where else and near as I can tell there is no documentation at
> > all. I
> > can't really call specs we don't fully follow, or feature pages,
> > to be
> > documentation.
>
> FYI I had to rescue two EFI rawhide system this week-end borked by
> grub
> changes. As far as I could reconstruct:
>
> 1. the new grub needs the env file to be regenerated or kernel
> scriplets
> will fail "environment block too small"
The new behavior only applies to Fedora 30 clean installs; upgraded
Fedora 29 and older should not get the new behavior, as I understand
it.
I did a clean install to UEFI, and then installed a newer kernel and
didn't get this error so I'm wondering exactly when you saw it? During
installation? From what install media? Or during a kernel update? Was
it BIOS or UEFI? Default partitioning or what was the file system
where the real grubenv is located?
That was during dnf update to the result of the latest rawhide mass
rebuild, on two UEFI systems, one initially installed in september 2015,
the other in january 2019, with whatever was most current then and then
switched to rawhide and continually updated via dnf since.
Both systems use lvm, one with md raid below lvm, the other without.
Both have the separate /boot/efi vfat mount, one with a separate ext4
/boot below it
The symlink business is confusing. I think that's for grubby's
benefit. It is a self describing method rather than hardwiring it in.
But I don't really like that the real grubenv ends up being in
/boot/efi/EFI/fedora/grubenv even when on BIOS systems where that path
should even exist but... ya not a hill I want to die on today I think.
There's no "real" grubenv, when the symlink gets broken you see that
part of the tools write in one file location, and the others in the
other one. IIRC boot_succes is a pathological case, the thing that sets
it to 0 writes in one grubenv location, and the thing that sets it to 1
uses the other one.
--
Nicolas Mailhot