Bug 1813685

Summary: dracut does not include lvm in the initramfs at the time of kernel upgrade on servers where the root pv contains a dos signature
Product: Red Hat Enterprise Linux 7 Reporter: Abhishek Karvi <akarvi>
Component: dracutAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.7CC: dracut-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-15 08:26:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.