Bug 694916

(In reply to comment #0)
> as described in this thread by someone else experiencing the same problem:
> http://lists.fedoraproject.org/pipermail/test/2011-April/098702.html

cornel panceac reported it to Bugzilla as bug 694647.
Is your problem caused by the same kind of misconfiguration in /etc/fstab?
If yes, was the fstab created by Anaconda that way?

I am seeing the same timeouts described in the other bug:
[  200.602693] systemd[1]: Job dev-mapper-vg00\x2dswap.device/start timed out.
[  201.638086] systemd[1]: Job dev-disk-by\x2duuid-2e13ec7d\x2d04f9\x2d467b\x2da388\x2d5ba19abe19db.device/start timed out.

My fstab was created by F14 anaconda:
#
# /etc/fstab
# Created by anaconda on Wed Aug 18 12:14:02 2010
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/luks-2e13ec7d-04f9-467b-a388-5ba19abe19db /                       ext4    defaults        1 1
UUID=34f0399e-eb32-4064-b00a-6052d89f6ab7 /boot                   ext4    defaults        1 2
/dev/mapper/vg00-swap   swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

the luks one sort of make sense, since it looks like its trying to use the wrong uuid; I replaced it with a line that reads:
UUID=2e13ec7d-04f9-467b-a388-5ba19abe19db       /       ext4    defaults        1 1
and that timeout is gone. But I tried both of these for swap and neither is working any better:
LABEL=swap                                     swap    swap    defaults        0 0
UUID=ebf28d22-643f-4d76-84af-c9b5b479ee43      swap    swap    defaults        0 0

What else might be causing the issue? Also, this probably needs to be considered a bug, whereas the other ticket was not, since it is likely upgraders will see these issues.

swaplabel /dev/mapper/vg00-swap
LABEL: swap
UUID:  ebf28d22-643f-4d76-84af-c9b5b479ee43

  --- Logical volume ---
  LV Name                /dev/vg00/swap
  VG Name                vg00
  LV UUID                tKve08-54RY-iuNP-Z0YF-yUdn-EG9E-XdBSfd
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                4.00 GiB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

I configured labels for swap and root and got things working smoothly with:

UUID=34f0399e-eb32-4064-b00a-6052d89f6ab7 	/boot   ext4    defaults       1 2
LABEL=root					/	ext4	defaults       1 1
LABEL=swap					swap	ext4	defaults       0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

I could not get it working properly with using UUID's for root and swap, but as of right now boot times are MUCH faster using labels.

One note above, I mentioned that the UUID for / was wrong, but then you'll see I used the same in the fstab when i changed to using "UUID=..." - I neglected to mention I used tune2fs to change the UUID to match; I'm not sure if that is such a great idea, but it does not seem to be hurting anything.

There is an obvious error in the swap line above - almost as soon as I posted the comment I realized what I did. Unfortunately as soon as I fixed the line the issue reappeared. 

However, after look at  dmesg better and seeing a line that read:
dracut: inactive '/dev/vg00/swap' 
and doing some reading I tried running:
dracut -f 
and all my problems went away.

I have since gotten things working using all labels, all UUID's, and the original lines from my fstab:
/dev/mapper/luks-2e13ec7d-04f9-467b-a388-5ba19abe19db   /     ext4 defaults  1 1
/dev/mapper/vg00-swap                                   swap  swap defaults  0 0
UUID=34f0399e-eb32-4064-b00a-6052d89f6ab7               /boot ext4 defaults  1 2
#UUID=1ae1c54c-c55d-45ac-b6cb-bf8fe89e30f0              swap  swap defaults  0 0
#UUID=2e13ec7d-04f9-467b-a388-5ba19abe19db              /     ext4 defaults  1 1
#LABEL=boot     /boot       ext4    defaults        1 2
#LABEL=swap     swap        swap    defaults        0 0
#LABEL=root     /           ext4    defaults        1 1
tmpfs           /dev/shm    tmpfs   defaults        0 0
devpts          /dev/pts    devpts  gid=5,mode=620  0 0
sysfs           /sys        sysfs   defaults        0 0
proc            /proc       proc    defaults        0 0

I stupidly did not save the original problem initramfs, but I think this is reproducible when doing an upgrade, since I had the same issue on a vm I also used preupgrade on. The vm had several other issues because the install failed the first time through and I ended up wiping it out and doing a clean install, so I no longer have it to look at either. 

I will try to set up a F14 system tomorrow, upgrade it, and see if the same thing happens.

I was able to confirm this bug on another system:

How reproducible:
I have seen this on a T61, KVM VM, and VMWare Player VM now. In each case I used preupgrade to upgrade from F14 x86_64 to F15 x86_64 - seems 100% reproducible. Simply running `dracut -f` did not fix it after upgrading to Fedora 15; instead I had to first update to dracut-009-5 and then rerun it.

Steps to Reproduce:
1. Install Fedora 14 x86_64 using an LVM config similar to above
2. yum -y update
3. yum --enablerepo=updates-testing -y install preupgrade (need 1.1.9-1.fc14)
4. Run preupgrade and install Fedora 15
5. Each boot and shutdown will now take several minutes
6. yum -y update dracut (from 008-7 to 009-5 in updates-testing)
7. dracut -f
8. Boot times return to normal.

So even though it looks like systemd is timing out it looks like this might be a dracut bug.

dracut-009-5 is already on the way to F15 stable:
https://admin.fedoraproject.org/updates/dracut-009-5.fc15

Looks like a problem with LVM in dracut. tentatively reassigning to dracut.