Upgrade from F29 to F30 fails to boot

Monday, 29 July 2019

I have a machine that I have been upgrading since F25. All of them went 
smoothly from F25-F29.

I did the upgrade from F29 to F30 yesterday and it seemed to go OK till 
the boot after installing everything.

I guess the naming I am using for my root partition is confusing the 
upgrade, although it has not changed since all the previous upgrades 
that worked fine. From the /boot/grub2/grub.cfg the F29 boot options 
show that my LVM root partition ends with roota:

linux16 /vmlinuz-5.1.18-200.fc29.x86_64 root=/dev/mapper/fedora-roota ro 
rd.lvm.lv=fedora/roota rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8

This works in F29 and all the previous upgrades have worked fine.

However, for F30 after the installation when it tries to reboot it 
complains that it can't find roota so it can't mount root and goes into 
a very minimal mode. I mounted the /boot partition in this restricted 
mode to look around.

The new F30 kernel wants to install a 5.1.19 kernel, but there is no 
line for that version in grub.cfg, although it shows up as the first 
option during boot.

I noticed a file called grubenv that has this line:

kernelopts=root=/dev/mapper/fedora-roota ro rd.lvm.lv=fedora/root 
rd.lvm.lv=fedora/swap rhgb quiet

Notice it has roota for the root variable, but not roota for the 
rd.lvm.lv value.

I added an "a" to the rd.lvm.lv value in grubenv and tried a reboot and 
it rebooted the 5.1.19 kernel just fine and came up as F30.

I am confused why this upgrade didn't add the "a" to the rd.lvm.lv value 
but always did in the previous upgrades?

Also, I am not sure that the upgrade is fully complete as there is still 
no entry in grub.cfg for the 5.1.19 kernel.

How do I get the 5.1.19 entry into the grub.cfg file?

This machine is a test machine for the a production machine. It is 
configured the same way as the production machine. I apply patches on 
this machine first then the production machine. Likewise for upgrades. I 
would like to not have to do any hack like this if there is something 
that can be done that will result in a smooth upgrade on the production 
machine. This machine is a VM and I took an image of it prior to the 
upgrade attempt. I have no problem reinstalling the image prior to the 
upgrade and trying it again if there is a way to get a clean upgrade.

My overriding concern is that this is something I will continue to run 
into on future upgrades.

Thanks

Chris K