Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #59572

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

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Sent from Yahoo Mail on Android 
 
  On Fri, Dec 8, 2017 at 17:36, Ben Hutchings<ben@decadent.org.uk> wrote:   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.
Ben
Network is set up from kernel parm passed to kernel,  including dns server address from U-boat bootloader.
The address resolution is done by a local windows domain server with a dns for the ms domain.
The mount fails even if there is an hard coded entry in /etc/hosts for address resolution.
How does the mount processing do the name to address lookup?
ThanksDuncan  

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#883890: nfs-common: Fully Qualified DNS Name mounts in fstab fail to be mounted Ben Hutchings <ben@decadent.org.uk> - 2017-12-09 02:40 +0100
  Bug#883890: nfs-common: Fully Qualified DNS Name mounts in fstab fail to be mounted Duncan Hare <dh@synoia.com> - 2017-12-09 04:10 +0100

csiph-web