Re: [DNG] vdev in chimaera

[aitor]

Hi Karl,

On 26/5/22 13:26, k...@aspodata.se wrote:

And, if DEVTMPFS isn't used then udev will not start, don't know
about eudev.
  vdev and mdev will probably run fine without devtmpfs.


Vdev does work without DEVTMPFS. Indeed, i have the following lines in my 
initramfs:

if command -v udevd; then
    mount -t devtmpfs -o nosuid,mode=0755 udev /dev
else
    mount -t tmpfs -o nosuid,mode=0755 none /dev
fi

leading to something like this in my /etc/mtab:

    none /dev tmpfs rw,relatime,size51200k,mode755 0 0

in contrast to

    udev /dev devtmpfs rw,nosuid,relatime,size=.

I did build a kernel without devtmpfs support:

https://www.gnuinos.org/nodevtmpfs/  

but don't expect to get eudev working with it.

On the other hand, and just the same as vdev, you don't need devtmpfs to run 
mdev:

https://sunxiboards.wordpress.com/2013/09/23/using-devtmpfs/  


Calling `|mdev -s`|  will check /sys and will create the correct devices. 
Therefore,
if you don't use devtmpfs, you need to call `mdev -s` in your /bin/init script 
to
populate /dev.

And then, when the kernel detects a new device, it calls the already mentioned

/proc/sys/kernel/hotplug

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[karl]

Didier:
> Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :
> > The kernel devtmpfs makes dev files come and go, yes, but they
> > will have some default user, group and permission setting, so
> > *dev daemons handle that part.
> 
>      Yes, I forgot this point.
> 
>      However handling permission and ownership is a simple task. 
> Couldn't it be done by a script fed by inotifywait ?
> 
>      'inotifywait -mqe create --format %f /dev | PermissionManager.sh'
> 
>      An oversimple hotplugger (~:

Well, why don't you try it and tell us.

The simplest cause of action is to have the /dev files previously set 
up. A static /dev is sufficient enless you use md's with superblock 
version > 0.90, hdmi audio (I guess) and lvm, and I guess if you havn't
root access on your system and uses not permanently connected usb devices.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 27/05/2022 à 15:40, Dr. Nikolaus Klepp via Dng a écrit :

Anno domini 2022 Fri, 27 May 15:11:24 +0200
  Didier Kryn scripsit:

Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :

The kernel devtmpfs makes dev files come and go, yes, but they
will have some default user, group and permission setting, so
*dev daemons handle that part.

      Yes, I forgot this point.

      However handling permission and ownership is a simple task.
Couldn't it be done by a script fed by inotifywait ?

      'inotifywait -mqe create --format %f /dev | PermissionManager.sh'

      An oversimple hotplugger (~:

Once upon a time there was /proc/sys/kernel/hotplug which did this.

Nik


    Yes. The legacy Busybox's mdev is working like this: 
/proc/sys/kernel/hotplug points to it.


    I think you can invoke your script like this. The script just needs 
to read some global variables to know if the uevent causes the creation 
of a device file and make sure the kernel has created this file before 
changing permissions.


    There was a disussion years ago in Busybox, about the respective 
merits of /proc/sys/kernel/hotplug versus netlink. In the first case, 
you have a "fork bomb" at boot time (launching the hotplugger at each 
device creation) and possibly unordered activity, and in the second 
case, you have the hotplugger always resident in RAM even when it's not 
needed, but sequential activity.


    DEVTMPFS was invented later, AFAIK because kernel people were 
unhappy with what udev was doing. It happens to offer a third triggering 
method to manage devices which have a device file: inotify.


    Using inotify is simple and sequential, but the process is 
permanently in RAM (like all hotpluggers but mdev). I think it is the 
simplest method if you deal only with character and block devices. Of 
course, the program isn't necessarily a script. I gave the example to 
show how easy it is.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Dr. Nikolaus Klepp via Dng]

Anno domini 2022 Fri, 27 May 15:11:24 +0200
 Didier Kryn scripsit:
> Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :
> > The kernel devtmpfs makes dev files come and go, yes, but they
> > will have some default user, group and permission setting, so
> > *dev daemons handle that part.
> 
>      Yes, I forgot this point.
> 
>      However handling permission and ownership is a simple task. 
> Couldn't it be done by a script fed by inotifywait ?
> 
>      'inotifywait -mqe create --format %f /dev | PermissionManager.sh'
> 
>      An oversimple hotplugger (~:

Once upon a time there was /proc/sys/kernel/hotplug which did this.

Nik

> 
> --     Didier
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :

The kernel devtmpfs makes dev files come and go, yes, but they
will have some default user, group and permission setting, so
*dev daemons handle that part.


    Yes, I forgot this point.

    However handling permission and ownership is a simple task. 
Couldn't it be done by a script fed by inotifywait ?


    'inotifywait -mqe create --format %f /dev | PermissionManager.sh'

    An oversimple hotplugger (~:

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[karl]

Didier:
...
>      Seems there is a myth about user-space hotplugger 
> (udev/eudev/vdev/mdev) being necessary to have a dynamic /dev. Dynamic 
> /dev has been managed by the kernel from many years. The hotpluggers do 
> other things, like managing the symlinks in /dev/disk/by-* and they are 
> usefull for that. But, even if you remove the hotplugger, if the kernel 
> has the DEVTMPFS feature enabled (which is likely), it will create and 
> delete the device files.

The kernel devtmpfs makes dev files come and go, yes, but they
will have some default user, group and permission setting, so
*dev daemons handle that part.

And, if DEVTMPFS isn't used then udev will not start, don't know
about eudev.
 vdev and mdev will probably run fine without devtmpfs.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[karl]

Aitor:
> On 25/5/22 23:04, k...@aspodata.se wrote:
> > It would be nice if one could choose static /dev (as it was before udev).
> > It is no problem running with a static /dev if you compile your own
> > kernel.
> 
> vdevd already has a "run once" option, passing the argument --once (either 
> -1),
...
> where the daemon -if not- would remain waiting for next events, once the 
> scanning
> of the contents of `/sys` has been carried out.
> So generated `/dev` is static and, as Jude Nelson explains in his 
> `how-to-test.md`
> file, "running the daemon again will update the
> previously-generated static `/dev` with only the device files that correspond
> to hardware plugged into your computer."

Very nice, but README.md says it removes dev files,
and I know how to get device files from /sys.
 But it should be useful for thoose packages that says they
depend on udev and doesn't really.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 25/05/2022 à 23:04, k...@aspodata.se a écrit :

Aitor:

On 20/1/22 0:23, aitor wrote:

...

I uploaded some images of gnuinos chimaera including vdev as default
device manager.

...

It's possible to choose between sysvinit, openrc or runit at the end of the
installation, but unlike devuan, the later is set as default.

Bear in mind that you can always toggle device managers via apt, whether:

# apt-get install libeudev1 eudev

or

# apt-get install libudev1-compat vdev

It would be nice if one could choose static /dev (as it was before udev).
It is no problem running with a static /dev if you compile your own
kernel.

    Seems there is a myth about user-space hotplugger 
(udev/eudev/vdev/mdev) being necessary to have a dynamic /dev. Dynamic 
/dev has been managed by the kernel from many years. The hotpluggers do 
other things, like managing the symlinks in /dev/disk/by-* and they are 
usefull for that. But, even if you remove the hotplugger, if the kernel 
has the DEVTMPFS feature enabled (which is likely), it will create and 
delete the device files.


--     Didier

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi Karl,

On 25/5/22 23:04, k...@aspodata.se wrote:

It would be nice if one could choose static /dev (as it was before udev).
It is no problem running with a static /dev if you compile your own
kernel.


vdevd already has a "run once" option, passing the argument --once (either -1), 
maybe with testing purposes in mind.
In doing so, vdev by-passes the poll() system call in the line 525 of:

https://github.com/jcnelson/vdev/blob/master/vdevd/os/linux.c  


where the daemon -if not- would remain waiting for next events, once the 
scanning of the contents of `/sys` has been carried out.
So generated `/dev` is static and, as Jude Nelson explains in his `how-to-test.md` 
file, "running the daemon again will update the
previously-generated static `/dev` with only the device files that correspond to 
hardware plugged into your computer."

Hope this helps,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[karl]

Aitor: 
> On 20/1/22 0:23, aitor wrote:
...
> > I uploaded some images of gnuinos chimaera including vdev as default 
> > device manager.
...
> It's possible to choose between sysvinit, openrc or runit at the end of the
> installation, but unlike devuan, the later is set as default.
> 
> Bear in mind that you can always toggle device managers via apt, whether:
> 
> # apt-get install libeudev1 eudev
> 
> or
> 
> # apt-get install libudev1-compat vdev

It would be nice if one could choose static /dev (as it was before udev).
It is no problem running with a static /dev if you compile your own
kernel.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi,

On 20/1/22 0:23, aitor wrote:


Hi all,

I uploaded some images of gnuinos chimaera including vdev as default 
device manager.


https://www.gnuinos.org/mirror/chimaera/live/ 




Most recent installer-isos also contain vdev as default device manager, which is
installed from the very beginning in the base system:

https://www.gnuinos.org/mirror/chimaera/installer-iso/  


It's possible to choose between sysvinit, openrc or runit at the end of the
installation, but unlike devuan, the later is set as default.

Bear in mind that you can always toggle device managers via apt, whether:

# apt-get install libeudev1 eudev

or

# apt-get install libudev1-compat vdev


I included fsmithred's usbpmount.sh and usb-unmount.sh yad scripts to
handle usb sticks, pending the arrival of an improved release of 
hopman in chimaera.


Removable media is now managed by hopman in all the isos of gnuinos.

Cheers,

Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi Didier,

On 11/2/22 12:11, Didier Kryn wrote:


My normal interfaces file contains an "auto" stanza for wlan0,
which is superfluous, according to messages from ifplugd, and*only*  
"iface eth0 inet dhcp" for eth0 because it comes first in the file and

"auto" and/or "allow-hotplug" can just cause the abovementionned delay
when no Ethernet cable is connected.


Please, give a try to the following image:

https://www.gnuinos.org/mirror/chimaera/live/  


There are several services being handled by runit in these images, and 
ifupdown's networking is one of them.
Better said, it's not a service -as you pointed out- but a script that starts 
another service, that is dhcp.
You can test the image in live mode, and you'll find that the delay caused by 
the configuration in
/etc/network/interfaces disappears. Also, even if you boot without wired 
connection, the connection will be
stablished without the need of restarting the service when you plug/unplug the 
ethernet cable again and again.

Note, on the other hand, that the time interval in the periodic reminder of the 
automatically_connect option of
simple-netaid (setup in /etc/simple-netaid/snetaid.conf) is equal to zero so as 
not to interfere with the
stanzas defined in /etc/network/interfaces. Hence, the wired connection is 
stablished thanks to these definitions.
And yes..., *both* stanzas are required for that. With this in mind, I decided 
to leave the automatically connect
option of simple-netaid only for wired devices.

More info later :)

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 10/02/2022 à 02:34, aitor a écrit :


Hi Didier,

On 9/2/22 16:36, Didier Kryn wrote:
And, if you haven't a server like ifupdown or netplug, you're going 
to need to restart networking everytime you plug/unplug your Ethernet 
cable.


Well, you mean *ifplugd* or netplug..., I understand.


    Yep (~:


Try with "auto" and "allow-hotplug" together, both at once. That is:

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

With this configuration, plug/unplug events will be automatically 
detected.


    Maybe plug/unplug of devices are detected, but I doubt plug/unplug 
of Ethernet cable are, though I didn't try because I should have 
uninstalled ifplugd for the test to be conclusive.


    But I made a minimum testing: I just inserted the doube stanza you 
suggest, for the eth0 interface of my laptop, and the net effect on 
reboot is a long delay with the message that ifup is waiting for a lock 
file the name of which contains "eth0". I would have bet some bucks on 
this result (~:


    My normal interfaces file contains an "auto" stanza for wlan0, 
which is superfluous, according to messages from ifplugd, and *only* 
"iface eth0 inet dhcp" for eth0 because it comes first in the file and 
"auto" and/or "allow-hotplug" can just cause the abovementionned delay 
when no Ethernet cable is connected. Again, "auto" and/or 
"allow-hotplug" are useless when you have ifplugd managing eth0 and 
wlan0; they can only cause a startup delay. Even on my desktop, which 
only has an Ethernet connection, eth0 is managed by ifplugd and there is 
no "auto" or "allow-hotplug" stanza. This allows smooth functionning 
when the machine is moved around and the Ethernet cable 
plugged/unplugged and/or the DSL modem/router is restarted.



I'll answerin detail to the rest of your post shortly, when I have time.

    I'd like a lot to learn more on this. I reached a consistent 
understanding based on experiments, but it's certainly not definitive 
and I know you're looking at things more in depth.


    Cheers.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi Didier,

On 9/2/22 16:36, Didier Kryn wrote:
And, if you haven't a server like ifupdown or netplug, you're going to 
need to restart networking everytime you plug/unplug your Ethernet cable.


Well, you mean *ifplugd* or netplug..., I understand.

Try with "auto" and "allow-hotplug" together, both at once. That is:

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

With this configuration, plug/unplug events will be automatically detected.

I'll answerin detail to the rest of your post shortly, when I have time.

Cheers,

Aitor.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 08/02/2022 à 01:45, aitor a écrit :

Hi Didier,
On 7/2/22 19:21, Didier Kryn wrote:

If you
remove the "allow-hotplug" and "auto" stanzas, ifup -a will just do
nothing, hence no wait. Therefore the solution is to install ifplugd or
netplug, configure it, and eliminate the "allow-hotplug" stanzas from
/etc/network/interfaces.

I've found a workaround replacing in the init script:
if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
then
  log_action_end_msg $?
else
  log_action_end_msg $?
fi
with this:
if [ $(runlevel) != "unknown" ] || ! [ -z $(grep '^id:1:initdefault:$' 
/etc/inittab) ]; then
   if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
   then
     log_action_end_msg $?
   else
     log_action_end_msg $?
   fi
fi
which means: "skip these lines if the boot process still has not switched to 
the default runlevel,
unless it is single user". The following script located in /etc/boot.d:
#!/bin/sh -e
#
# networking-restart
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.

if test -x /etc/init.d/networking ; then
     service networking restart
fi
will restart the service and from this moment, both "auto " and "allow-hotplug 
" will take effect.
This way, the delay will occur only in the case of a single user default 
runlevel, which is often not the case.

     IIUC this means that network startup is deferred. Does it mean 
starting ntp, ssh and/or web services before the network is available? 
Doesn't this method defeat the whole purpose of the dependencies 
inserted as comments in the headers of the RC scripts? I ask this 
because I'm not sure of my understanding of the whole mechanism. 
Wouldn't it be cleaner to change the priorities?


     Clearly there is a wrong assignment of priorities in the startup: 
there is no reason that the login prompt and all the applications which 
do not depend on the network have to wait until the network startup 
times out. AFAIU your method is a workaround for this misconfiguration. 
But the timeout is still there before you can use the network, while in 
most cases, it should not. And, if you haven't a server like ifupdown or 
netplug, you're going to need to restart networking everytime you 
plug/unplug your Ethernet cable.


 The ifupdown API, driven by the configuration of 
/etc/network/interfaces is well suited for static network configuration; 
it offers a lot of possibilities to the admin, eg bonding. The addition 
of the stanza "inet dhcp" has made it usable with dynamic network 
configuration, and the addition of the stanza "allow-hotplug" in 
replacement of "auto" has made it usable with hotplug network interfaces 
such as USB-Ethernet or USB-WIFI adapters.


 But this does not respond to the cases where one or more 
interfaces are not *always* connected, in particular the case of laptops 
which have one single connection to the network, *alternatively* through 
Wifi and through Ethernet. In this case, the connection is done through 
Ethernet when the Ethernet cable is connected and through Wifi otherwise 
and it is a nonsense to try to bring eth0 up when the Ethernet cable is 
not plugged in. Instead, eth0 must be brought respectively up and down 
when the cable is connected and disconnected, and, simultaneously wlan0 
must be brought down and up.


 I don't know any stanza of the interfaces file which might achieve 
that because there is no feature such as the detection of the Ethernet 
carrier in ifupdown - ifupdown is not a server. This functionality can 
be provided by ifplugd, and AFAIK by netplug. These two servers detect 
changes in the presence of the Ethernet carrier and make use of the 
ifupdown API to bring the interfaces up and down. In this situation, 
stanzas like "auto" and "allow-hotplug" are nothing but nuisances.


 It would be very nice if the installer could provide a dialog to 
configure this, but it does not look like an easy job. Maybe the user 
could be directed to some documentation.



--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi Didier,

On 7/2/22 19:21, Didier Kryn wrote:


If you
remove the "allow-hotplug" and "auto" stanzas, ifup -a will just do
nothing, hence no wait. Therefore the solution is to install ifplugd or
netplug, configure it, and eliminate the "allow-hotplug" stanzas from
/etc/network/interfaces.


I've found a workaround replacing in the init script:

if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
then
 log_action_end_msg $?
else
 log_action_end_msg $?
fi

with this:

if [ $(runlevel) != "unknown" ] || ! [ -z $(grep '^id:1:initdefault:$' 
/etc/inittab) ]; then
  if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
  then
    log_action_end_msg $?
  else
    log_action_end_msg $?
  fi
fi

which means: "skip these lines if the boot process still has not switched to 
the default runlevel,
unless it is single user". The following script located in /etc/boot.d:

#!/bin/sh -e
#
# networking-restart
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.

if test -x /etc/init.d/networking ; then
    service networking restart
fi

will restart the service and from this moment, both "auto " and "allow-hotplug 
" will take effect.
This way, the delay will occur only in the case of a single user default 
runlevel, which is often not the case.

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 07/02/2022 à 16:22, fsmithred via Dng a écrit :

On 2/7/22 06:35, Didier Kryn wrote:

Le 07/02/2022 à 08:29, aitor a écrit :

I've uploaded new iso images fixing a bug related to the last change in
simple-netaid for
compatibility with static ip addresses, that involved the response to
routing table netlink
events triggered by other processes. The images come with vdev by
default. Next step will be
to write a runit script for ifupdown that intend to solve the problem of
the still remaining
(at least booting with vdev) long delayed boot time when using
"allow-hotplug "
stanzas in /etc/network/interfaces.

     The long delay is also present with sysvrc. It can be supressed by
just removing the "allow-hotplug" line, without replacing it by an "auto"
line, and relying on ifplugd or netplug to detect the presence of the
carrier and trigger the configuration of the interface. The delay is
suppressed because 'ifup -a' does not find any interface to bring up and
carrier to wait for; and then ifplugd/netplug brings them up only when the
carrier is detected. Dunno if simple-netaid can play the role of ifplugd
or netplug.

--     Didier


I keep updating your check-link-state.patch on /etc/network/interfaces. It
seems to still be working with allow-hotplug.

The original discussion on DNG is gone, but I saved part of it here:
https://dev1galaxy.org/viewtopic.php?pid=15493#p15493

I think the line numbers are right for chimaera, but I always edit this
manually.

--- networking.orig 2021-11-08 08:47:47.520020285 -0500
+++ patches/networking.patched  2019-12-14 11:13:07.842536000 -0500
@@ -112,7 +112,13 @@
done)
if [ -n "$ifaces" ]
then
-   ifup $ifaces "$@" || true
+   # link detection does not work unless we up the link
+   ip link set "$iface" up || true
+   if [ "$(cat /sys/class/net/$link/operstate)" = up ]
+   then
+   echo "$iface"
+   fi
+
fi
  fi
  }

    Sorry but I doubt that the patch is from me, specially because I'm 
not familiar (yet) with the ip command, which replaced ifconfig.


    The problem I met, like most people with a laptop is that I have 
both eth0 and wlan0. Invoquing ifup -a at boot causes a delay when no 
Ethernet cable is plugged in, which is the usual situation. This is 
because ifupdown then waits for the carrier and only gives up after a 
delay, and only then, brings up wlan0 (given eth0 is listed first in the 
interfaces file).


    "allow-hotplug" is meant for network *devices* (not cables) you 
plug in on the fly, like USB-Ethernet adapters. The word hotplug does 
not mean that the cable is plugged in/out on the fly. In most cases, 
"allow-hotplug" is equivalent to "auto". But, when bringing up an 
interface, ifupdown waits until the carrier is detected or the timeout 
is expired. When there is no cable, there is no carrier, and the timeout 
is pretty long.


    On the other hand, ifplugd or netplug are awakened when the carrier 
is detected on one of the interfaces they control, and then, they invoke 
ifup for the interface in question, just when it makes sense. If you 
remove the "allow-hotplug" and "auto" stanzas, ifup -a will just do 
nothing, hence no wait. Therefore the solution is to install ifplugd or 
netplug, configure it, and eliminate the "allow-hotplug" stanzas from 
/etc/network/interfaces.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[fsmithred via Dng]

On 2/7/22 06:35, Didier Kryn wrote:
> Le 07/02/2022 à 08:29, aitor a écrit :
>> I've uploaded new iso images fixing a bug related to the last change in
>> simple-netaid for
>> compatibility with static ip addresses, that involved the response to
>> routing table netlink
>> events triggered by other processes. The images come with vdev by
>> default. Next step will be
>> to write a runit script for ifupdown that intend to solve the problem of
>> the still remaining
>> (at least booting with vdev) long delayed boot time when using
>> "allow-hotplug "
>> stanzas in /etc/network/interfaces.
> 
>     The long delay is also present with sysvrc. It can be supressed by
> just removing the "allow-hotplug" line, without replacing it by an "auto"
> line, and relying on ifplugd or netplug to detect the presence of the
> carrier and trigger the configuration of the interface. The delay is
> suppressed because 'ifup -a' does not find any interface to bring up and
> carrier to wait for; and then ifplugd/netplug brings them up only when the
> carrier is detected. Dunno if simple-netaid can play the role of ifplugd
> or netplug.
> 
> --     Didier
> 

I keep updating your check-link-state.patch on /etc/network/interfaces. It
seems to still be working with allow-hotplug.

The original discussion on DNG is gone, but I saved part of it here:
https://dev1galaxy.org/viewtopic.php?pid=15493#p15493

I think the line numbers are right for chimaera, but I always edit this
manually.

--- networking.orig 2021-11-08 08:47:47.520020285 -0500
+++ patches/networking.patched  2019-12-14 11:13:07.842536000 -0500
@@ -112,7 +112,13 @@
done)
if [ -n "$ifaces" ]
then
-   ifup $ifaces "$@" || true
+   # link detection does not work unless we up the link
+   ip link set "$iface" up || true
+   if [ "$(cat /sys/class/net/$link/operstate)" = up ]
+   then
+   echo "$iface"
+   fi
+
fi
 fi
 }


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 07/02/2022 à 08:29, aitor a écrit :

I've uploaded new iso images fixing a bug related to the last change in 
simple-netaid for
compatibility with static ip addresses, that involved the response to routing 
table netlink
events triggered by other processes. The images come with vdev by default. Next 
step will be
to write a runit script for ifupdown that intend to solve the problem of the 
still remaining
(at least booting with vdev) long delayed boot time when using "allow-hotplug 
"
stanzas in /etc/network/interfaces.


    The long delay is also present with sysvrc. It can be supressed by 
just removing the "allow-hotplug" line, without replacing it by an 
"auto" line, and relying on ifplugd or netplug to detect the presence of 
the carrier and trigger the configuration of the interface. The delay is 
suppressed because 'ifup -a' does not find any interface to bring up and 
carrier to wait for; and then ifplugd/netplug brings them up only when 
the carrier is detected. Dunno if simple-netaid can play the role of 
ifplugd or netplug.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[hal]

On 2/7/22 01:35, aitor wrote:

Hi,

On 7/2/22 8:29, aitor wrote:

Next step will be
to write a runit script for ifupdown that intend to solve the problem of the 
still remaining
(at least booting with vdev) long delayed boot time when using "allow-hotplug 
"
stanzas in /etc/network/interfaces.


I have Laurent Bercot's s6 in mind, and shortly i'll give a try to Obarun.

Cheers,

Aitor.


Thank you!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi,

On 7/2/22 8:29, aitor wrote:

Next step will be
to write a runit script for ifupdown that intend to solve the problem of the 
still remaining
(at least booting with vdev) long delayed boot time when using "allow-hotplug 
"
stanzas in /etc/network/interfaces.


I have Laurent Bercot's s6 in mind, and shortly i'll give a try to Obarun.

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi,

On 20/1/22 0:23, aitor wrote:


Hi all,

I uploaded some images of gnuinos chimaera including vdev as default 
device manager.


https://www.gnuinos.org/mirror/chimaera/live/ 



I would like you to test them after a hard disk installation because 
this is the

first time one can replace eudev with vdev via APT by simply typing:

# apt-get install vdev libudev1-compat

beyond which it's possible to restore eudev in a similar way:

# apt-get install eudev libeudev1

Though eudev and vdev depend on libeudev1 and libudev1-compat 
respectively, it's
recommended to mention them explicitly in order to prevent other 
packages like Xorg

from being uninstalled during the change.

It's worth mentioning that you won't find any external devices in the 
panel of thunar
because some benefits of gvfs/udisks2 don't work with vdev.Hopefully 
the trash is still there.
With this in mind, I included fsmithred's usbpmount.sh and 
usb-unmount.sh yad scripts to
handle usb sticks, pending the arrival of an improved release of 
hopman in chimaera.


I also uploaded the sources of the live-sdk that generate the 
available iso images.



I've uploaded new iso images fixing a bug related to the last change in 
simple-netaid for
compatibility with static ip addresses, that involved the response to routing 
table netlink
events triggered by other processes. The images come with vdev by default. Next 
step will be
to write a runit script for ifupdown that intend to solve the problem of the 
still remaining
(at least booting with vdev) long delayed boot time when using "allow-hotplug 
"
stanzas in /etc/network/interfaces.

The sources of the live-sdk have been updated as well.

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] vdev in chimaera

[aitor]

Hi all,

I uploaded some images of gnuinos chimaera including vdev as default 
device manager.


https://www.gnuinos.org/mirror/chimaera/live/ 



I would like you to test them after a hard disk installation because 
this is the

first time one can replace eudev with vdev via APT by simply typing:

# apt-get install vdev libudev1-compat

beyond which it's possible to restore eudev in a similar way:

# apt-get install eudev libeudev1

Though eudev and vdev depend on libeudev1 and libudev1-compat 
respectively, it's
recommended to mention them explicitly in order to prevent other 
packages like Xorg

from being uninstalled during the change.

It's worth mentioning that you won't find any external devices in the 
panel of thunar
because some benefits of gvfs/udisks2 don't work with vdev.Hopefully the 
trash is still there.
With this in mind, I included fsmithred's usbpmount.sh and 
usb-unmount.sh yad scripts to
handle usb sticks, pending the arrival of an improved release of hopman 
in chimaera.


I also uploaded the sources of the live-sdk that generate the available 
iso images.


Cheers,

Aitor




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng