Created attachment 546705 [details] dmesg output using log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg Description of problem: A fedora 16 x86_64 system stops in bootup at a prompt asking for root password for maintenance. The system has two raid md devices, one of which is mounted using fstab. From the systemd logs, it appears that systemd is trying to mount the raid-6 device before it ready. At 9.15s, it tries to mount the XFS file system /xback2_back1 (md0). This fails at 9.197s (can't read superblock). The md0 device is properly created at 9.2277s. The fstab entry for the device is: /dev/md0 /xback2_back1 xfs nobarrier 1 0 Version-Release number of selected component (if applicable): systemd-37-3.fc16.x86_64 mdadm-3.2.2-13.fc16.x86_64 kernel-3.1.5-1.fc16.x86_64 How reproducible: Almost every time. Some times it succeeds. Steps to Reproduce: 1. Boot system
Looks like the problem discussed recently on the mailing list: http://lists.freedesktop.org/archives/systemd-devel/2011-December/004043.html
Thanks - that's given me a workaround at least. I've labelled the XFS filesystem. Using LABEL=foo in fstab instead of /dev/md0 seems to get the ordering correct, as presumably it can't read a label until the device is ready.
This is still occurring in Fedora 17, and I'm marking it as high severity because it prevents boot from completing.
Please test if adding the following rule to /usr/lib/udev/rules.d/99-systemd.rules helps: SUBSYSTEM=="block", KERNEL=="md*", ATTR{md/array_state}=="|clear|inactive", ENV{SYSTEMD_READY}="0" Add the rule near the other rules that set SYSTEMD_READY.
This worked for me! (In reply to comment #4) > Please test if adding the following rule to > /usr/lib/udev/rules.d/99-systemd.rules helps: > > SUBSYSTEM=="block", KERNEL=="md*", ATTR{md/array_state}=="|clear|inactive", > ENV{SYSTEMD_READY}="0" > > Add the rule near the other rules that set SYSTEMD_READY.
Added upstream: http://cgit.freedesktop.org/systemd/systemd/commit/?id=a96e4839d5ba1b2cbc75d9a998b5f8ccfbb39544
systemd-190-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-190-1.fc18
Package systemd-191-2.fc18, rtkit-0.11-3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18 then log in and leave karma (feedback).
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18 then log in and leave karma (feedback).
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18 then log in and leave karma (feedback).
systemd-44-20.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-20.fc17