Hide Forgot
Description of problem: Boot process hangs for several minutes. Removing rhgb and quiet from grub line shows that it is waiting at: Starting recreate volatile files and directories as described in this thread by someone else experiencing the same problem: http://lists.fedoraproject.org/pipermail/test/2011-April/098702.html Version-Release number of selected component (if applicable): Fedora 15 - systemd 24-1 How reproducible: Always Steps to Reproduce: 1. Install Fedora 15 2. yum -y update 3. Reboot Actual results: Boot takes several extra minutes Expected results: Boot normally Additional info:
(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.