Created attachment 488566 [details] dmesg output with systemd debug level enabled Description of problem: at boot root filesystem (ext4, lvm) does not get remounted rw Merry Hell ensues Version-Release number of selected component (if applicable): systemd-20-1.fc15.x86_64 How reproducible: currently every boot. I had this problem a while ago but it went away after an update so I closed the bug Steps to Reproduce: 1.reboot 2.watch services fail to start 3. Actual results: critical system services fail because /var/run and /var/lock are not available Expected results: normal boot Additional info: have attached the dmesg out put with systemd.log_level=debug systemd.log_target=kmsg enabled
Please attach the contents of /etc/fstab Note that /var/run and /var/lock are mounted from tmpfs these days.
# # /etc/fstab # Created by anaconda on Tue Mar 8 15:07:11 2011 # # 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/vg_island-lv_root / ext4 defaults 1 1 UUID=89b19e37-87d4-439b-b211-2c5d6bf5a04b /boot ext4 defaults 1 2 /dev/mapper/vg_island-lv_home /home ext4 defaults 1 2 /dev/mapper/vg_island-lv_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 vsnfs-web.vsnet.gmu.edu:/VS/web /VS/web nfs4 sec=krb5 0 0 vsnfs-home.vsnet.gmu.edu:/VS/home /VS/home nfs4 sec=krb5 0 0
(In reply to comment #1) > Please attach the contents of /etc/fstab > > Note that /var/run and /var/lock are mounted from tmpfs these days. is that set up by systemd-tmpfiles-setup.service?
This is a Dell Optiplex 755 just fyi
problem persists after today's updates. In fact it is worse as now I do not get to a tty on a default boot. However, I tried booting into single user mode and this works cleanly - / mounted rw and an init 5 from there gets me to the desktop.
[ 8.798100] systemd[1]: Found ordering cycle on basic.target/start [ 8.798105] systemd[1]: Walked on cycle path to sockets.target/start [ 8.798109] systemd[1]: Walked on cycle path to dbus.socket/start [ 8.798113] systemd[1]: Walked on cycle path to sysinit.target/start [ 8.798118] systemd[1]: Walked on cycle path to systemd-random-seed-load.service/start [ 8.798122] systemd[1]: Walked on cycle path to local-fs.target/start [ 8.798127] systemd[1]: Walked on cycle path to quotacheck.service/start [ 8.798131] systemd[1]: Walked on cycle path to VS-home.mount/start [ 8.798135] systemd[1]: Walked on cycle path to network.target/start [ 8.798140] systemd[1]: Walked on cycle path to network.service/start [ 8.798144] systemd[1]: Walked on cycle path to iptables.service/start [ 8.798148] systemd[1]: Walked on cycle path to basic.target/start [ 8.798153] systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start This is the same wrong dependency of local-fs.target on NFS as in bug 691075. See if systemd-21 fixes it for you (make sure you have SELinux in permissive mode though).
> See if systemd-21 fixes it for you (make sure you have SELinux in permissive > mode though). ... You can get it from Koji if it's not in updates-testing yet: http://koji.fedoraproject.org/koji/buildinfo?buildID=236648
(In reply to comment #7) > > See if systemd-21 fixes it for you (make sure you have SELinux in permissive > > mode though). > > ... You can get it from Koji if it's not in updates-testing yet: > http://koji.fedoraproject.org/koji/buildinfo?buildID=236648 Indeed it does. Can I leave you to close this as I don't quite know what disposition it gets marked as? Many thanks, Alastair
*** This bug has been marked as a duplicate of bug 691075 ***