Re: Kernel upgrades

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

 



On Mon, May 6, 2019 at 3:15 PM Steven A. Falco <stevenfalco@xxxxxxxxx> wrote:
>
> As I was reading through the documentation, I came across a statement that grubenv is unavailable on RAID - please see the second to last sentence here:
>
> https://www.gnu.org/software/grub/manual/grub/html_node/Environment-block.html
>
> My machine is set up with /boot on SW RAID-1 (and everything else on SW RAID-5 / LVM).  That said, grubenv appears to update properly.  I don't know if the manual is not quite current, or if there is some other explanation - perhaps any updates always occur under Linux, while the RAID-1 is assembled.
>
> Regardless, everything is good now, so I'll stop obsessing about it. :-)

Yep.
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/PBCAGLM46RSG54QW3DM43U4H5YQSHZNB/

GRUB pre-boot environment can read grubenv from anything GRUB supports
reading, which is practically anything including mdadm RAID. Your
grubenv can be read, it just can be changed by GRUB in the pre-boot
environment. That means it can't change boot_success to 0. It'll
always be a 1, meaning GRUB will think your boots are always
successful.

When a new kernel is installed, the package scripts cause grubenv
saved_entry to get updated. This is happening through kernel file
system and md code, so it's a completely supported change, and that's
how GRUB in the pre-boot environment can see the updated saved_entry
and know which kernel version to boot by default.

But it's worth keeping an eye on anomalies. There is the potential for
goofy things happening. Unrelated to this particular feature, rather
it was grub.cfg being updated, in cases where that update happened
very quickly followed by an immediate reboot, GRUB only saw the
previous grub.cfg. On journaled file systems, the new file gets
written out, and indicated only in the journal, and a particular set
of circumstances preventing the root fs from being cleanly unmounted
resulted in a hidden new grub.cfg that only became revealed after
journal replay by the kernel code. The GRUB code can't read file
system journals, so it was seeing the stale file as a result of
reading stale file system metadata without the benefit of reading the
journal. :P


--
Chris Murphy
_______________________________________________
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