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 ...
::
Re: [DNG] ascii an waiting for dhcp…
