Upgrading Fedora from F16 to F17 with /usr being a separate Logical Volume
Due to legacy reasons I have a separate volume mounted under /usr, preupgrade and anaconda didn't complain about and seamlessly installed all necessary upgrades. However, after having booted with the F17 kernel I was unpleasantly surprised..
After "Loading initial ramdisk ..." I got "Dropping to debug
shell." and was dumped into a dracut prompt. The last
dmesg line read "dracut Warning:" and nothing more. The
previous lines indicated that the root volume was mounted successfully.
Digging around revealed that one of the next steps should had been the "/usr
merge", but not without the /usr volume ...
cat /etc/fstab showed
/dev/mapper/VG-usr /sysroot/usr ext4 defaults 1 2so it seems that had been detected, but there was no /dev/mapper/VG-usr, only /dev/mapper/VG-root (plus control and VG-swap and luks-... because the partition where that volume group resides is encrypted)
At least Upgrading Fedora using yum hinted at some ideas what needed to be changed.
If you have /usr on LVM, MD raid or DM raid, make sure the kernel command line has either all settings like "rd.lvm.lv=..." to ensure the /usr device is accessible in dracut or just remove all restrictions like "rd.lvm...", "rd.md...", "rd.dm...".For further dracut kernel command line options see the man page.
So, reboot and edit the grub entry for the f17 kernel (press e in grub and possibly you need to enter superuser username and password if you specified one for grub), in the kernel parameters (linux /vmlinuz-...) is something like
rd.lvm.lv=VG/rootor whatever you named the volume group and logical volume for your root filesystem, there add another parameter
rd.lvm.lv=VG/usrwith usr being the logical volume name that is mounted under /usr and press Ctrl+X to boot. At least for me booting was successful then and all /bin, /sbin, /lib and /lib64 content was moved into /usr/bin/, /usr/sbin/ /usr/lib/ and /usr/lib64/ and the symbolic links setup in the / directory.
Now to make that change permanent it has to go into the grub
configuration, so as root edit /etc/default/grub and add the
rd.lvm.lv=VG/usr to the GRUB_CMDLINE_LINUX line and execute
grub2-mkconfig -o /boot/grub2/grub.cfg
Additionally, when executing grub2-mkconfig I got lots of
/usr/sbin/grub2-probe: warning: the device.map entry `hd0,1' is invalid. Ignoring it. Please correct or delete your device.map.In /boot/grub2/device.map there was (hd0,1) /dev/sda1, apparently a leftover from older times, removing that line and keeping only (hd0) /dev/sda solved it.
Somehow the updated configuration gave me a different menu than the
initial one and I also got three "error: file not found", apparently
one for each insmod line of the menu entry chosen, followed by
a "press any key to continue", but it booted. After a
/dev/sda then the grub menu came up in a different font and I had to
enter the boot-superuser username and password but the errors were gone..
WTF? it seems that during upgrade the /boot/grub2/grub.cfg along with
the new grub2-2.0-0.39 was not properly installed. So for the default
Fedora entry I added an --unrestricted option to
/etc/grub.d/10_linux in the line that contains menuentry ...
gnulinux-simple-$boot_device_id before the
\$menuentry_id_option and again ran
/boot/grub2/grub.cfg ... uffz.. finally.
There are known issues with grub2 passwords, see Setting a password for interactive edit mode and it appears to me that I was lucky having set an edit password before the upgrade and installing the new grub2 ...
Still there is some "error: file ..." displayed before the boot menu pops up, but it is displayed for such a very short time that I couldn't read it and have no idea so far what it is about. But, things work..
Display comments as Linear | Threaded