mounting nfs not working at boot

[qsummon]

I have installed Open Suse 12.1 and I'm having issues mounting the NFS volumes
If I do a mount -a after the boot is done everything goes fine, but I would like to fix it.
Seems like a dependency or name resolution issue. (My nfs server name is nfs)
Here is the messages logs at boot time
Jun 9 13:07:51 xbmcpr mount[1065]: mount.nfs: Failed to resolve server nfs: Name or service not known
Jun 9 13:07:51 xbmcpr mount[1069]: mount.nfs: Failed to resolve server nfs: Name or service not known
Jun 9 13:07:51 xbmcpr nscd[1023]: Starting Name Service Cache Daemon..done
Jun 9 13:07:51 xbmcpr systemd[1]: mnt-media.mount mount process exited, code=exited status=32
Jun 9 13:07:51 xbmcpr systemd[1]: Job remote-fs.target/start failed with result 'dependency'.
Jun 9 13:07:51 xbmcpr systemd[1]: Unit mnt-media.mount entered failed state.
Jun 9 13:07:51 xbmcpr systemd[1]: mnt-pics.mount mount process exited, code=exited status=32
Jun 9 13:07:51 xbmcpr pcscd[944]: Starting PC/SC smart card daemon (pcscd): ..done
Jun 9 13:07:51 xbmcpr systemd[1]: Unit mnt-pics.mount entered failed state.

Here is the /fstab
/dev/disk/by-id/ata-Maxtor_6Y160M0_Y45LAD5E-part2 swap swap defaults 0 0
/dev/disk/by-id/ata-Maxtor_6Y160M0_Y45LAD5E-part3 / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-Maxtor_6Y160M0_Y45LAD5E-part1 /boot ext4 acl,user_xattr 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0

nfs:/vgdata/pch /mnt/media nfs defaults 0 0
nfs:/vgdata/docs/Pics /mnt/pics nfs defaults 0 0
nfs:/vgdata/docs/Mp3 /mnt/mp3 nfs defaults 0 0

[hendersj]

On Sat, 09 Jun 2012 16:46:02 +0000, qsummon wrote:

> I have installed Open Suse 12.1 and I'm having issues mounting the NFS
> volumes If I do a mount -a after the boot is done everything goes fine,
> but I would like to fix it.

If you're using NetworkManager, that can cause the network to not start
before the GUI starts (though that /seems/ to be fixed on my systems),
and without the network, NFS mounts wouldn't be mounted.

You could try switching to using the ifup method and see if that helps.

Jim



--
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

[please_try_again]

I have installed Open Suse 12.1 and I'm having issues mounting the NFS volumes
If I do a mount -a after the boot is done everything goes fine, but I would like to fix it.

The problem is that rpcbind is started too late in systemd.
It is neither a network manager issue, nor openSUSE specific.

I use this workaround (under openSUSE and Fedora) to mount my file server on machines booting with systemd : Running commands (that depend on a process being started) in after.local.

It works in 90% of the cases. When it doesn't, I mount manually. The other option is to use sysinit.

[Knurpht]

The problem is that rpcbind is started too late in systemd.
It is neither a network manager issue, nor openSUSE specific.

I use this workaround (under openSUSE and Fedora) to mount my file server on machines booting with systemd : Running commands (that depend on a process being started) in after.local.

It works in 90% of the cases. When it doesn't, I mount manually. The other option is to use sysinit.

This is what it's all about. Have experienced this on a 12.1 server too. The 11.4 install on the same machine, same configs worked fine, so I tried moving 12.1 back from systemd to sysvinit. Issue solved.

[robin_listas]

On 2012-06-09 20:26, please try again wrote:

> The problem is that rpcbind is started too late in systemd.
> It is neither a network manager issue, nor openSUSE specific.
>
> I use this workaround (under openSUSE and Fedora) to mount my file
> server on machines booting with systemd : http://tinyurl.com/7lhwutx.

I read recently that systemd disregards completely the idea of starting
something after another. Instead it creates a socket or whatever and relies
on activating it when something wants to read it. fstab is (or will be)
superseded, filesystems are mounted when something want to read them, etc.
I did not understand it completely, but it scares me a lot.

The article is in Spanish, so it is no use for you, I'm afraid.


systemd, otro reemplazo de init

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)

[deano_ferrari]

This https://wiki.archlinux.org/index.php/Systemd article mentions

Remote filesystem mounts

If you have NFS mounts listed in /etc/fstab then systemd will attempt to mount them but will typically do so too early (before networking has been configured). To get the timing correct we need to tell systemd explicitly that the mount depends on networking and rpc.statd. To do this, create the following file:

/etc/systemd/system/<mount-unit-name>.mount

[Unit]  Description=<mountpoint>  Wants=rpc-statd.service  After=network.target rpc-statd.service     [Mount]  What=<server>:<share>  Where=<mountpoint>  Type=nfs

In the above:

• mount-unit-name is the full path to the mountpoint in an escaped format. For example, a mount unit for /usr/local must be named usr-local.mount.
• mountpoint is the local mountpoint
• server:share specifies the remote filesystem in the same manner as for /etc/fstab

See systemd.unit(5) and systemd.mount(5) for further details.
A similar approach will probably be required for other remote filesystem types such as nfs4 and cifs.
Alternatively, you can mark these entries in /etc/fstab with the x-systemd.automount and x-systemd.device-timeout=# options (see systemd.mount(5)). Make sure that if you also include defaults as a mount option, that you override the implicit auto with noauto. This will cause the device to be mounted on first access, similar to Autofs.

This Gentoo Wiki page also has some work-in-progress comments:

systemd - Gentoo Linux Wiki

[robin_listas]

On 2012-06-10 01:36, deano ferrari wrote:
>
> This https://wiki.archlinux.org/index.php/Systemd article mentions
>> REMOTE FILESYSTEM MOUNTS
>> If you have NFS mounts listed in /etc/fstab then systemd will attempt
>> to mount them but will typically do so too early (before networking has
>> been configured). To get the timing correct we need to tell systemd
>> explicitly that the mount depends on networking and rpc.statd. To do
>> this, create the following file:
>>
>> /etc/systemd/system/<mount-unit-name>.mount

What an horrible solution. They really broke fstab :-/

--
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)

[deano_ferrari]

IMHO, this is one area where all the dependencies are likely to vary between different set-ups, and so fraught with potential complications. Here's an old Fedora thread which typifies some o the discussions I've read on the subject:

Fedora 15: NFS mount in fstab hangs boot [Archive] - FedoraForum.org

I note that man systemd.mount mentions

/etc/fstab

Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).
When reading /etc/fstab a few special mount options are understood by systemd which influence how dependencies are created for mount points from /etc/fstab. systemd will create a dependency of type Wants from either local-fs.target or remote-fs.target, depending whether the file system is local or remote. If x-systemd.automount is set, an automount unit will be created for the file system. See systemd.automount(5) for details. If x-systemd.device-timeout= is specified it may be used to configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab. Specify a time in seconds or explicitly specifiy a unit as s, min, h, ms.
If a mount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.

but from what I've read, the various fstab options for remote file systems appear not to work in some cases.

I'd be interested in hearing others experiences about this.

[deano_ferrari]

I thought this may be useful to others who come searching:

http://www.happyassassin.net/2011/05...remote-shares/

[djh-novell]

deano ferrari wrote:
> I thought this may be useful to others who come searching:
>
> http://tinyurl.com/3cshybt

"So boot runs as fast as possible, and as soon as you actually try to
access the share, it gets mounted. Thanks, systemd!"

So instead of bringing up a system to an operational, usable state, it's
brought up to a state where the first time any operation is tried,
there's a long delay?? NO THANKS, systemd. What a *$£! stupid idea.

When I boot a system, I want it to work fully after it's finished
booting. And work properly, including performance targets.