Hi! Am Mittwoch, 6. Dezember 2017 schrieb Olaf Meeuwissen: > Hi, > > Dr. Nikolaus Klepp writes: > > > Hi Ralph! > > > > Am Dienstag, 5. Dezember 2017 schrieb Ralph Ronnquist: > >> Dr. Nikolaus Klepp wrote on 05/12/17 18:41: > >> > Hi! > >> > > >> > On 2017-11-29 08:37, Dr. Nikolaus Klepp wrote: > >> >> Hi! > >> >> > >> >> Am Mittwoch, 29. November 2017 schrieb Didier Kryn: > >> >>> Le 29/11/2017 à 08:38, Dr. Nikolaus Klepp a écrit : > >> >>>> Hi! > >> >>>> > >> >>>> When bootin ascii and eth0 is present and configured as dhcp and eth0 > >> >>>> is not connected to a network, then the boot process is blocked at ~ > >> >>>> 1 minute at the stage where eth0 is configured. This is quite anoying > >> >>>> and did not happen on jessie. Is there an easy way to get the old > >> >>>> behaviour (i.e. background dhcp request) back on ascii? > >> >>>> > >> >>> > >> >>> Sorry to reply by this triviality: did you check > >> >>> /etc/network/interfaces ? > >> >>> > >> >>> If you have 'auto eth0' , then it might explain the wait. > >> >>> Normally, if the cable is meant to be unplugged/replugged, you > >> >>> should have > >> >>> 'allow-hotplug eth0' instead. > >> >>> > >> >>> Didier > >> >> > >> >> Well, this is exactly the problem: I have these lines in > >> >> /etc/network/interfaces: > >> >> > >> >> allow-hotplug eth0 > >> >> iface eth0 inet dhcp > >> >> > >> > > >> > Maybe I did not make myself clear: > >> > > >> > No matter which line I put in /etc/network/interfaces, be it > >> > "allow-hotplug eth0" or "auto eth0", booting is delayed when no network > >> > is present and dhcp should be used. > >> > > >> > Could somebody else please check if this is behavior is reproducible? > >> > >> Both of those result in "ifup eth0" being run as part of the boot > >> sequence, and a wait for that to succeed or give up. Neither scheme pays > >> attention to the link state; it merely checks whether the interface is > >> up or not, and if not, it brings it up bmo ifup. > >> > >> I believe that during some period in the past, the control scripts > >> involved (nowadays /etc/init.d/networking or /lib/udev/net.agent) did > >> pay attention to link state, and avoided the ifup command when the link > >> wasn't there, which then avoided it waiting for dhcp to give up. But I > >> might remember it wrong; in any case, progress has made it that today we > >> wait, or bypass it by using some other networking solution. > >> > >> Ralph. > > > > Ok, then this is really stupid and a regression. Jessie did check if the > > cable is plugged in and did only run dhcpcd when the cable was present. > > Acsii does not check and so blocks on every system startup for ~ 1 minute. > > When ascii becomes stable this will most likely make a bunch of people quit > > unhappy :-/ > > I've been afflicted by the same :-( > > > Just seen in the manpage: > > > > (Interfaces marked "allow-hotplug" are brought up when udev detects them. > > This can > > either be during boot if the interface is already present, or at a > > later time, > > for example when plugging in a USB network card. Please note that this > > does not > > have anything to do with detecting a network cable being plugged in.) > > > > Hm ... what to do about it? Any idea? > > Downgrade to 0.8.13? From the changelog for 0.8.14: > > * Ignore link state when bringing up hotplug interfaces at boot. > Closes: #814785, #834820
Now how sick is this? Break lan 'caus systemd cannot handle wlan propperly? Did nobody actually test what this "fix" does? ascii has "ifupdown" version 0.8.19, no way back :-( > > # Had a quick look and it *seems* udev is involved somehow ... > > Revert the change that "fixes" those two Debian bugs? > > Another option could be to muck around in /etc/init.d/networking to > check whether *wired* "allow-hotplug" interfaces have a cable attached > before trying to bring them up. > > No bright ideas for how you'd check for that though, but it probably > involves poking around in /sys/class/net/$IFACE/. > > Hope this helps, -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
