On Mon, May 6, 2019 at 1:04 PM Steven A. Falco <stevenfalco(a)gmail.com> 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.
At the moment, I think whatever problem there was has been cleared and
it's now behaving normally.
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.
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.
--
Chris Murphy