Grub Empty after dnf upgrade

I ran dnf upgrade yesterday and when I rebooted my machine after the Grub menu only showed Windows. I am dual booting windows and Rocky 8.10. I can boot on a Fedora Live CD and see my file system for Rocky, and the /boot folder is completely empty. Any help would be greatly appreciated.

/boot is a separate partition so would have to be mounted before or after you enter the chroot environment. Use lsblk to list the partitions.
It seems that you rebooted before grub was updated or the update did not complete.

1 Like

Thank you, this did get the /boot working. But my chroot still did not fix my grub. Infact now it is missing the windows 10 that was there previously. Here is what I did.

sudo mount /dev/rl_resolve/root /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot
sudo mount --bind /dev /mnt/dev
sudo mount --bind /sys /mnt/sys
sudo mount --bind /proc /mnt/proc
sudo chroot /mnt
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg
exit
sudo umount /mnt/dev
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/boot
sudo umount /mnt/
reboot

Any help would be great!

[EDIT] For some reason I did misread the tag as “9”. The this does not apply to Rocky 8:
On el9 the latter (/boot/efi/EFI/rocky/grub.cfg) is a mere stub that looks like:

search --no-floppy --root-dev-only --fs-uuid --set=dev 14fba..95e95
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

Where the 14fba..95e95 is the UUID of the filesystem on your /dev/nvme0n1p1
In other words, the /boot/efi/EFI/rocky/grub.cfg simply loads the /boot/grub2/grub.cfg.
Or did, before you did wrote the entire grub.cfg there. Your new /boot/efi/EFI/rocky/grub.cfg does not include the /boot/grub2/grub.cfg.

Skip the above on el8 [/EDIT]


That, however, is not the issue with Windows. On Rocky the grub2-mkconfig could/should call “os-prober” that detects “other OS” and adds entries to GRUB menu for them. In principle, a re-run of grub2-mkconfig on Rocky could do that.


Besides, if you do use UEFI boot, then there should be a chance to invoke “Boot Menu” before GRUB loads (usually with F10, F11, or F12). It should have entries for both Windows and Rocky. That is the menu that I actually use to select OS.

[EDIT]
I have actually disabled os-prober with:

# grep OS_PROBER /etc/default/grub 
GRUB_DISABLE_OS_PROBER=true

and created custom.cfg file in the same directory where the actual grub.cfg is. It has:

menuentry 'Windows 10' --class windows --class os --unrestricted --id 'win10' {
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,msdos1'  1069-4171
	else
	  search --no-floppy --fs-uuid --set=root 1069-4171
	fi
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
if [ "${orig_timeout_style}" -a "${menu_auto_hide}" != "2" ]; then
  set timeout_style=${orig_timeout_style}
  set timeout=${orig_timeout}
fi

where the 1069-4171 is the UUID of my ESP (EFI System partition).
You can see the UUIDs with: lsblk -f

So I actually can’t get into my rocky system at all, outside of booting into a live CD of fedora to see the contents of it. Using the boot entry menu if i select the drive that holds Rocky it shows the empty grub menu. I can select the drive with windows, that works just fine.

I attempted to launch from grub terminal doing the below

grub> ls (hd0,1)/ #pressed tab for auto fill
efi/ /grub2 /loader vmlinuz-0-rescue- #plenry more entries

grub> set root=(hd0,1)
grub> linux /vmlinuz-4.18.0-553.47.1.el18_10.x86_64 root=/dev/nvme01n1p1
grub> initrd /initramfs-4.18.0-553.47.1.el18_10.x86_64.img
grub> boot

It gets to

Found volume group "rl_resolve" using metadata type lvm2
3 logical volume(s) in volume group "rl_resolve" now active

Then enters a loop of
dracut-initqueue timeout - starting timeout scripts

Over and over until it says
Warning could not boot

If the /dev/nvme01n1p1 has contents of /boot, then it is not the root.
The root seems to be LV “root” on VG “rl_resolve”.
There are some kernel cmdline options to request that LV is enabled.

Ah so I would start with

rd.lvm=1

And change
root=/dev/nvme01n1p1 to root=/dev/nvme01n1p2? Or would i change it to root=/dev/rl_resolve/root?

Will try those tonight.

Partial good news!

Changed to root=/dev/rl_resolve/root and using the rescue kernel I am able to access my rocky system. Then I ran the below.

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

Now after a reboot I am again seeing Windows 10 but not rocky on my grub menu.

How do I move forward? I am unable to boot into the regular kernel only the rescue.

Got into /etc/default/grub and changed GRUB_ENABLE_BLSCFG=true to false.

Then

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

And it fixed the issue!

1 Like

On Rocky 8 the boot process has two options:

  • Legacy boot loads GRUB from /boot/grub2/ and GRUB reads /boot/grub2/grub.cfg
  • UEFI boot loads GRUB from /boot/efi/EFI/rocky/ and GRUB reads /boot/efi/EFI/rocky/grub.cfg

On Rocky 9 the same happens, but the /boot/efi/EFI/rocky/grub.cfg is a wrapper that makes the UEFI GRUB read /boot/grub2/grub.cfg.

Either way, you do need only one real grub.cfg


In all cases, the there are two options:

  • BLS is enabled and the grub.cfg should include /boot/loader/entries/*.conf files as boot entries. This is the default
  • BLS is disabled and all boot entries are within the grub.cfg

The entries as separate (BLS) files is easier for kernel updates: simply create file for new kernel and remove file of removed kernel. With entries in grub.cfg requires insert/remove lines type edits.

If no BLS entries were found, had they been erased, or did GRUB’s “locate BLS entries” somehow fail?

I’m not sure how I would check what caused the problem, could I have some guidance?