Every so often I come across an old Linux box that doesn’t take kindly to being rebooted. Without console access, it is hard to see what is going on, but the Linux kernel gets stuck trying to mount the root file system. There are many possible fixes for this, but they all have one thing in common … a work-around has to be performed to get the box up and running.
The console gets stuck in a “mini-root” environment loaded when the initrd image is loaded and before the real root file system is mounted which means a lot of commands are not available, but lvm should be available. First of all, run lvm lvscan to get a list of the logical volumes that need activating :-
(initramfs) lvm lvscan inactive '/dev/sys/root' [332.00 MiB] inherit inactive '/dev/sys/usr' [8.38 GiB] inherit inactive '/dev/sys/var' [2.79 GiB] inherit inactive '/dev/sys/swap_1' [7.05 GiB] inherit inactive '/dev/sys/tmp' [380.00 MiB] inherit inactive '/dev/sys/home' [16.00 GiB] inherit inactive '/dev/sys/opt' [24.00 GiB] inherit
For each volume group (the second column, middle word), run: lvm lvchange -ay ${volume-group-name}. In the case of my example :-
(initramfs) lvm vgchange -ay /dev/sys 7 logical volume(s) in volume group "sys" now active
At which point you should be able to press ^D (or enter exit) to continue the boot process.
A slighter better work-around involves changing the Grub configuration to add a delay to the kernel parameters. This sections assumes that you are not using Grub Legacy!
Start by editing /etc/default/grub and changing the variable GRUB_CMDLINE_LINUX to include “rootdelay=20” :-
GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8 rootdelay=20'
Finalise by running update-grub. This adds a 20s delay to the boot process so is hardly an ideal solution.