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.