Bug#883829: Bug#883890: nfs-common: Fully Qualified DNS Name mounts in fstab fail to be mounted

[Duncan Hare]

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 <ben at decadent.org.uk>
 To: Duncan Hare <dh at synoia.com>; 883890 at 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.


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20171209/23b97de5/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20171209/23b97de5/attachment-0004.sig>