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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
