Hide Forgot
Description of problem: On rhel nfs client loop mount of the image present in nfs share is not getting mounted with _netdev option. Version-Release number of selected component (if applicable): 3.10.0-327.4.4.el7.x86_64 (RHEL 7.2) How reproducible: Everytime Steps to Reproduce: 1. Export a nfs share from RHEL machine containing image. 2. Mount that share on nfs client and add the entry in /etc/fstab with _netdev option. 3. Loop mount the image present in share on nfs client and add the entry for same /etc/fstab without _netdev option and with x-systemd.requires for original nfs filesystem mounted in Step 2. Actual results: Without _netdev option for the loop Expected results: As we have added dependency for original nfs filesystem in loop back device it should get mounted with _netdev option. Additional info: Workaround is to add _netdev option for loop mount device. ==> Working Configuration 10.65.6.158:/myexport /mnt/install nfs ro,_netdev 0 0 /mnt/install/rhel-server-7.1-x86_64-dvd.iso /repodvd iso9660 loop,ro,x-systemd.requires=mnt-install.mount,_netdev 0 0 ==> Not-working configuration. 10.65.6.158:/myexport /mnt/install nfs ro,_netdev 0 0 /mnt/install/rhel-server-7.1-x86_64-dvd.iso /repodvd iso9660 loop,ro,x-systemd.requires=mnt-install.mount 0 0
Typo In Description of the Bug. It should be read as : On rhel nfs client loop mount of the image present in nfs share is not getting mounted **WITHOUT** _netdev option.
Can you please add debug to kernel cmdline, reproduce the issue and post here output of journalctl -b?
Yes, or you can just add thet directly during boot in grub.
Looking at the latest upstream fstab-generator, setting dependencies happens in the following: if (streq(me->mnt_type, "swap")) k = add_swap(what, me, makefs*MAKEFS | growfs*GROWFS | noauto*NOAUTO | nofail*NOFAIL); else { bool automount; const char *post; automount = fstab_test_option(me->mnt_opts, "comment=systemd.automount\0" "x-systemd.automount\0"); if (initrd) post = SPECIAL_INITRD_FS_TARGET; else if (mount_is_network(me)) post = SPECIAL_REMOTE_FS_TARGET; else post = SPECIAL_LOCAL_FS_TARGET; k = add_mount(arg_dest, what, canonical_where ?: where, canonical_where ? where: NULL, me->mnt_type, me->mnt_opts, me->mnt_passno, makefs*MAKEFS | growfs*GROWFS | noauto*NOAUTO | nofail*NOFAIL | automount*AUTOMOUNT, post, fstab_path); } Note that the "mount_is_network(me)" operation determines if the mount is to be tied to either the local-fs.target or remote-fs.target. That function evaluates as: static bool mount_is_network(struct mntent *me) { assert(me); return fstab_test_option(me->mnt_opts, "_netdev\0") || fstype_is_network(me->mnt_type); } And: bool fstype_is_network(const char *fstype) { const char *x; x = startswith(fstype, "fuse."); if (x) fstype = x; return STR_IN_SET(fstype, "afs", "cifs", "smbfs", "sshfs", "ncpfs", "ncp", "nfs", "nfs4", "gfs", "gfs2", "glusterfs", "pvfs2", /* OrangeFS */ "ocfs2", "lustre"); } In lieu of setting "_netdev", the mechanism needed here would be a feature enhancement. Any feature of this type would have to be upstream first, to add awareness of parent filesystems. In other words, in the instance that you are mounting: parent /parent child /parent/child The expectation would be that if the parent filesystem is a network-requiring filesystem, then the child would not have a Before=local-fs.target directive. It would instead get a Before=remote-fs.target. I am more than a bit concerned that this implicit behaviour is much less ideal over the explicit use of the "_netdev" option. It would then result in odd child mount behaviours in the event that an incorrect "_netdev" configuration option is used in a parent mount. As a result of the above state of the implementation, and that the initial investigation that started this bug report has been closed, I am closing this bug as WONTFIX in the RHEL 7 stream. In the event that demand is found to continue pursuit of this type of change, please open a subsequent bug report for RHEL 8 and reference this previous instance. From there, the guidance would be to file a request with the upstream project and pursue a solution there.