Bug#883829: closed by Michael Biebl <biebl at debian.org> (Re: Bug#883829: systemd: Fully qualified host names in fstab results in mounts failing)

Duncan Hare dh at synoia.com
Fri Dec 8 21:05:32 GMT 2017


Michael
File systems correctly mounted after "reached target network online"
File systema rw in both cases.

Case 1

1. I deleted resolv.conf2. Root fs rw in fstab3. 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
tmpfs                                    /tmp    tmpfs   nodev,nosuid,size=1%,mode=1777 0 0

Case 2
1. I deleted resolv.conf2. Root fs rw in fstab3. File systems mounted by server name
4. Mount failed.
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
tmpfs                                    /tmp    tmpfs   nodev,nosuid,size=1%,mode=1777 0 0

Case 2
1. resolv.conf not deleted.
2. Root fs rw in fstab3. File systems mounted by server name
4. Mount failed.
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
tmpfs                                    /tmp    tmpfs   nodev,nosuid,size=1%,mode=1777 0 0
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?
Thanks
 Duncan Hare

714 931 7952

      From: Debian Bug Tracking System <owner at bugs.debian.org>
 To: Duncan Hare <dh at synoia.com> 
 Sent: Friday, December 8, 2017 12:30 PM
 Subject: Bug#883829 closed by Michael Biebl <biebl at debian.org> (Re: Bug#883829: systemd: Fully qualified host names in fstab results in mounts failing)
   
This is an automatic notification regarding your Bug report
which was filed against the systemd package:

#883829: systemd: Fully qualified host names in fstab results in mounts failing

It has been closed by Michael Biebl <biebl at debian.org>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Michael Biebl <biebl at debian.org> by
replying to this email.


-- 
883829: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883829
Debian Bug Tracking System
Contact owner at bugs.debian.org with problemsAm 08.12.2017 um 20:43 schrieb Duncan Hare:
> Michael
> 
> u-boot is a bootloader. The u-boot script load  the kernel from a
> server,, constructs the kernel commandline,
> and the u-boot script is complete when the kernel starts, well before
> these failures.
> 
> In the kernel command line there is a dns server address, 192.168.1.12
> passed to the linux kernel on the kernel command line. 
> 
> How the DNS server address is passed to resolveconf by the kernal I do
> not know. That's an interface between the kernel and systemd.
> 

Nope, systemd is not directly involved in this.
In any case, this is nothing systemd can fix for you, thus closing.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Package: systemd
Version: 232-25+deb9u1
Severity: grave
Justification: causes non-serious data loss

This works, the home directory gets mounted

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    
tmpfs                                    /tmp    tmpfs  nodev,nosuid,size=1%,mode=1777 0 0

This /home mount fails, probably becuse no dns lookup is performed. It is supposed to work:


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
browne.danum.local:/nfsroot/b827eb/c23849/home /home  nfs    defaults,rw                    0 0    
tmpfs                                    /tmp    tmpfs  nodev,nosuid,size=1%,mode=1777 0 0

After the failed scenario when boot is complete, This fails after mounting the home 
directory by shell command:

sudo mkdir /abc
sudo mount browne:/nfsroot/b827eb/c23849/home /abc

and normally this works:
 
sudo mkdir /abc
sudo mount browne:/nfsroot/b827eb/c23849/home abc

and yes, my local domain suffix is .local, becuse it is a Microsoft domain.



-- Package-specific info:

-- System Information:
Distributor ID:    Raspbian
Description:    Raspbian GNU/Linux 9.1 (stretch)
Release:    9.1
Codename:    stretch
Architecture: armv7l

Kernel: Linux 4.9.59-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser        3.115
ii  libacl1        2.2.52-3
ii  libapparmor1    2.11.0-3
ii  libaudit1      1:2.6.7-2
ii  libblkid1      2.29.2-1
ii  libc6          2.24-11+deb9u1
ii  libcap2        1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcc1        1:6.3.0-18+rpi1
ii  libgcrypt20    1.7.6-2+deb9u2
ii  libgpg-error0  1.26-2
ii  libidn11        1.33-1
ii  libip4tc0      1.6.0+snapshot20161117-6
ii  libkmod2        23-2
ii  liblz4-1        0.0~r131-2
ii  liblzma5        5.2.2-1.2
ii  libmount1      2.29.2-1
ii  libpam0g        1.1.8-3.6+rpi1
ii  libseccomp2    2.3.1-2.1
ii  libselinux1    2.6-3
ii  libsystemd0    232-25+deb9u1
ii  mount          2.29.2-1
ii  procps          2:3.3.12-3
ii  util-linux      2.29.2-1

Versions of packages systemd recommends:
ii  dbus            1.10.22-0+deb9u1
ii  libpam-systemd  232-25+deb9u1

Versions of packages systemd suggests:
ii  policykit-1        0.105-18
pn  systemd-container  <none>
pn  systemd-ui        <none>

Versions of packages systemd is related to:
pn  dracut          <none>
ii  initramfs-tools  0.130
ii  udev            232-25+deb9u1

-- no debconf information


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20171208/ed772179/attachment-0002.html>


More information about the Pkg-systemd-maintainers mailing list