[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#860264: Acknowledgement (nfs-kernel-server: NFS starts before DNS works, "exportfs: Failed to resolve ...")



Hi!

I'm currently experiencing the exact same issue with an NFS mount for
/home, and another nfs mount (from another server) that gets mounted
under /srv/something: at boot, nfs mount times out, and afterwards when
the boot is complete, if I ssh in and execute "mount -a" as root the
mount points become available.

On Mon, 17 Apr 2017 09:19:59 -0400 Greg Wooledge <wooledg@eeg.ccf.org>
wrote:
> wooledg:~$ systemctl list-dependencies network-online.target
> network-online.target
> * `-networking.service
> 
> wooledg:~$ cat /lib/systemd/system/networking.service
> [...]
> [Service]
> Type=oneshot
> EnvironmentFile=-/etc/default/networking
> ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle'
> ExecStart=/sbin/ifup -a --read-environment

This seems to be problematic.. unfortunately if I understand correctly
"allow-hotplug" is meant to make it possible to have the network
interface be configured dynamically whenever it appears. So it might be
useful for network interface dongles ... but if I try to reason why
debian's installer configures interfaces as "allow-hotplug" by default,
I would guess that it might also be useful for laptops that have wifi
on/off physical switches to disable/enable the interface.

I'm wondering why physical interfaces (previously known as ethN) would
require this instead of using "auto", though..

Also just to add at least one data point that's more closely relevant to
the paragraph above: the unit file for network-online.target is still
the same in sid now, so the issue still exists!

I'm not sure what would be the correct solution for this to avoid
requiring ppl to manually change the definition of their interface when
they want to use a mount point at boot that requires networking :\

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: