Fedora dissappeared on boot after Windows reinstall

and yes, edit both parts if needed to replace nobara_localhost-live with nobaraVG

1 Like

I GOT IN! thank you so much
Is there anything I need to do now?

Yes, now we need to fix the problem that caused that kernel command line to be invalid.

cat /etc/default/grub so we can see the command line there.

1 Like
$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=nobara_localhost-live/root rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

I am guessing I have to change GRUB_CMDLINE_LINUX="rd.lvm.lv=nobara_localhost-live/root

That change needs to be done first then run grub2-mkconfig -o /boot/grub2/grub.cfg

After that is done we need to check one more thing

1 Like

got a small error i think

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
grub2-probe: error: cannot find a GRUB drive for /dev/sdb3.  Check your device.map.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

not a significant error. It sees the usb drive which is not needed now.

Now to look at the next part.
ls /boot/loader/entries and find the file that shows the 5.19.6 kernel.
then grep that file for the rd.lvm.lv entry to see if it has the old VG name or the new one.

1 Like

this is what I got

$ sudo ls /boot/loader/entries
[sudo] password for mxfuuu: 
8ae5229828014ea2a89e0a795b4b9270-0-rescue.conf
8ae5229828014ea2a89e0a795b4b9270-5.18.18-201.fsync.fc36.x86_64.conf
8ae5229828014ea2a89e0a795b4b9270-5.19.4-201.fsync.fc36.x86_64.conf
8ae5229828014ea2a89e0a795b4b9270-5.19.6-202.fsync.fc36.x86_64.conf

I am not sure what to do here

grep rd.lvm.lv /boot/loader/entries/8ae5229828014ea2a89e0a795b4b9270-5.19.6-202.fsync.fc36.x86_64.conf

1 Like
$ sudo grep rd.lvm.lv /boot/loader/entries/8ae5229828014ea2a89e0a795b4b9270-5.19.6-202.fsync.fc36.x86_64.conf
options root=/dev/mapper/nobaraVG-root ro rd.lvm.lv=nobaraVG/root rhgb quiet nvidia-drm.modeset=1 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau

this is what I got

Good. Now a simple reboot should work properly for that kernel.

If you do the same for each of the other files in that directory then you can verify if all were updated or not.
grep rd.lvm.lv /boot/loader/entries/*

1 Like

I will wait (im)patiently for the result of the reboot :innocent:

1 Like

VGs seems to be alright in all of the directories!
Rebooting!

I am in!!
Thank you so much! really grateful to everyone here who helped me, and especially @computersavvy !

So just to recap everything that worked.

  1. verify that everything under /boot/efi/EFI/fedora was gone
  2. Verify that /boot/grub2/grub.cfg was removed
  3. Rename the VG (may or may not have been necessary, but was not activating at all when booted to the live USB system)
  4. The windows install created a new UUID for the ESP. That plus renaming the VG required an edit of /etc/fstab with the new info required for booting.
  5. Reinstall both grub2* and shim* (to rebuild all the files under /boot/efi/EFI/fedora)
  6. run efibootmgr -c to tell the UEFI bios that grub was available to boot.
  7. Renaming the VG necessitated an edit of /etc/default/grub to put the new VG name in the kernel command line.
  8. A final run of grub2-mkconfig -o /boot/grub2/grub.cfg put the updated kernel command line in all the boot loaders for fedora and booting is now working properly.

If that is the gist as you see it then I am very glad we were able to solve the issue and hopefully no one will need to go through all this angst in the future. :cowboy_hat_face:

I learned a lot myself with this process.

also never install windows after installing Linux xD

1 Like

Yeah, that was the steep entrance into this rabbit hole. :sunglasses:

thank you again! you have been kind enough to patiently help me though this and I really appreciate that!

Make a backup copy

rsync -a /boot/efi/EFI/fedora /root/efibakcup

This is potentially a good idea, though it does not influence the changes in /boot/grub2 and /boot/loader that would happen with each kernel update. It only would be of assistance in a situation such as happened here with installing windows after fedora was already installed and the fedora directory in the efi partition was wiped out. Reinstalling grub2 and shim fixes that issue so I am not sure of the benefit.

As shown above, there were actually two issues

  1. The windows install wiped out the fedora efi info, as well as wiping the info for grub boot from the UEFI bios. That necessitated a full grub2 and shim reinstall followed by use of efibootmgr to enable grub booting.
  2. The resultant changes caused LVM to not load and the need to solve the issue with LV activation to enable booting.