Systemd has stated this is not their problem: See bug report 883829 and 88167. My value here is testing. I'm happy to test any proposal and provide the results. It is my problem, because Debian Stretch has introduced this behavior. wheezy and jessie did not exhibit this behavior.
My view is: If there are to be large changes , new interface names, mounting
file systems not devices, and asynchronous startup
then the authors of these changes have the responsibility for their quality.
It is not amusing to be caught in the cracks between Debian components.
Please discuss this among yourselves to resolve the issue.
I'v added bug 881675 to the issues. It appears somewhat related.
Please let me know what you need in the way of diagnostic information and
testing.
Regards
Duncan Hare
714 931 7952
From: Ben Hutchings <b...@decadent.org.uk>
To: Duncan Hare <d...@synoia.com>; 883...@bugs.debian.org
Sent: Friday, December 8, 2017 5:36 PM
Subject: Re: Bug#883890: nfs-common: Fully Qualified DNS Name mounts in fstab
fail to be mounted
Control: severity -1 important
Control: tag -1 moreinfo
On Fri, 2017-12-08 at 13:31 -0800, Duncan Hare wrote:
> Package: nfs-common
> Version: 1:1.3.4-2.1
> Severity: grave
> Justification: renders package unusable
>
> File systems correctly mounted after "reached target network online"
>
> File systema rw in both cases.
>
> Case 1
>
> 1. I deleted resolv.conf
> 2. Root fs rw in fstab
> 3. File systems mounted by IP address
> 4. resolve.conf built by end of boot when login possible
>
> proc /proc proc defaults
> 0 0
> /dev/mmcblk0p1 /boot vfat defaults,ro
> 0 2
> #PARTUUID=62bc0a1f-02 / ext4 defaults,noatime
> 0 1
> 192.168.1.10:/nfsroot/r.32.test / nfs defaults,rw
> 0 0
> 192.168.1.10:/nfsroot/b827eb/c23849/var /var nfs defaults,rw
> 0 0
> 192.168.1.10:/nfsroot/b827eb/c23849/home /home nfs defaults,rw
> 0 0
> #browne.danum.local:/nfsroot/b827eb/c23849/home /home nfs defaults,rw
> 0 0
Is that a regular DNS name? The .local LTD is reserved for mDNS, so
it's not good practice to use it for regular DNS. But I doubt that has
anything to do with the problem.
As you say resolv.conf is built during boot, I assume the DNS server is
remote and is discovered through DHCP. Is that correct?
[...]
> Conclusion: name resolution, dns lookup, is not performed at fstbab mount
> time.
>
> This is supposed to work. Who's issue is this? systemd or mount?
It does work, in general.
The problem is likely to be in the systemd configuration. Quoting
systemd.mount(5):
· Network mount units automatically acquire After= dependencies on
remote-fs-pre.target, network.target and network-online.target.
Towards the latter a Wants= unit is added as well.
Depending on which network configuration tools you use, you might need
to define additional dependencies for network-online.target or
remote-fs-pre.target.
Ben.
--
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.
signature.asc
Description: PGP signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
