Re: Kernel upgrades

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

 



On 5/6/19 4:47 PM, Chris Murphy wrote:
> On Mon, May 6, 2019 at 1:04 PM Steven A. Falco <stevenfalco@xxxxxxxxx> wrote:
>>
>>> # grub2-editenv list
>>
>> Here is the command output:
>>
>> saved_entry=2aa6409d5c354eea9cc2e4630c4efda0-5.0.11-300.fc30.x86_64
>> boot_success=1
>> boot_indeterminate=1
>> kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap
> 
> Looks normal.
> 
> Also, about the /boot/grub2/grubenv symlink to
> /boot/efi/EFI/fedora/grubenv - I'm only seeing this on clean installs
> from Fedora-Workstation-Live-x86_64-30-1.2.iso so it might be related
> to how the lives are assembled and rsync'd over. It doesn't happen
> with a minimal or server installation on a BIOS VM.

The install originated as a "server edition", so that is consistent.

> At the moment, I think whatever problem there was has been cleared and
> it's now behaving normally.

Agreed.

>> I'm reading through the various scripts trying to understand the impact of GRUB_DEFAULT.  It seems like having GRUB_DEFAULT=saved is not currently hurting me.  The last upgrade, to 5.0.11-300, properly made that kernel the new default.
>>
>> If GRUB_DEFAULT is commented out, then I think grub will always choose the first item in its menu, which would be fine, because the newest kernel always appears first in the grub menu.  Is that why you recommended commenting it out?
> 
> Nope, sorry, you're confused. I referred to GRUB_SAVEDEFAULT -
> thinking maybe you had a customized /etc/default/grub. GRUB_DEFAULT
> and GRUB_SAVEDEFAULT are two different things, but the latter depends
> on the former.

It wouldn't be the first time I was confused. :-)

> I suggest keeping things as is, with saved_entry set in the grubenv.
> And that's because GRUB and the grub-boot-success.service are able to
> do an automatic fallback to the previous working kernel if boot fails
> following a kernel upgrade.

I will leave it alone, as you recommend.

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. :-)

And thanks for all your help!

	Steve

_______________________________________________
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