Bug 691908

Summary: After an unclean reboot systemd does not mount root filesystems read-write causing a cascade of launch failures
Product: [Fedora] Fedora Reporter: Alastair Neil <aneil2>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 15CC: johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-30 15:51:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
dmesg output with systemd debug level enabled none

Description Alastair Neil 2011-03-29 20:48:41 UTC
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

Comment 1 Lennart Poettering 2011-03-29 22:22:02 UTC
Please attach the contents of /etc/fstab

Note that /var/run and /var/lock are mounted from tmpfs these days.

Comment 2 Alastair Neil 2011-03-30 00:16:16 UTC
#
# /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

Comment 3 Alastair Neil 2011-03-30 00:17:59 UTC
(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?

Comment 4 Alastair Neil 2011-03-30 00:19:01 UTC
This is a Dell Optiplex 755 just fyi

Comment 5 Alastair Neil 2011-03-30 15:29:36 UTC
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.

Comment 6 Michal Schmidt 2011-03-30 15:38:06 UTC
[    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).

Comment 7 Michal Schmidt 2011-03-30 15:39:27 UTC
> 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

Comment 8 Alastair Neil 2011-03-30 15:48:22 UTC
(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

Comment 9 Michal Schmidt 2011-03-30 15:51:30 UTC

*** This bug has been marked as a duplicate of bug 691075 ***