RHEL fails to start when moved to other LPAR

Latest response

I had to move a RHEL server from one LPAR to another. The other LPAR is on a different physical server, but it is the same type/model.
LPAR boots from SAN. Boot disk is simply mapped to the new LPAR. FC adapter in the new LPAR is a different type.
I often do the same with AIX LPARs - without problems.

When I try to boot the new RHEL LPAR, it ends like shown below (complete output is attached).
I have searched for a solution, but without luck.
I hope someone here can point me in the right direction.

Regards, Carsten

[  199.222980] dracut-initqueue[319]: Warning: dracut-initqueue timeout - starting timeout scripts
[  199.740480] dracut-initqueue[319]: Warning: dracut-initqueue timeout - starting timeout scripts
[  199.741482] dracut-initqueue[319]: Warning: Could not boot.
[  199.745290] dracut-initqueue[319]: Warning: /dev/mapper/rhel-root does not exist
[  199.745607] dracut-initqueue[319]: Warning: /dev/rhel/root does not exist
[  199.745996] dracut-initqueue[319]: Warning: /dev/rhel/swap does not exist
         Starting Dracut Emergency Shell...
Warning: /dev/mapper/rhel-root does not exist
Warning: /dev/rhel/root does not exist
Warning: /dev/rhel/swap does not exist

Generating "/run/initramfs/rdsosreport.txt"

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.




Hello Carsten,

I can only conclude the volume group RHEL is not found. Is the SAN zoning correct on the new server?


Jan Gerrit Kootstra

Hi Jan

Yes the zoning is correct. The server currently has only 1 disk, and since it is booting up, the disk is available to the server. For some reason it finds the boot partition, but fails to find the RHEL vg.


My guess would be that the 'initramfs' file was generated only with the appropriate drivers for the original hardware - even if the correct drivers are installed on the system, if they were not loaded into the kernel when the initramfs was generated (any time the 'kernel' RPM is installed or updated), they will not be present in the image.

can you run 'lsmod' from the emergency mode 'dracut:#/' shell & see which device drivers are present?

I've only dealt with x64(32/64) hardware, but if I was doing a similar move in that world, the procedure would be: BEFORE moving LUNs to a new host:

insmod $NEWHBA_DRIVER_NAME lsmod # (make sure it loaded!) dracut -f -v # now we have an initramfs with the new driver embedded

Then shut down & move the SAN volume(s) (LUNs) to the new physical host & boot up.

There are other ways of forcing dracut to include (or exclude) certain modules (instead of fiddling with insmod / modprobe / lsmod) - but I've so rarely had to use them, I can't remember the relevant commands or config files off the top of my head. RTFM helps here :-)

Recovering from a move where this wasn't done could be done one of two ways: move (temporarily) back to the old hardware, boot up & run the procedure above, then move back to the new hardware; OR, attach the LUN(s) containing /boot & root file systems to a working "rescue" LPAR on the new machine, mount them under /mnt/recovery (/mnt/sysimage or whatever), then chroot into that system to run 'dracut -f -v' (no need to 'insmod', the rescue system kernel should already have the right drivers loaded).

Hi James

Thank you for your feedback. That sounds right. I will go ahead and see which way will work for me.


A final update: I figured out that we are using two different kind of FC adapters: QLogic, for which the driver is "qla2xxx" and Emulex, for which the driver is "lpfc". I moved the server back to the old hardware, included both drivers in /etc/dracut.conf and built a new initramfs containing both drivers. Then moved the server to the new hardware, and it booted without problems :-) I can now move the server back and forth between hardware with these adapter types.