Re: F30 change, bootloaderspec by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux