This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 679321

Summary: LVM never unsets the DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 flags
Product: [Fedora] Fedora Reporter: Daniel Mach <dmach>
Component: udevAssignee: udev-maint
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 15CC: agk, antillon.maurizio, bmarzins, bmr, ccecchi, dwysocha, extras-orphan, harald, heinzm, jonathan, lpoetter, lvm-team, metherid, mgrepl, mschmidt, msnitzer, mtasaka, notting, plautrba, prajnoha, prockai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 15:16:02 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Daniel Mach 2011-02-22 04:00:01 EST
Both /home and swap are not mounted after boot.
'mount /home' command works as expected therefore I assume the problem might be in systemd.


/etc/fstab:
LABEL=home              /home                   ext4    noatime,commit=600         1 2
LABEL=swap              swap                    swap    defaults        0 0


Both home and swap are LVM volumes on an encrypted disk.


Log:
'\x2d' looks suspicious, but it might be just a logging issue.

[   32.930224] systemd[1]: Accepted connection on private bus.
[   32.933847] systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Agent.Released() on /org/freedesktop/systemd1/agent
[   32.937436] systemd[1]: systemd-logger.service: cgroup is empty
[   32.941018] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
[   77.103904] systemd[1]: Job dev-disk-by\x2dlabel-home.device/start timed out.
[   77.107451] systemd[1]: Job dev-disk-by\x2dlabel-home.device/start finished, success=no
[   77.110982] systemd[1]: Job home.mount/start finished, success=no
[   77.114589] systemd[1]: Job fsck@dev-disk-by\x2dlabel-home.service/start finished, success=no
[   77.118198] systemd[1]: local-fs.target changed dead -> active
Comment 1 Lennart Poettering 2011-02-22 12:08:56 EST
Are these file systems on LVM?

If you do "systemctl --type=device --all --full" do you see the block devices these file systems are mounted from appear in the output as "plugged"?
Comment 2 Lennart Poettering 2011-02-22 12:11:28 EST
Also, if these devices are indeed on LVM, please track down on which dm device they are and then attach the output of "udevadm info -p /sys/class/block/dm-0 -q all" here, with "dm-0" replaced by the right dm device.
Comment 3 Daniel Mach 2011-02-22 12:36:19 EST
Yes, as I mentioned in the first comment, it's LVM:

$ fdisk /dev/sda
Command (m for help): p
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63     1060289      530113+  83  Linux
/dev/sda2         1060290   195366464    97153087+  8e  Linux LVM

/dev/sda2 is LUKS formatted


$ pvs
  PV                                 VG   Fmt  Attr PSize  PFree
  /dev/mapper/luks-...               vg0  lvm2 a-   92.65g    0


$ lvs
  LV    VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  home  vg0  -wi-ao 68.65g                                      
  root1 vg0  -wi-ao 10.00g                                      
  root2 vg0  -wi-a- 10.00g                                      
  swap  vg0  -wi-a-  4.00g


dm-0: LUKS
P: /devices/virtual/block/dm-0
N: dm-0
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/block/dm-0
E: MAJOR=253
E: MINOR=0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: DM_SBIN_PATH=/sbin
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: SYSTEMD_READY=0
E: TAGS=:systemd:


dm-3: SWAP:
P: /devices/virtual/block/dm-3
N: dm-3
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/block/dm-3
E: MAJOR=253
E: MINOR=3
E: DEVNAME=/dev/dm-3
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: DM_SBIN_PATH=/sbin
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: SYSTEMD_READY=0
E: TAGS=:systemd:


dm-4: HOME:
P: /devices/virtual/block/dm-4
N: dm-4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/block/dm-4
E: MAJOR=253
E: MINOR=4
E: DEVNAME=/dev/dm-4
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: DM_SBIN_PATH=/sbin
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: SYSTEMD_READY=0
E: TAGS=:systemd:


$ systemctl --type=device --all --full | egrep "swap|home|boot"
dev-disk-by\x2dlabel-boot.device loaded active   plugged     HITACHI_HTS723210L9SA60
dev-disk-by\x2dlabel-home.device loaded inactive dead        dev-disk-by\x2dlabel-home.device
dev-disk-by\x2dlabel-swap.device loaded inactive dead        dev-disk-by\x2dlabel-swap.device

Boot, which is not a LVM volume, it's correctly plugged.
Others are dead.

LUKS device is plugged too:
dev-disk-by\x2duuid-ad1....device loaded active   plugged
Comment 4 Lennart Poettering 2011-02-22 12:44:39 EST
Seems LVM never finishes to set up the devices. i.e. DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 is set for all devices which tells apps like systemd and udisks to ignore the device for now, until the flag is unset.

Seems this is a bug in lvm, reassigning.
Comment 5 Milan Broz 2011-02-22 14:19:50 EST
I do not see this flag when creating new LVs, so it must be either bug in early boot udev rules or in some rule I have not installed here.

So you have  DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 cached for all DM devices in udev db, right? (/dev/.udev/db/)
Comment 6 Daniel Mach 2011-02-23 08:52:48 EST
Milan helped me to debug this issue and we've found that it's due to different udev in initramfs and in the system.

Reproducer:
1) install
  libgudev1-164-9.fc15.i686
  libudev-164-9.fc15.i686
  udev-164-9.fc15.i686

2) dracut -f

3) install
libgudev1-166-1.fc15.i686
udev-166-1.fc15.i686
libudev-166-1.fc15.i686

4) reboot
Comment 7 Milan Broz 2011-02-23 09:24:34 EST
Reassigning this to udev, updating udev should trigger initramfs update...
Comment 8 Harald Hoyer 2011-02-23 10:28:53 EST
Somewhere in the real root, before starting the udevd.service

/sbin/udevadm info --convert-db

has to happen..
Comment 9 Lennart Poettering 2011-02-23 14:37:40 EST
(In reply to comment #8)
> Somewhere in the real root, before starting the udevd.service
> 
> /sbin/udevadm info --convert-db
> 
> has to happen..

Is that expensive, do we have to do that unconditionally?

Can't we just rebuild the initrd when LVM (or udev?) is upgraded?

Also, did the udev db actually really change?
Comment 10 Harald Hoyer 2011-02-23 14:52:31 EST
(In reply to comment #9)
> (In reply to comment #8)
> > Somewhere in the real root, before starting the udevd.service
> > 
> > /sbin/udevadm info --convert-db
> > 
> > has to happen..
> 
> Is that expensive, do we have to do that unconditionally?

We could check in real root, if there is the old file format.
Might be a simple file check.

> 
> Can't we just rebuild the initrd when LVM (or udev?) is upgraded?

Sure, we do this already, when udev is updated. But we cannot/should not update all the old initramfs images, where an old udev version can live in.

> 
> Also, did the udev db actually really change?

Yes, it did.
Comment 11 Daniel Mach 2011-02-24 09:44:14 EST
(In reply to comment #9)
> Can't we just rebuild the initrd when LVM (or udev?) is upgraded?

Rebuilding initramfs is only a partial solution.
It won't work when admin sets
'UPDATEDEFAULT=no' in /etc/sysconfig/kernel 
and switches to a new kernel only when he wants.

It would be necessary to rebuild all initramfs files (probably according to installed kernel packages or grub records).
Comment 12 Lennart Poettering 2011-02-24 19:55:02 EST
*** Bug 679842 has been marked as a duplicate of this bug. ***
Comment 13 Lennart Poettering 2011-02-28 14:56:27 EST
*** Bug 680601 has been marked as a duplicate of this bug. ***
Comment 14 Fedora Admin XMLRPC Client 2011-10-20 12:09:05 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Fedora Admin XMLRPC Client 2011-10-20 12:11:22 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 16 Fedora Admin XMLRPC Client 2011-10-20 12:13:15 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 17 Fedora Admin XMLRPC Client 2011-10-20 12:17:42 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 18 Fedora End Of Life 2012-08-07 15:16:06 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

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

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping