<html><head></head><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:10px"><div id="yui_3_16_0_ym19_1_1512837160919_19359"><span id="yui_3_16_0_ym19_1_1512837160919_22094">Systemd has stated this is not their problem:</span></div><div id="yui_3_16_0_ym19_1_1512837160919_22171"><span id="yui_3_16_0_ym19_1_1512837160919_22094"><br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_25746" dir="ltr"><span id="yui_3_16_0_ym19_1_1512837160919_25776">See bug report 883829 and </span><span title="Re: Bug#881675: systemd root filesystem remount fails when ZFS booting and /dev/nfs specied in fstab" id="yui_3_16_0_ym19_1_1512837160919_25777">88167. </span></div><div id="yui_3_16_0_ym19_1_1512837160919_25711"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1512837160919_25712"><span id="yui_3_16_0_ym19_1_1512837160919_25713">My value here is testing. </span><span id="yui_3_16_0_ym19_1_1512837160919_25714">I'm happy to test any proposal and provide the results.</span></div><div><span id="yui_3_16_0_ym19_1_1512837160919_22094"></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22265"><span id="yui_3_16_0_ym19_1_1512837160919_22094"><br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22289"><span id="yui_3_16_0_ym19_1_1512837160919_22094">It is my problem, because Debian Stretch has introduced this behavior. wheezy and jessie did not exhibit this behavior.<br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22416"><span id="yui_3_16_0_ym19_1_1512837160919_22094"><br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22509"><span id="yui_3_16_0_ym19_1_1512837160919_22094">My view is: If there are to be large changes , new interface names, mounting file systems not devices, and asynchronous startup <br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22534"><span id="yui_3_16_0_ym19_1_1512837160919_22094">then the authors of these changes have the responsibility for their quality.<br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22558"><span id="yui_3_16_0_ym19_1_1512837160919_22094"><br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22559"><span id="yui_3_16_0_ym19_1_1512837160919_22094">It is not amusing to be caught in the cracks between Debian components.<br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_22314"><span id="yui_3_16_0_ym19_1_1512837160919_22094"><br></span></div><div id="yui_3_16_0_ym19_1_1512837160919_19289" dir="ltr"><div id="yui_3_16_0_ym19_1_1512837160919_22365" dir="ltr">Please discuss this among yourselves to resolve the issue. <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1512837160919_25516"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1512837160919_25517">I'v added bug<span title="Re: Bug#881675: systemd root filesystem remount fails when ZFS booting and /dev/nfs specied in fstab" id="yui_3_16_0_ym19_1_1512837160919_25572"> 881675 to the issues. It appears somewhat related.<br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1512837160919_22711"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1512837160919_22712">Please let me know what you need in the way of diagnostic information and testing.<br></div><div id="yui_3_16_0_ym19_1_1512837160919_22366"><br></div><div id="yui_3_16_0_ym19_1_1512837160919_25568">Regards <br></div></div><div class="signature" id="yui_3_16_0_ym19_1_1512837160919_19358">Duncan Hare<br><br>714 931 7952</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1512837160919_22533"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1512837160919_25889" style="display: block;"> <div style="font-family: verdana, helvetica, sans-serif; font-size: 10px;" id="yui_3_16_0_ym19_1_1512837160919_25888"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1512837160919_25887"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Ben Hutchings <ben@decadent.org.uk><br> <b><span style="font-weight: bold;">To:</span></b> Duncan Hare <dh@synoia.com>; 883890@bugs.debian.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Friday, December 8, 2017 5:36 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: Bug#883890: nfs-common: Fully Qualified DNS Name mounts in fstab fail to be mounted<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_ym19_1_1512837160919_25886"><br><div dir="ltr" id="yui_3_16_0_ym19_1_1512837160919_25885">Control: severity -1 important<br clear="none">Control: tag -1 moreinfo<br clear="none"><br clear="none">On Fri, 2017-12-08 at 13:31 -0800, Duncan Hare wrote:<br clear="none">> Package: nfs-common<br clear="none">> Version: 1:1.3.4-2.1<br clear="none">> Severity: grave<br clear="none">> Justification: renders package unusable<br clear="none">> <br clear="none">> File systems correctly mounted after "reached target network online"<br clear="none">> <br clear="none">> File systema rw in both cases.<br clear="none">> <br clear="none">> Case 1<br clear="none">> <br clear="none">> 1. I deleted resolv.conf<br clear="none">> 2. Root fs rw in fstab<br clear="none">> 3. File systems mounted by IP address<br clear="none">> 4. resolve.conf built by end of boot when login possible<br clear="none">> <br clear="none">> proc /proc proc defaults 0 0<br clear="none">> /dev/mmcblk0p1 /boot vfat defaults,ro 0 2<br clear="none">> #PARTUUID=62bc0a1f-02 / ext4 defaults,noatime 0 1<br clear="none">> 192.168.1.10:/nfsroot/r.32.test / nfs defaults,rw 0 0<br clear="none">> 192.168.1.10:/nfsroot/b827eb/c23849/var /var nfs defaults,rw 0 0<br clear="none">> 192.168.1.10:/nfsroot/b827eb/c23849/home /home nfs defaults,rw 0 0<br clear="none">> #browne.danum.local:/nfsroot/b827eb/c23849/home /home nfs defaults,rw 0 0<br clear="none"><br clear="none">Is that a regular DNS name? The .local LTD is reserved for mDNS, so<br clear="none">it's not good practice to use it for regular DNS. But I doubt that has<br clear="none">anything to do with the problem.<br clear="none"><br clear="none">As you say resolv.conf is built during boot, I assume the DNS server is<br clear="none">remote and is discovered through DHCP. Is that correct?<div class="yqt5233299499" id="yqtfd80093"><br clear="none"><br clear="none">[...]<br clear="none">> Conclusion: name resolution, dns lookup, is not performed at fstbab mount time.<br clear="none">> <br clear="none">> This is supposed to work. Who's issue is this? systemd or mount?</div><br clear="none"><br clear="none">It does work, in general.<br clear="none"><br clear="none">The problem is likely to be in the systemd configuration. Quoting<br clear="none">systemd.mount(5):<br clear="none"><br clear="none"> ยท Network mount units automatically acquire After= dependencies on<br clear="none"> remote-fs-pre.target, network.target and network-online.target.<br clear="none"> Towards the latter a Wants= unit is added as well.<br clear="none"><br clear="none">Depending on which network configuration tools you use, you might need<br clear="none">to define additional dependencies for network-online.target or<br clear="none">remote-fs-pre.target.<br clear="none"><br clear="none">Ben.<br clear="none"><br clear="none">-- <br clear="none">Ben Hutchings<br clear="none">Quantity is no substitute for quality, but it's the only one we've got.<div class="yqt5233299499" id="yqtfd22720"><br clear="none"></div></div><br><br></div> </div> </div> </div></div></body></html>