Hide Forgot
Description of problem: I did a clean install of fedora 15 beta on the local hard drive. This included /home being on the local disk as well. I later edited the /etc/fstab to replace the local /home with NFS mounted /home from our server. After rebooting I was hoping to have NFS mounted /home but it is still getting the old local /home. If I do umount /home and mount /home as root, I do get the right NFS mounted /home. This used to work just fine on F14 but I saw some discussion about something being pre-mounted by systemd? However, even if something is pre-mounted, the /etc/fstab must be respected no matter what.
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...