Bug 1813685 - dracut does not include lvm in the initramfs at the time of kernel upgrade on servers where the root pv contains a dos signature
Summary: dracut does not include lvm in the initramfs at the time of kernel upgrade on...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut
Version: 7.7
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-15 13:09 UTC by Abhishek Karvi
Modified: 2021-09-15 08:26 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-15 08:26:13 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Abhishek Karvi 2020-03-15 13:09:36 UTC
Description of problem:

After upgrading from Rhel 7.6 to Rhel 7.7, dracut does not include lvm in the initramfs, thereby causing the system to not boot. 

To solve this issue, we simply need to enter rescue mode and rebuild initramfs. 
Simply running "dracut -f <path to initramfs> <kernel version>" is sufficient. We do NOT need to explicitly use "--add lvm" while rebuilding initramfs

So the issue is introduced at kernel upgrade. Also, during the process of kernel upgrade, dracut creates initramfs of the latest kernel that is being installed AS WELL AS it rebuilds the initramfs of kernels that are already present on the system. And while rebuilding the initramfs of the existing kernels, dracut does not include lvm in any of them thereby causing the system to not boot using any of the older kernels. 


Version-Release number of selected component (if applicable):

Before patching to Rhel 7.7:

  dracut-033-554.el7.x86_64
  kernel-3.10.0-957.el7.x86_64
  lvm2-2.02.180-10.el7_6.2.x86_64

After patching to Rhel 7.6:

  dracut-033-564.el7.x86_64
  kernel-3.10.0-1062.9.1.el7.x86_64
  lvm2-2.02.185-2.el7_7.2.x86_64


Steps to reproduce:

Upgrade the OS via Satellite server using "yum update" command

The customer has 2 identical systems that were patched. The patch level and patching method is the same on both.
The difference between the 2 systems is:

A] On the problematic system, /dev/sda2 (PV for rootvg) has a dos partition table signature 

     # wipefs /dev/sda2
     offset               type
     ----------------------------------------------------------------
     0x1fe                dos   [partition table]                     <=====

     0x218                LVM2_member   [raid]
                          UUID:  AAA-BBB-CCC-DDD-EEE-FFF-GGG

   This partiton table signature does not cause /dev/sda2 to not be detected as a PV so we never notice an issue while the system is running, until the upgrade


B] And on the working system, /dev/sda2 does not have the dos partition table signature

     # wipefs /dev/sda2
     offset               type
     ----------------------------------------------------------------
     0x218                LVM2_member   [raid]
                          UUID:  HHH-III-JJJ-KKK-LLL-MMM-NNN
  
   Here lvm gets included in the initramfs at the time of kernel upgrade and the system boots without issues 


=> Now on the problematic server, we wiped off the dos signature and upgraded the kernel and this time there was no issue

   $ wipefs -o 0x1fe /dev/sda2 -f


Actual results:

lvm is not included in the initramfs on the problematic system


Expected results:

dracut should recognize the lvm signature on the disk and lvm should be included in the initramfs.

  $ blkid | grep sda2
  /dev/sda2: PTTYPE="dos" 

  $ pvs | grep sda2
  /dev/sda2  rhel   lvm2 a--   <100g  50g  <100g   AAA-BBB-CCC-DDD-EEE-FFF-GGG      0   1020.00k     1        1   1.00m


On the problematic system, even though blkid did NOT report /dev/sda2 as "LVM2_member" there was another disk that was reported as "LVM2_member" and this should be ideally be sufficient to include lvm module in the initramfs

  $ blkid | grep 
  /dev/sdx1: UUID="OOO-PPP-QQQ-RRR-SSS-TTT-UUU" TYPE="LVM2_member"

Comment 5 RHEL Program Management 2021-09-15 08:26:13 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


Note You need to log in before you can comment on or make changes to this bug.