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
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"?
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.
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
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.
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/)
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
Reassigning this to udev, updating udev should trigger initramfs update...
Somewhere in the real root, before starting the udevd.service /sbin/udevadm info --convert-db has to happen..
(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?
(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.
(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).
*** Bug 679842 has been marked as a duplicate of this bug. ***
*** Bug 680601 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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