If the filesystem that the root or netmount init script (re)mounts is nfs4, it will have to depend on rpc.idmapd. I assume the test could look similar to need_portmap() in netmount. root is lacking such dependencies entirely… Reproducible: Always
How can I know if a filesystem is nfs4? Is this a type that will appear in fstab?
(In reply to comment #1) > How can I know if a filesystem is nfs4? Is this a type that will appear > in fstab? Yes, NFSv3 is type=nfs (or fs=server:/path leading to automatic type detection) and NFSv3 is type=nfs4.
Also, looking at need_portmap() in /etc/init.d/netmount, you might be able to use fstabinfo --fstype nfs4. A quick test on my machine shows that it outputs the mountpoints of nfs4 mounts in fstab.
*** Bug 427998 has been marked as a duplicate of this bug. ***
depending on just rpc.idmapd is not sufficient. nfsmount already handles the edge cases.
@vapier: I think the change I made here takes care of this. 3863c11 Correct?
(In reply to comment #6) it does not. check out the depend() in nfsmount.
If nfsmount exists, why is there duplicate functionality in netmount? Can you not just replace need_portmap() with need_nfsmount() and be done with it?
@vapier: Why does netmounts duplicate the functionality of nfsmounts for NFS* file systems? Would it be a good idea to re-code netmounts to skip nfs mounts and allow nfsmounts to take care of them?
Created attachment 323800 [details, diff] 0001-netmount-do-not-handle-NFS-mounts.patch @vapier and all: This patch removes NFS handling from netmounts. I think this will be the best way to go for OpenRC, because no other network file system we support directly requires daemons on the client side. What are your thoughts, both about the patch and about the way I want to take OpenRc?
(In reply to comment #10) > Created attachment 323800 [details, diff] [details, diff] > 0001-netmount-do-not-handle-NFS-mounts.patch > > @vapier and all: > This patch removes NFS handling from netmounts. I think this will be the > best way to go for OpenRC, because no other network file system we > support directly requires daemons on the client side. > > What are your thoughts, both about the patch and about the way I want to > take OpenRc? Patch appears good to me. Just please make sure netmount never tries to mount nfs/nfs4, because that might silently work and produce wrong results, if the daemons are not running. Other ways to handle this would be: * Issue a warning if fstype=nfs* and nfsmount is not running. Requires use=nfsmount and a call to service_started nfsmount. * Figure out whether there are nfs* filesystems to be mounted and set need=nfsmount in that case. Just like need_portmap() does.
(In reply to comment #11) > Just please make sure netmount never tries to > mount nfs/nfs4, because that might silently work and produce wrong results, > if the daemons are not running. I.e. add a comment to the "continue", mentioning that this is handled by nfsmount, so that no one later removes it again.
(In reply to comment #11) > (In reply to comment #10) > > Created attachment 323800 [details, diff] [details, diff] [details, diff] > > 0001-netmount-do-not-handle-NFS-mounts.patch > > > > @vapier and all: > > This patch removes NFS handling from netmounts. I think this will be the > > best way to go for OpenRC, because no other network file system we > > support directly requires daemons on the client side. > > > > What are your thoughts, both about the patch and about the way I want to > > take OpenRc? > Patch appears good to me. Just please make sure netmount never tries to > mount nfs/nfs4, because that might silently work and produce wrong results, > if the daemons are not running. This patch does that; notice that in the case statements it uses continue to skip the rest of the loop for nfs|nfs4 types. > Other ways to handle this would be: > * Issue a warning if fstype=nfs* and nfsmount is not running. Requires > use=nfsmount and a call to service_started nfsmount. > * Figure out whether there are nfs* filesystems to be mounted and set > need=nfsmount in that case. Just like need_portmap() does. (In reply to comment #12) > (In reply to comment #11) > > Just please make sure netmount never tries to > > mount nfs/nfs4, because that might silently work and produce wrong results, > > if the daemons are not running. > I.e. add a comment to the "continue", mentioning that this is handled by > nfsmount, so that no one later removes it again. The problem with all of this is that it directly refers to a service that is not part of OpenRc, so if the nfs-utils folks decide to change the name of their service, I have to do another release just because of that.
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > Created attachment 323800 [details, diff] [details, diff] [details, diff] [details, diff] > > > 0001-netmount-do-not-handle-NFS-mounts.patch > > > > > > @vapier and all: > > > This patch removes NFS handling from netmounts. I think this will be the > > > best way to go for OpenRC, because no other network file system we > > > support directly requires daemons on the client side. > > > > > > What are your thoughts, both about the patch and about the way I want to > > > take OpenRc? > > Patch appears good to me. Just please make sure netmount never tries to > > mount nfs/nfs4, because that might silently work and produce wrong results, > > if the daemons are not running. > > This patch does that; notice that in the case statements it uses continue to > skip the rest of the loop for nfs|nfs4 types. s.b. > > Other ways to handle this would be: > > * Issue a warning if fstype=nfs* and nfsmount is not running. Requires > > use=nfsmount and a call to service_started nfsmount. > > * Figure out whether there are nfs* filesystems to be mounted and set > > need=nfsmount in that case. Just like need_portmap() does. > > (In reply to comment #12) > > (In reply to comment #11) > > > Just please make sure netmount never tries to > > > mount nfs/nfs4, because that might silently work and produce wrong results, > > > if the daemons are not running. > > I.e. add a comment to the "continue", mentioning that this is handled by > > nfsmount, so that no one later removes it again. > > The problem with all of this is that it directly refers to a service that is > not part of OpenRc, so if the nfs-utils folks decide to change the name of > their service, I have to do another release just because of that. The request there was to add *a comment*, so that *developers of OpenRC* do not remove the continue line, because they think it is unnecessary (or whatever), breaking nfs mounts in the process.
This has been implemented along with a comment explaining that netmount does not support nfs file systems in commit a0fe1c5.
(In reply to comment #15) > This has been implemented along with a comment explaining that netmount > does not support nfs file systems in commit a0fe1c5. Thanks!
*** Bug 446690 has been marked as a duplicate of this bug. ***
