Ask Your Question

Tried to install 2nd Fedora, can't boot into original one

asked 2017-12-02 11:27:16 -0500

allencmcbride gravatar image

Dear Fedora friends,

I have an SSD and a HDD. I have Windows and my main Fedora on the SSD, with home areas on the HDD. I had extra space on the HDD and installed a second Fedora there (for CUDA work). The new install works, but now i can't boot into the old one.

When installing the new one, I only selected the HDD in Anaconda and did an automatic setup, thinking it would therefore not touch my SSD. And I'm not sure it did... and I can almost boot into the old... but something goes wrong that I don't understand.

When I select the old boot entry in the BIOS menu, it goes to the correct GRUB2 menu for the old install. And the old grub.cfg file seems unaltered, and it seems to have the correct entries (e.g., "set root='hd1,gpt6'"). Furthermore, when I select the top entry, it prompts for my LUKS password (only my old install is encrypted), so it really seems to be on the right track... But then I end up booted into the new install. (The boot partition for the old boot ends up unlocked but unmounted.)

So somewhere between selecting a GRUB2 entry and the finished boot, I'm getting diverted to the wrong installation, and I don't understand where the fork in the road is, how it got changed, or how to fix it.

Here's the output of fdisk -l:

Here's /boot/efi/EFI/fedora/grub.cfg for the new installation (works fine):

Here's /boot/efi/EFI/fedora/grub.cfg for the old install (looks fine to me, seems unchanged from before, but selecting an entry leads to the wrong installation):

(Also, if I select the last kernel back in the GRUB2 menu for the old install, I get emergency mode, but I don't have a root password so I can't do much. I assume this is because when it (for whatever reason) tries to divert to the new install, the new install doesn't have that kernel version available.)

Thanks for reading! --Allen

edit retag flag offensive close merge delete


What do you get for

efibootmgr -v
cmurf gravatar imagecmurf ( 2017-12-03 13:53:47 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-12-03 14:34:41 -0500

cmurf gravatar image

updated 2017-12-03 14:40:23 -0500

OK I see what's going on. The old and new grub.cfg's are both using root=/dev/mapper/fedora-root to refer to rootfs. And both old and new installations have rootfs on a VG named fedora, and LV named root. Therefore the root=/dev/mapper/fedora-root is ambiguous, and the kernel simply uses the first rootfs of that name it finds which is the one for the new installation (for whatever reason), but if you tried it enough times maybe you'd find 1 in X attempts results in the old installation booting. Anyway, you have to change the name of one of the LV's. The easiest thing to do is boot the new installation, since that's the working one anyway, and use lvrename, then update /etc/fstab, then update /etc/default/grub where there's and that need their names updated, and then remake the grub.cfg with grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg.

edit flag offensive delete link more


Note you can either rename the VG or the LV, it is probably better to rename the VG because having two VGs of the same name is still ambiguous even though it shouldn't cause a problem. If you rename the VG, that means the path for /dev/mapper/fedora-swap also changes, so you need to fix that in /etc/fstab too.

cmurf gravatar imagecmurf ( 2017-12-03 14:37:55 -0500 )edit

Great, thank you! On the last step, grub2-probe was still looking for the path to the no-longer-there /dev/mapper/fedora-root. So I tried the instructions at . That didn't work either, because on reboot dracut seemed to still be looking for the old vg name. But that's no big deal: I hadn't set up my 2nd install yet, so I can just install it again (with a different vg name this time). And more importantly, getting that duplicate vg name out of the way fixed my old install. And I'm happy to understand what the problem had been.

allencmcbride gravatar imageallencmcbride ( 2017-12-03 19:20:16 -0500 )edit

I'd say this is a valid installer bug. The installer should see the old installation and pick a different VG name automatically. And yeah, dracut by default does hostonly initramfs so there can be some host specific stuff in them, so a refined work around would be to add as a last step 'dracut -fN' so that the current new install has a nohostonly initramfs which should not have vg/lv names in it at all. After rebooting, dracut -f to rebuild a much smaller hostonly initramfs that has the new vg/lv name in it.

cmurf gravatar imagecmurf ( 2017-12-03 23:33:23 -0500 )edit

Question Tools

1 follower


Asked: 2017-12-02 11:27:16 -0500

Seen: 128 times

Last updated: Dec 03 '17