Bug 1187753 - dmraid failure to remove underlying subpartitions leads to LVM physical volume being wrongly assigned
Summary: dmraid failure to remove underlying subpartitions leads to LVM physical volum...
Keywords:
Status: CLOSED DUPLICATE of bug 1172510
Alias: None
Product: Fedora
Classification: Fedora
Component: dmraid
Version: 22
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Heinz Mauelshagen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-30 19:30 UTC by Helmut Schlattl
Modified: 2015-11-24 20:07 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-24 20:07:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Screenshot 1: dmraid -ay ... (340.91 KB, image/jpeg)
2015-02-01 11:39 UTC, Helmut Schlattl
no flags Details
Screenshot 2: dmraid -s (272.17 KB, image/jpeg)
2015-02-01 11:40 UTC, Helmut Schlattl
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1172510 0 unspecified CLOSED boot fails with "Failed to mount /boot." 2021-02-22 00:41:40 UTC

Description Helmut Schlattl 2015-01-30 19:30:14 UTC
Description of problem:
Root partition on dmraid RAID1 device (pdc_bcdbecjef). 
During early boot (dracut) the underlying partitions (sda?, sdb?) should be removed by dmraid --rm_partitions ... This fails however. With the sdaX and sdbX devices still present, udev will start lvm2-pvscan@.service on these devices. It seems that this actually leads to the usage of sdaX or sdbX for the LVM physical volume instead of pdc_bcdbecjefX


Version-Release number of selected component (if applicable):
dmraid-1.0.0.rc16-25.fc21.x86_64
lvm2-2.02.115-1.fc21.x86_64

How reproducible:
always

Steps to Reproduce:
1. boot system with logical volume on dmraid (e.g., /home)
2.
3.

Actual results:
LVM's physical volume is /dev/sdaX

Expected results:
LVM's physical volume is /dev/pdc_bcdbecjefX


Additional info:

If everything works fine dmsetup ls --tree shows (on my system):
pdc_bcdbecjef1 (253:1)
 └─pdc_bcdbecjef (253:0)
    ├─ (8:16)
    └─ (8:0)
vg02-system (253:5)
 └─pdc_bcdbecjef4 (253:2)
    └─pdc_bcdbecjef (253:0)
       ├─ (8:16)
       └─ (8:0)
vg02-home (253:6)
 └─pdc_bcdbecjef4 (253:2)
    └─pdc_bcdbecjef (253:0)
       ├─ (8:16)
       └─ (8:0)

'/' on /dev/mapper/pdc_bcdbecjef1
'/home' on /dev/mapper/vg02-home

I disabled mounting '/home' in /etc/fstab. Then I get after boot:

> systemctl --all | grep pvscan 

 lvm2-pvscan@253:2.service      loaded    active   exited    LVM2 PV scan on device 253:2  
  lvm2-pvscan@8:20.service       loaded    active   exited    LVM2 PV scan on device 8:20   
● lvm2-pvscan@8:4.service        loaded    active  activating  LVM2 PV scan on device 8:4
  system-lvm2\x2dpvscan.slice    loaded    active   active    system-lvm2\x2dpvscan.slice 

> pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda4
  VG Name               vg02
  PV Size               830,82 GiB / not usable 1,31 MiB
  Allocatable           NO
  PE Size               4,00 MiB
  Total PE              212690
  Free PE               0
  Allocated PE          212690
  PV UUID               pRAI6d-g1LF-Tqrs-sYVd-no1X-XF4f-PwCIQY

To repaired this, I did the following:
> systemctl stop lvm2-pvscan@8:4.service
> vgchange -an vg02
> pvchange -x n /dev/sda2
> pvscan --cache -a ay 253:2

With this:
> pvdisplay
--- Physical volume ---
  PV Name               /dev/mapper/pdc_bcdbecjefpdc_bcdbecjef4
  VG Name               vg02
  PV Size               830,82 GiB / not usable 1,31 MiB
  Allocatable           NO
  PE Size               4,00 MiB
  Total PE              212690
  Free PE               0
  Allocated PE          212690
  PV UUID               pRAI6d-g1LF-Tqrs-sYVd-no1X-XF4f-PwCIQY

So the dmraid array would be working, if it would be activated properly!

Being astonsished that sda4 (and sdb4) is still present, I rebooted with 'rd.break=initscripts'. Until this point /dev/mapper/pdc_bcdbecjef was not yet present, as well as no /dev/sda4 or /dev/sdb4. Analogue to dracut's dmraid-module I performed:

dmraid -ay -i -p --rm_partitions pdc_bcdbecjef

Unexpectedly, /dev/sda1, /dev/sda4, /dev/sdb1 & /dev/sdb4 were created by this command!!

Comment 1 Helmut Schlattl 2015-02-01 11:39:47 UTC
Created attachment 986735 [details]
Screenshot 1: dmraid -ay ...

Comment 2 Helmut Schlattl 2015-02-01 11:40:29 UTC
Created attachment 986736 [details]
Screenshot 2: dmraid -s

Comment 3 Helmut Schlattl 2015-02-01 11:42:13 UTC
Performed an addition test in dracut-shell using "rd.break=pre-trigger" to avoid udev interference.

The two attachments (screenshots) show that dmraid is actually removing sdaX and sdbX, but eventually does not activate pdc_bcdbecjef, although dmraid -s shows the opposite???

Comment 4 Fedora End Of Life 2015-11-04 10:20:13 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Helmut Schlattl 2015-11-24 20:07:56 UTC

*** This bug has been marked as a duplicate of bug 1172510 ***


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