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
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
