Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #59571 > unrolled thread
| Started by | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| First post | 2017-12-09 02:40 +0100 |
| Last post | 2017-12-09 04:10 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2017-12-09 02:40 +0100 |
| Subject | Bug#883890: nfs-common: Fully Qualified DNS Name mounts in fstab fail to be mounted |
| Message-ID | <uUChr-3wB-1@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [next] | [standalone]
| From | Duncan Hare <dh@synoia.com> |
|---|---|
| Date | 2017-12-09 04:10 +0100 |
| Message-ID | <uUDGx-4y4-7@gated-at.bofh.it> |
| In reply to | #59571 |
[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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web