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

# 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,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join