Lvm Module Missing In Initramfs

Home » CentOS » Lvm Module Missing In Initramfs
CentOS 1 Comment

After upgrading the kernel package, my CentOS 7 server didn’t boot.

Here is a small summary:
old kernel = kernel-3.10.0-123.4.4.el7.x86_64 (everything just fine)
new kernel = kernel-3.10.0-123.6.3.el7.x86_64
root partition is on a primary partition, NOT on a LVM volume
/var partition is on a LVM volume new kernel’s boot problem = systemd cannot mount /var partition saying requirements failed or something like that

I have find out that the new kernel’s initramfs image does not contain the lvm module while the old kernel’s initramfs did.

I have created a new initramfs with lvm using dracut and could boot the server successfully. However I do not consider this as a fix, and don’t know how to find the primary cause of the problem. I need some help finding out who’s to blame:

Is the lvm module really missing? AFAIK the initramfs exists for one purpose only and that is to mount the root partition. All kernel modules are on this partition and once it is mounted, the kernel can access all hardware it supports – LVM included, of course. The fact is the root partition WAS mounted successfully before the boot process failed and the lvm module is NOT needed for this task. Initramfs did its job fine, didn’t it?

If that’s true and the lvm module is NOT missing in the initramfs, is the boot problem systemd related? Has it failed to activate the LVM? Why?

Any help would be appreciated.

One thought on - Lvm Module Missing In Initramfs

  • Update: I did some tests on a very similar CentOS 7 server and could reproduce the problem with an older kernel. So kernel version doesn’t matter.

    After swapoff -a the mkinitrd command produces an initamfs image WITHOUT the lvm. The system cannot boot with it.

    Then after swapon -a the mkinitrd creates an image WITH the lvm module.

    Any ideas why? Is it a bug?

    On the original system was the swap not disabled, but replaced with an encrypted swap (one added line in crypttab, one line changed in fstab). And when the next kernel update came, the server have become unusable as I
    described in my first post.