Le 26/04/2020 à 17:39, aitor a écrit :
>
> Hi,
>
> On 9/4/20 18:16, Didier Kryn wrote:
>> Le 09/04/2020 à 16:13, dal a écrit :
>>> Hello and thanks for Beowulf.
>>>
>>> An issue:
>>>
>>> it looks like
>>>
>>>    devuan_beowulf_3.0.0_beta_amd64_netinstall.iso
>>>    and the base system installable from it
>>>
>>> do not contain the ifupdown package (nor other networking utilities
>>> besides busybox ip?).
>>>
>>> The resulting base installation remains offline.
>>> This is a more limited definition of a "base system" than it used to
>>> be, most probably unintentionally.
>>
>>     I remember this was also the case in a previous version, wether
>> Jessie or Ascii. Obviously this isn't an issue when upgrading. I also
>> remind you that the startup delay caused by the timed-out activation
>> of the Ethernet interface (when not plugged in) is still there with
>> the default interfaces file. The solution is to remove the clause
>> "allow-hotplug eth0" and install ifupdown or the equivalent I have
>> forgotten the name of.
>>
>>     Didier
>
>
> The origin of the startup delay is in the lock_interface() function of
> ifupdown in the main.c file:
>
> https://github.com/wido/ifupdown/blob/master/main.c
>
> between the lines nº196-209, surely because ifupdown is trying to lock
> both wired and wireless devices
> at the same time that some dhcp client (isc-dhcp-client, dhcpcd5,
> udhcpc...) is trying to connect (in vain) to some of them,
> being these resources busy.

   AFAIU, dhcp client is invoked by the ifupdown logic only on
interfaces already up. Logically, there might be an interface already up
while ifupdown tries to set up another one, but it seems it starts them
sequentially as shown by what we observe at startup of a laptop:
typically, there is a delay in trying to set up eth, and wifi is only
brought up after this delay, leaving the laptop hanging and without
connection during the delay.

> The C function used during the lock attempts is *fcntl* which uses the
> following macros:
>
>
> Macro: /int/ *F_SETLK*
>
>         whose error conditions are defined by EACCES in GNU/Linux and
> EAGAIN in GNU/Hurd.
>
>
> Macro: /int/ *F_SETLKW  (= F_SETLK + Wait)
> *
>

>     which causes the process to block (or wait) until the request can
>     be specified (line nº199 in main.c).

>
>
> Read here for more details:
>
> https://www.gnu.org/software/libc/manual/html_node/File-Locks.html
>
> I replaced this code by an unique line:
>
>         int flags = fcntl(fileno(lock_fp), F_SETLK, &lock);
>
> and the delay disappears (the same effect than removing
> "allow-hotplug" from /etc/network/interfaces.
>
> As a final remark, the "auto <device>" stanza seems to be deprecated,
> but some people still use it. In the case of
>
> having both defined, that is:
>
> auto eth0
> allow-hotplug eth0
> iface eth0 inet dhcp
>
> the clause "allow-hotplug" has priority over "auto"; so, using both at
> the same time makes no sense.
>
> You can download the patched packages from here:
>
> http://packages.gnuinos.org/?dir=gnuinos/pool/main/i/ifupdown
>
    Thanks Aitor for having investigated this and found a solution,
though I'm not sure the cause of the delay if fully understood.

    The interfaces file describes actions which ifupdown performs  to
set interfaces up and down, plus two special clauses "auto" and
"allow-hotplug", which tell it which interfaces to set up automatically
respectively at start-up or when the interface is plugged in (eg
USB-Ethernet or USB-wifi interface). In the case of the loopback
interface, "auto" is always fine because it isn't a hardware interface;
in the case of other interfaces, "auto" works only if the interface is
hard-wired and "allow-hotplug" works as well if it is hard-wired or
hot-plug; this is why "auto" is deprecated in the installers except for lo.

    In the case of a  server, you generally want all interfaces
(connected to different networks) to be brought up at start-up,
therefore you just need "allow-hotplug" for all interfaces. In the case
of a laptop with both a wifi and an Ethernet interface you generally do
not want both interfaces to be used in the same time because they both
play the role of the primary interface connected to the LAN, with
identical configuration (typically "inet dhcp"). This is why you don't
want ifupdown to start both; instead you need some tool able to detect
if an ethernet cable is plugged in. When an ethernet cable is plugged
in, this tool will tell ifupdown to configure the Ethernet interface and
deconfigure the Wifi. If the cable is plugged out, it will tell it to do
the opposite. I know two such tools: ifplugd and netplug. But there
shouldn't be "auto" or "allow-hotplug" stanzas in the interface file in
this case; their only effect is to cause a delay at start-up.

    In summary "auto" and "hotplug" assume that the interface can be
configured. If you cannot assume it blindly, dont put them and install
ifplugd or netplug. And this is the general case of a laptop. I
understand that it would add more complexity to the installer to decide
what to put in the interfaces file and it probably should not force the
installation of ifplugd or netplug.

    I guess the policy in Debian is to install network-manager and not
ifupdown. I don't know what ifupdown2 does;it is incompatible with
ifplugd. Maybe it is able to detect by itself that an Ethernet cable is
connected.

        Didier