[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47706: nfs mount in file-system works only if "nfs4" type is used fo
From: |
Maxim Cournoyer |
Subject: |
bug#47706: nfs mount in file-system works only if "nfs4" type is used for "mount" syscall |
Date: |
Sat, 07 Aug 2021 23:19:14 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello,
fsdfsdfsd3 <fsdfsdfsd3@protonmail.com> writes:
> Hello,
>
> I ran into an issue with trying to mount an nfs file-system in an
> operating-system config.. I managed to trace it back to being an issue with
> the mount syscall.
>
> The following did not work:
> (mount "192.168.1.10:/nas-server" "/mnt/nas-client" "nfs" 0 "addr=192.168.
> 1.10")
> and would result in an error "No route to host"
>
> I changed the type from "nfs" to "nfs4" however and this did work (For
> context; at the command line, both mount.nfs and mount.nfs4 also work fine.,
> mount.nfs also works fine without nfs-utils installed).
>
> This might be fixable by adding another check-procedure option for "nfs4" in
> addition to nfs, but I am sending it your way in case there is something else
> going on.
>
> Thank you!
Does this really work? I seem to recall that the bigger problem would
be that file system services do *not* and cannot currently depend on
networking (while NFS obviously does).
Here's the attached output of
$ guix system shepherd-graph gnu/system/examples/bare-bones.tmpl \
| dot -Tsvg -oout.svg
out.svg
Description: Binary data
We can see that the networking service dependency chain has:
networking --> user-processes --> user-homes --> file-systems
Which to me suggests that it wouldn't be enough to fix the problem you
reported above (or perhaps it is? and NFS would simply fail during the
boot but keep trying until networking becomes available without too much
of an issue?)
Thanks,
Maxim
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#47706: nfs mount in file-system works only if "nfs4" type is used for "mount" syscall,
Maxim Cournoyer <=