Bug 698793

hmm?

So you have two entries for the same mount point in /etc/fstab? Or what are you saying?

Are you using NM? If so you might need to run "systemctl enable NetworkManager-wait-online.service" to ensure that the boot waits for the net to be up before continuing. (requires newest NM)

No, here is my /etc/fstab (hostnames removed):


#
# /etc/fstab
# Created by anaconda on Thu Apr 21 08:40:27 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_jme-lv_root /                       ext4    defaults        1 1
UUID=8bfc5ce8-0b3f-4177-aa4e-79590e8996dd /boot                   ext4    defaul
ts        1 2
# /dev/mapper/vg_jme-lv_home /home                   ext4    defaults        1 2
zzz.xxx.yyy:/home	     /home		     nfs     defaults	     0 0
zzz.xxx.yyy:/usr/local /usr/local		     nfs     defaults	     0 0
/dev/mapper/vg_jme-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

During the boot the nfs mount of /home fails and after that it somehow has automagically mounted the local /home partition.

I will try the systemctl setting - I hope this will be enabled by default so that things will work out of the box without hacking...

are you saying there is a separate local /home partition? And this is mounted without any mention in /etc/fstab of it?

Maybe your initrd contains wrong data... if you rebuild the initrd with "dracut -f", does that help?

No, NetworkManager-wait-online.service will not be enabled by default. Delaying the boot due to external network problems is a bad idea. Only NFS needs that really. And that's kinda borked...

will run dracut tomorrow. This used to work just fine but not anymore. Why would one need to now run dracut after editing /etc/fstab ?

As for NFS.... I just want to have my /home partition NFS mounted and with F15 this has been very painful. First by default selinux disallows this and gives out cryptic messages about this (only in /var/adm/messages; yes you can allow this by changing the selinux default settings, if you are familiar with selinux configs) and now network manager needs these strange settings. I understand that you are trying to perhaps target different audience but for me all this is becoming too painful because you need to tweak way too many things to get the box working. In addition to NFS being messed up, ypbind seems to suffer from the same blues.

Running dracut did not help. If NFS mount fails during the boot, the system somehow magically mounts the local /home which is not even mentioned in /etc/fstab.

I now added the networkmanager setting. This fixed the ypbind startup but still instead of the NFS /home in my /etc/fstab, I get the local /home. After every boot I have to do: umount /home and mount /home

Furthermore, there is probably some issue with ypbind and gnome gdm as it always gets stuck the first time I try to login. Killing it and restarting will help.

What does "systemctl show home.mount" print after boot?

Could you boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" added to your kernel command line and attach here the output of "dmesg"?
Thanks.

Here is the systemctl output - I will boot later - gotta work now ;-) This is after I have booted and done umount & mount.

(my nfs server name replaced with xxx.yyy.zzz in the output)

Id=home.mount
Names=home.mount
Requires=systemd-logger.socket -.mount
RequiredBy=remote-fs.target
Conflicts=umount.target
Before=umount.target remote-fs.target
After=systemd-logger.socket network.target -.mount
Description=/home
LoadState=loaded
ActiveState=active
SubState=mounted
InactiveExitTimestamp=Thu, 28 Apr 2011 08:47:05 -0700
InactiveExitTimestampMonotonic=43887047
ActiveEnterTimestamp=Thu, 28 Apr 2011 08:47:05 -0700
ActiveEnterTimestampMonotonic=43887047
ActiveExitTimestamp=Thu, 28 Apr 2011 08:47:02 -0700
ActiveExitTimestampMonotonic=41493420
InactiveEnterTimestamp=Thu, 28 Apr 2011 08:47:02 -0700
InactiveEnterTimestampMonotonic=41493420
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=no
OnFailureIsolate=no
IgnoreOnIsolate=yes
DefaultControlGroup=name=systemd:/system/home.mount
ControlGroup=cpu:/system/home.mount name=systemd:/system/home.mount
NeedDaemonReload=no
JobTimeoutUSec=0
ConditionTimestampMonotonic=0
ConditionResult=no
Where=/home
What=xxx.yyy.zzz:/home
Options=rw,relatime,rw,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tc
Type=nfs
TimeoutUSec=3min
UMask=0002
LimitCPU=4294967295
LimitFSIZE=4294967295
LimitDATA=4294967295
LimitSTACK=4294967295
LimitCORE=4294967295
LimitRSS=4294967295
LimitNOFILE=1024
LimitAS=4294967295
LimitNPROC=32110
LimitMEMLOCK=65536
LimitLOCKS=4294967295
LimitSIGPENDING=32110
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=4294967295
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=kmsg
StandardError=inherit
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=1048576
PrivateTmp=no
SameProcessGroup=yes
KillMode=control-group
KillSignal=15
ControlPID=0
DirectoryMode=0755

can you also please attach /proc/self/mounts after boot?

OK, now here is everything right after the boot (no umount & mount to get the NFS home performed).

files attached.

Created attachment 496639 [details]
systemctl output

Created attachment 496640 [details]
/proc/self/mounts

Created attachment 496641 [details]
dmesg

Looks like the bind mount of /home on itself done by the sandbox service is interfering:

[    3.005842] systemd[1]: Installed new job home.mount/start as 89
...
[    7.674139] systemd[1]: About to execute: /etc/rc.d/init.d/sandbox start
...
[    7.686044] systemd[1]: Forked /etc/rc.d/init.d/sandbox as 778
[    7.686071] systemd[1]: sandbox.service changed dead -> start
...
[    7.807615] systemd[1]: Got SIGCHLD for process 778 (sandbox)
[    7.807646] systemd[1]: Child 778 died (code=exited, status=0/SUCCESS)
[    7.807649] systemd[1]: Child 778 belongs to sandbox.service
...
[    7.948733] systemd[1]: home.mount changed dead -> mounted
[    7.948739] systemd[1]: Job home.mount/start finished, result=done

systemd must have got confused by the mount appearing on /home.

Does disabling the sandbox service make the problem go away?

I disabled sandbox and now I did not get the local /home but I did not get the NFS /home either. Issuing mount /home right after the boot gives me the NFS mounted /home.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Is this still a problem or can this bug be closed?

I have given up hope to get yellow pages and nfs working properly with network manager, selinux etc., so I have disabled all of these nuisances. I can see, however, that a newly installed F16 system will not start up properly with yellow pages or nfs, the bug is not gone for sure. Everything has to be done by hand (start network, restart yellow pages, remount nfs) - very annoying. Of course one can spend time on getting everything to come up but there has to be a better way to do this so that it will work out of the box (the installer knows already about yellow pages but maybe it should know about nfs mounts too; at least then it would have all the necessary info to set things up so that everything works).

Is that on fully updated F16 box ( there where some issues with the nfs unit file http://koji.fedoraproject.org/koji/buildinfo?buildID=293769 ) also relatively new fixes in ypbind http://koji.fedoraproject.org/koji/buildinfo?buildID=295282.
And make sure you have enable NetworkManager-wait-online.service

Not sure how the installer fits into this picture but if it actually does you should file a separated bug against anaconda about that.

Well, if the installer knows about the nfs mounts, it could update the /etc/fstab and enable the NetworkManager-wait-online.service automatically and users would not have to wonder why things are not working. I think ypbind would need this service enabled as well because you cannot login without actually being able to authenticate through yp.

The installer issue is something you need to file a bug or RFE against anaconda and bugs/enhancments to units is something that needs to be discussed with it's maintainer(s) so the ypbind issue is something you need to file a bug against ypbind and discuss with it's maintainer. ( same thing applies to nfs units ).

Is there anything else left here and is relevant to systemd or can this bug be closed?

Yes, you can close it but folks please make sure that these "new fancy things" don't break the "old stuff".

We do our best from the systemd site the rest is up to the relevant maintainers for example we still have 50 components with units left in bugzilla from the F15/F16 development cycles and addition new 65 ( nine new components have ship native systemd units in rawhide at the time of this writing ) components that have native systemd units that are not yet shipped ( and those that have been filed for F15/F16 wont be shipped in F15/F16 due to project policies ).

As you can see we are doing our best in better integrate service with systemd but our effort is only going so far...