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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[aitor]

I've got the live images working under qemu

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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[aitor]

Hi Joel,

On 11/1/21 1:06, Joel Roth via Dng wrote:

Thanks for digging into this, Aitor!

On Sun, Jan 10, 2021, aitor wrote:

Images of gnuinos openbox with vdev for testing purposes are available at:

https://www.gnuinos.org/Beowulf/  

I tried out the ISO under qemu. Could boot to rescue mode,
but hung up booting to live image at
vmw_driver_load.cold.23 [vmwgfx] ERROR: hardware has no pitchlock

I've got the live images working under qemu (with openbox and mate).
There is still room for improvement, though.

Thanks for your tests!

Aitor.


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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Joel Roth via Dng]

Thanks for digging into this, Aitor!

On Sun, Jan 10, 2021, aitor wrote:
> Images of gnuinos openbox with vdev for testing purposes are available at:
> 
> https://www.gnuinos.org/Beowulf/ 

I tried out the ISO under qemu. Could boot to rescue mode,
but hung up booting to live image at
vmw_driver_load.cold.23 [vmwgfx] ERROR: hardware has no pitchlock

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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[aitor]

Hi again,

On 10/1/21 20:45, aitor wrote:

On the other hand, i defined a separate config
file with a minimal amount of actions for vdev during the load of the 
temporary root

filesystem (initrd) and the subsequent first stage of runit.


The rest of the actions run in the foreground [*] together with the 
daemon handled by runit:


exec /sbin/vdevd -f -c /etc/vdev/vdevd.conf /dev

ending up at the line nº525 of linux.c:

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



and remaining in waiting for possible events on a file descriptor (like 
USB connections).


Cheers,

Aitor.

[*] The binary that is being called in the run script handled by runit 
(vdevd in our case)
should run in the foreground, and it should be run without spawning a 
new process or a shell.

This point explains the use of the builtin *exec* command.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[aitor]

Hi Joel,

On 30/12/20 20:51, Joel Roth via Dng wrote:

While I don't understand your post completely, I agree with
your point that udev-compat need not be a high priority as
libeudev meets this need. I understand that without
udev-compat, vdev wouldn't be able to serve some heavyweight
desktop environments.

During these days i upgraded the hardware database and also libudev1-compat
leaving it as close as possible to libeudev1. I also added the cdrom_id 
binary required
during live sessions after jessie. On the other hand, i defined a 
separate config
file with a minimal amount of actions for vdev during the load of the 
temporary root
filesystem (initrd) and the subsequent first stage of runit. Thus, the 
boot time has been
improved a lot (~30 sec between the grub splash and the login screen is 
not so bad, but

it's still a bit high in comparison with eudev).

I think that's okay, because Probably most potential users
of vdev will be using a lightweight window manager or even
just console.  I think serving that group will be a good
place to start.


Images of gnuinos openbox with vdev for testing purposes are available at:

https://www.gnuinos.org/Beowulf/ 


Also, while a database for fast startup would be great,
enabling it to work at all would be a good first step.

Eventually some sort of write-up about vdev comparing it to
mdev, udev, eudev might help getting the word out. (I'd
help with that.)

Thanks for all your work!
One thing i would like to do is to extend the vdev_preseed_run function 
to unlimited

output buffer space (actually limited to 1MB).

Cheers,

Aitor.


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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Didier Kryn]

Le 31/12/2020 à 17:53, Steve Litt a écrit :
> Next, I'd base the video solution on SVG.

    It was a big error to not use vector graphics in the X-terminals
from the beginning. I recall that PotScript existed before X, and
PostScript is practically equivalent to SVG - only missing transparency.
I remember that, at that time, I was shocked.

--     Didier


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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Steve Litt]

On Thu, 31 Dec 2020 08:18:02 -0600
o1bigtenor  wrote:

> I don't really play any games - - - I
> have too much fun just using software on my system - - - - but then
> I'm a business  man and self-employed and that means, by definition,
> that I'm weird. 

Me too, o1bigtenor. My computer enables me to produce and sell books,
teach systematic Troubleshooting mindset and techniques, and write
software to make my business's workflow better. People like us are
often ignored when software decisions are made. Back in the Windows
days, we were called "Power Users" and respected. Trade mags had
many articles addressed to people like us. Today it seems we're just a
minority to be ignored in the rush to somehow "market" the Linux
Desktop --- an endeavor that's been failing miserably for two decades
now.

This is one of the many reasons I'm glad Devuan exists. Devuan's
rejection of systemd removes the attempt to embed my Linux computer in
epoxy and force me to use only systemd's dials and switches, which of
course are one to several needless levels of abstraction that really do
nothing to simplify, but only get in the way.

Like you, my income depends on my Linux computer. That puts us in a
whole different category from gamers, and from dwobes who use their
computers for social media without understanding anything about a
computer.


> I am working with software in a very wide range of
> things, from CADD to CAM (that very little at present), to
> spreadsheets, to starting to work in self designed software
> supporting equipment that I'm fabricating and a bunch of other
> things. To date I've been mostly a software user but am starting on
> becoming a software developer because in certain areas software just
> isn't adequate. In the software using I've found myself pushing the
> envelope because I combine things in ways that seem to all too often
> be non-customary.

Exactly! Luckily, we still have POSIX, which is a simple way to achieve
amazing things with lightning speed. Just a little knowledge of Python
or Perl, AWK, sed, C and shellscripting can usually produce the exact
behavior you're seeking, which is exactly what Thompson and Richie were
trying to accomplish.
 
SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Steve Litt]

On Thu, 31 Dec 2020 08:18:02 -0600
o1bigtenor  wrote:

> On Wed, Dec 30, 2020 at 4:34 PM Steve Litt
>  wrote:
> >
> > On Wed, 30 Dec 2020 09:51:33 -1000
> > Joel Roth via Dng  wrote:  
> snip
> > One question: How does your above statement hold up when Wayland
> > becomes the law of the land?
> >  
> 
> Greetings
> 
> From what little I"ve been able to discern about Wayland I really
> hope that it doesn't become the law of the land.

Me too. My impression is that Wayland is from the same crew who brought
us systemd, will probably require systemd unless modified, and breaks
all the UI software I currently use (Openbox and dmenu).

The problem is that X really sucks, and unlike systemd, there are no
alternatives like runit, s6, Epoch, Busybox init, or OpenRC to prevent
it from being a binary choice. I'll keep X as long as possible, because
"sucks" is better than "breaks all your software" or "requires
systemd". But much like that nasty UEFI, sooner or later I think we'll
be stuck with it.


It didn't have to be this way. In 2020, better alternatives could have
been made. If I were the project manager, the first thing I'd do is
uncouple keyboard, mouse and video from each other. Why X has anything
to do with keyboard or mouse is beyond me.

Next, I'd base the video solution on SVG. It's clean, scaleable,
convertable to just about anything including a bitmap for your screen.
It's a standard, and it doesn't depend on what init system you're
using, or any other extraneous nonsense.

If SVG is too slow and bulky because it's XML, I'd create a smaller
version of SVG. I'm not going to do this, because I'm not smart enough.
But I'm pretty sure it could be done and would blow the doors off of
either X or Wayland.

As far as the keyboard, we had that completely solved in 1989, with
interrupts and keymaps. Add in internationalization, which is a problem
solved many years ago, and that's all you need for the keyboard.

All you need to know for mice is either the coordinates that got
clicked or other-evented, or the object. I've already made several
interactive SVG files, with Inkscape, that, when displayed in a browser,
change colors or whatever on events, or institute software commands
(which of course could be generalized callback routines).

It didn't have to be a choice between Wayland and X, but it is, thanks
to an organization I might despise more than Poettering/Redhat:
FreeDesktop.Org.


SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[o1bigtenor via Dng]

On Thu, Dec 31, 2020 at 8:18 AM o1bigtenor  wrote:
>
> On Wed, Dec 30, 2020 at 4:34 PM Steve Litt  wrote:
> >
> > On Wed, 30 Dec 2020 09:51:33 -1000
> > Joel Roth via Dng  wrote:
> snip
> > One question: How does your above statement hold up when Wayland
> > becomes the law of the land?
> >
>
> Greetings
>
> From what little I"ve been able to discern about Wayland I really hope that
> it doesn't become the law of the land.
> ( I will admit that I"m downright weird - - - - I have 2 graphics cards and
> presently 4 monitors with the 5th sitting waiting for time to install.
> One of my cards is old enough so that I run nouveau instead of any
> proprietary option (the card is EOLed!). I first set up this system in
> the beginning of 2011 and really struggled to find useful information
> to run this multi-monitor setup. There is a tiny bit of information that
> is available since the initial setup but very little which tells me that
> running multi-gpu and multi-monitor is highly unusual in the linux
> community. I just finished yesterday a project where I actually was
> needing to use all 4 monitors (all the screen real estate) and I still found
> myself wishing for more. For setup after any boot or reboot I use
> xrandr using notes from what I was able to find (xrandr is very terribly
> exampled and the notes are adequate but really do need a lot of
> experimenting - - - - which is not comfortable for most!!) better
> develop for myself.
>
> Spent a little time just now doing some searching and it seems that
> multi-gpu and serious multi-monitor (more than 2) is now considered
> to be the province of gamers. I don't really play any games - - - I have
> too much fun just using software on my system - - - - but then I'm a
> business  man and self-employed and that means, by definition, that
> I'm weird. I am working with software in a very wide range of things,
> from CADD to CAM (that very little at present), to spreadsheets, to
> starting to work in self designed software supporting equipment that
> I'm fabricating and a bunch of other things. To date I've been mostly a
> software user but am starting on becoming a software developer
> because in certain areas software just isn't adequate. In the software
> using I've found myself pushing the envelope because I combine things
> in ways that seem to all too often be non-customary.
>
> So - - - to draw the circle a little closer to closed - - - - what I see in
> Wayland doesn't enthuse me one iota - - - multi-gpu and serious i
> multi-monitor stuff is really still considered 'weird' and that means
> that its not really supported and if there is some support - - - - its
> called good luck finding it. (Most of the information on the web for
> xrandr is for version 1.3 (meaning version 3) or earlier yet I have found
> a hint that version 1.6 is immanent but I can't really find any information
> on what is proposed.)
>
> (>rant off)

I possibly should have changed the topic - - - - mea culpa!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[o1bigtenor via Dng]

On Wed, Dec 30, 2020 at 4:34 PM Steve Litt  wrote:
>
> On Wed, 30 Dec 2020 09:51:33 -1000
> Joel Roth via Dng  wrote:
snip
> One question: How does your above statement hold up when Wayland
> becomes the law of the land?
>

Greetings

From what little I"ve been able to discern about Wayland I really hope that
it doesn't become the law of the land.
(rant off)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Didier Kryn]

Le 30/12/2020 à 20:51, Joel Roth via Dng a écrit :
> On Thu, Dec 24, 2020, aitor wrote:
>> Hi Joel,
>>
>> On 24/12/20 7:40, Joel Roth wrote:
>>> Thanks for looking into this! I, for one, don't need
>>> to run KDE or Gnome.
>> I've been working on vdev during these days, and i'm thinking on a possible
>> new approach for it. For instance:
>>
>> 1) We should consider whether or not a separate ABI (libudev-compat) is
>> required since the apparition
>> of libeudev1 (libudev1 without systemd), or leave instead this other library
>> (compatible  with libeudev1, or
>> better said, depending on it) for new features added by Jude Nelson and
>> contributors (say the whole libudev-fs.c
>> or some add-ons like "udev_monitor *udev_monitor_new_from_filesystem" in
>> libudev-monitor.c, non existent
>> in libeudev1)
>>
>> 2) We should also consider the inclusion of a hardware database management 
>> tool, call udevadm, vdevadm or
>> whatever you want. I propose this addition due to the slow boot of the
>> system caused by the lack of  this tool,
>> i guess. In the case of eudev, the hardware database is compiled into a
>> binary and only the binary is used at
>> runtime. I should however add that yesterday I handled vdev with runit and
>> the boot process was very quick,
>> but there is a drawback here: you need to wait for the hardware to be
>> detected. In a console session I needed
>> to wait for the detection of wlan0 (even eth0 was detected inmediately); in
>> a X session I couldn't login because
>> neither the mouse nor the keyboard didn't respond.
> While I don't understand your post completely, I agree with
> your point that udev-compat need not be a high priority as
> libeudev meets this need. I understand that without
> udev-compat, vdev wouldn't be able to serve some heavyweight
> desktop environments.

    I'm not absolutely sure of what I write there, but it seems to me
that libeudev and eudev work together and the second contributes to fill
the data structures maintained by the first.

--     Didier


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

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Steve Litt]

On Wed, 30 Dec 2020 09:51:33 -1000
Joel Roth via Dng  wrote:

> Hi Aitor,
> 
> On Thu, Dec 24, 2020, aitor wrote:
> > Hi Joel,
> > 
> > On 24/12/20 7:40, Joel Roth wrote:  
> > > Thanks for looking into this! I, for one, don't need
> > > to run KDE or Gnome.  
> > 
> > I've been working on vdev during these days, and i'm thinking on a
> > possible new approach for it. For instance:
> > 
> > 1) We should consider whether or not a separate ABI
> > (libudev-compat) is required since the apparition
> > of libeudev1 (libudev1 without systemd), or leave instead this
> > other library (compatible  with libeudev1, or
> > better said, depending on it) for new features added by Jude Nelson
> > and contributors (say the whole libudev-fs.c
> > or some add-ons like "udev_monitor
> > *udev_monitor_new_from_filesystem" in libudev-monitor.c, non
> > existent in libeudev1)
> > 
> > 2) We should also consider the inclusion of a hardware database
> > management tool, call udevadm, vdevadm or
> > whatever you want. I propose this addition due to the slow boot of
> > the system caused by the lack of  this tool,
> > i guess. In the case of eudev, the hardware database is compiled
> > into a binary and only the binary is used at
> > runtime. I should however add that yesterday I handled vdev with
> > runit and the boot process was very quick,
> > but there is a drawback here: you need to wait for the hardware to
> > be detected. In a console session I needed
> > to wait for the detection of wlan0 (even eth0 was detected
> > inmediately); in a X session I couldn't login because
> > neither the mouse nor the keyboard didn't respond.  
> 
> While I don't understand your post completely, I agree with
> your point that udev-compat need not be a high priority as
> libeudev meets this need. I understand that without
> udev-compat, vdev wouldn't be able to serve some heavyweight
> desktop environments.

One question: How does your above statement hold up when Wayland
becomes the law of the land?
 
SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev (was: Re: if2mac init.d service for persistent network interface names)

[Joel Roth via Dng]

Hi Aitor,

On Thu, Dec 24, 2020, aitor wrote:
> Hi Joel,
> 
> On 24/12/20 7:40, Joel Roth wrote:
> > Thanks for looking into this! I, for one, don't need
> > to run KDE or Gnome.
> 
> I've been working on vdev during these days, and i'm thinking on a possible
> new approach for it. For instance:
> 
> 1) We should consider whether or not a separate ABI (libudev-compat) is
> required since the apparition
> of libeudev1 (libudev1 without systemd), or leave instead this other library
> (compatible  with libeudev1, or
> better said, depending on it) for new features added by Jude Nelson and
> contributors (say the whole libudev-fs.c
> or some add-ons like "udev_monitor *udev_monitor_new_from_filesystem" in
> libudev-monitor.c, non existent
> in libeudev1)
> 
> 2) We should also consider the inclusion of a hardware database management 
> tool, call udevadm, vdevadm or
> whatever you want. I propose this addition due to the slow boot of the
> system caused by the lack of  this tool,
> i guess. In the case of eudev, the hardware database is compiled into a
> binary and only the binary is used at
> runtime. I should however add that yesterday I handled vdev with runit and
> the boot process was very quick,
> but there is a drawback here: you need to wait for the hardware to be
> detected. In a console session I needed
> to wait for the detection of wlan0 (even eth0 was detected inmediately); in
> a X session I couldn't login because
> neither the mouse nor the keyboard didn't respond.

While I don't understand your post completely, I agree with
your point that udev-compat need not be a high priority as
libeudev meets this need. I understand that without
udev-compat, vdev wouldn't be able to serve some heavyweight
desktop environments.

I think that's okay, because Probably most potential users
of vdev will be using a lightweight window manager or even
just console.  I think serving that group will be a good
place to start. 

Also, while a database for fast startup would be great,
enabling it to work at all would be a good first step.

Eventually some sort of write-up about vdev comparing it to
mdev, udev, eudev might help getting the word out. (I'd 
help with that.)

Thanks for all your work!

Joel

> Cheers,
> 
> Aitor.
> 
> 
> 

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

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[aitor]

Hi again,

On 27/12/20 13:50, aitor wrote:


Hi,

Looking at the code of vdev, I've found an interesting library unknown 
until now for me:


http://sglib.sourceforge.net/doc/index.html#array_exam 



Sglib consists of a single header file written in C, and Jude Nelson 
includes it in libvdev:


https://github.com/jcnelson/vdev/blob/master/libvdev/sglib.h 



This header provides generic implementation of most common algorithms 
for arrays and lists.
In our case, it allows the use of some functions analogous to the type 
and use of std::vector in C++:


 - sglib_cstr_vector_init ( ... )

 - sglib_cstr_vector_push_back ( ... )

 - sglib_cstr_vector_size ( ... )

 - sglib_cstr_vector_free ( ... )

Anybody knows where can i find more information about this library?

Cheer,

Aitor.

Btw, I have a system with vdev working with graphical sessions, but the 
hardware takes too long

to respond, and i'm trying to figure out the origin of this delay.

Cheers,

Aitor.


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

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[aitor]

Hi,

Looking at the code of vdev, I've found an interesting library unknown 
until now for me:


http://sglib.sourceforge.net/doc/index.html#array_exam 



Sglib consists of a single header file written in C, and Jude Nelson 
includes it in libvdev:


https://github.com/jcnelson/vdev/blob/master/libvdev/sglib.h 



This header provides generic implementation of most common algorithms 
for arrays and lists.
In our case, it allows the use of some functions analogous to the type 
and use of std::vector in C++:


 - sglib_cstr_vector_init ( ... )

 - sglib_cstr_vector_push_back ( ... )

 - sglib_cstr_vector_size ( ... )

 - sglib_cstr_vector_free ( ... )

Anybody knows where can i find more information about this library?

Cheer,

Aitor.

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

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[Hendrik Boom]

On Sat, Dec 26, 2020 at 07:04:51PM +0100, Didier Kryn wrote:
> Le 25/12/2020 à 18:18, Hendrik Boom a écrit :
> >>> Hearing this thread's perplexity, I long for the days of mknod.
> >> But that wouldn't have helped with the network interfaces, because (in
> >> an un-Unixy way) their names have never been file names on the systems
> >> we're discussing now.
> > I wonder why.  Historical accident?  Or some deep technical reason?
> 
>     I guess it's historical: historically there was only character
> devices and block devices, and no provision for other categories, and
> maybe no provision in the bitfields which qualify the associated special
> files.

That makes sense.  Thank you.

> 
>    These device special files are used in particular to write to and
> read from and I think nobody wants this to happen with network devices.
> AFAIU, there are a lot of devices which don't show up in /dev, like all
> the intermediate devices, the ones which handle USB, SCSI, SATA, PCI.
> 
> --         Didier
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[Antony Stone]

On Saturday 26 December 2020 at 19:04:51, Didier Kryn wrote:

> I guess it's historical: historically there was only character devices and
> block devices, and no provision for other categories, and maybe no provision
> in the bitfields which qualify the associated special files.

Sounds entirely plausible.  I, too, have long wondered why ethX devices were 
never represented under /dev

> These device special files are used in particular to write to and read from
> and I think nobody wants this to happen with network devices. AFAIU, there
> are a lot of devices which don't show up in /dev, like all the intermediate
> devices, the ones which handle USB, SCSI, SATA, PCI.

Hm...

/dev/ttyUSBX
/dev/sdX
/dev/srX
/dev/hdX

I can't really think of a sensible category for PCI, since it's not so much a 
family of devices as just a way of plugging things in.  I mean, we never had 
/dev entries for ISA, VESA, AGP (and probably many more I don't think of right 
now), so why should the PC bus appear in /dev?

What's important is the thing that's plugged in to PCI, and that appears as 
/dev/lpX, /dev/ttyX, /dev/sdX, etc.

I also see no reason to list a USB hub, or a PCI bus, as a "device".  It's not 
like anything in userspace needs to talk to it, and that's what /dev is for, 
yes?


Antony.

-- 
Pavlov is in the pub enjoying a pint.
The barman rings for last orders, and Pavlov jumps up exclaiming "Damn!  I 
forgot to feed the dog!"

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[Didier Kryn]

Le 25/12/2020 à 18:18, Hendrik Boom a écrit :
>>> Hearing this thread's perplexity, I long for the days of mknod.
>> But that wouldn't have helped with the network interfaces, because (in
>> an un-Unixy way) their names have never been file names on the systems
>> we're discussing now.
> I wonder why.  Historical accident?  Or some deep technical reason?

    I guess it's historical: historically there was only character
devices and block devices, and no provision for other categories, and
maybe no provision in the bitfields which qualify the associated special
files.

   These device special files are used in particular to write to and
read from and I think nobody wants this to happen with network devices.
AFAIU, there are a lot of devices which don't show up in /dev, like all
the intermediate devices, the ones which handle USB, SCSI, SATA, PCI.

--         Didier


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

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[terryc]

On Fri, 25 Dec 2020 12:18:10 -0500
Hendrik Boom  wrote:

> On Fri, Dec 25, 2020 at 08:53:53AM -0800, Ian Zimmerman wrote:
> > On 2020-12-25 10:21, Steve Litt wrote:
> >   
> > > Hearing this thread's perplexity, I long for the days of mknod.  
> > 
> > But that wouldn't have helped with the network interfaces, because
> > (in an un-Unixy way) their names have never been file names on the
> > systems we're discussing now.  
> 
> I wonder why.  Historical accident?  Or some deep technical reason?
> and not historical?

Err, because NICs are modern.
IME,early networking was SLIP or PLIP and went via ye olde modem.
Sophisticated was the stat Mux.

Again, IME, NICs came with thin/thick net.
The evolution of TCP/IP?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[Hendrik Boom]

On Fri, Dec 25, 2020 at 08:53:53AM -0800, Ian Zimmerman wrote:
> On 2020-12-25 10:21, Steve Litt wrote:
> 
> > Hearing this thread's perplexity, I long for the days of mknod.
> 
> But that wouldn't have helped with the network interfaces, because (in
> an un-Unixy way) their names have never been file names on the systems
> we're discussing now.

I wonder why.  Historical accident?  Or some deep technical reason?

-- hendrik

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

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[Ian Zimmerman]

On 2020-12-25 10:21, Steve Litt wrote:

> Hearing this thread's perplexity, I long for the days of mknod.

But that wouldn't have helped with the network interfaces, because (in
an un-Unixy way) their names have never been file names on the systems
we're discussing now.

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

Re: [DNG] Vdev [ was Re: if2mac init.d service for persistent network interface names]

[Steve Litt]

On Fri, 25 Dec 2020 08:33:47 +0100
Didier Kryn  wrote:


>     Aitor I think you are the only person who knows vdev in depth.
> Therefore only you can decide what the best approach is, keeping in
> mind the amount of work is implied by the maintenance. I also agree
> that a tool to compile the database would be helpfull.

Hearing this thread's perplexity, I long for the days of mknod. If I'd
known udev and its descendants would turn into this kind of mess, I'd
have made an inotifywait or dmesg based shellscript to monitor
everything and perform the necessary mknod to create a device for it,
thereby eliminating a substantial part of the necessity for udev. Other
people could have created other shellscripts or simple C programs to do
the rest of udev's work.

Of course, that's 15 years water under the dam, settled law, so I'm not
going to do it.
 
SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Ralph Ronnquist]

Arnt Karlsen wrote on 28/04/17 04:02:

[cut]

..this is getting hilarious, I now have the mousepad working in
X, but not the keyboard joystick nor any keys or buttons.
Everything except the keyboard joystick and the top 3 buttons on
the mousepad, works in the console.
In my last goof boot, I found the hardware sound volume buttons
cleared the frame-buffer ;oD, so I carried on.

..and, I'm getting confused, I need your vdev-0.1.1, _and_ udev?
Which version, udev 220:3.2.2-2 amd64?

..udev whines about missing vdev's hwdb, should udev not have
its own hardware database?  Or is that gone away into systemd?

..I have:
root@box:~# dpkg -l |grep -w udev |fmt -tuw 140 |cut -d" " -f 1-4
ii hdmi2usb-udev 0.0.0+git20161124-2 all
ii libeeze1:amd64 1.8.6-2.5+b2 amd64
ii libinput-bin 1.6.3-1 amd64
ii sg3-utils-udev 1.42-2 all
ii system-config-printer-udev 1.5.7-3+b1 amd64
iF udev 220:3.2.2-2 amd64
ii udev-discover 0.2.2-1.2 amd64
root@box:~# dpkg -l |grep -w vdev |fmt -tuw 140 |cut -d" " -f 1-4
ii vdev 20161228-jessie1 amd64
ii vdev-assistant 20161228-jessie1 all
ii vdev-dbgsym 0.1.1 amd64
root@box:~#



Yes, and maybe we should continue off-list as people might run out of 
popcorn soon :-)


Though your system still seems to have an interesting combination of 
hotplug handling, but it does seem to be primarily Gnuinos' vdev.


1. > iF udev 220:3.2.2-2 amd64
That is the "udev" package, and it's not fully installed. "iF" means 
that you've tried installing it, and it's now "half-configured".


2. > ii vdev 20161228-jessie1 amd64
   > ii vdev-assistant 20161228-jessie1 all
I think those are Gnuinos' vdev, and there might be a third package 
"libudev1-compat" belonging to it. It seems to still be installed.


3. > ii vdev-dbgsym 0.1.1 amd64
This relates to Devuan's vdev, though I think it's "debug symbols" only, 
and not the actual package, which is called just "vdev".


But it's not the same as the "vdev" you have installed (with version 
code 20161228). Here we have a package naming conflict. The Devuan vdev 
package has version code "0.1.1".


Now, as I don't know the exact details of Gnuinos' package(s), I can 
only suggest that you firstly make the system go back to only having 
"udev", and be rebootable with that. In connection with that, you should 
purge all vdev packages, (including any libudev1-compat package).


Only thereafter should you install Devuans' "vdev" from "experimental" 
(only "vdev" is needed; not "vdev-dbgsym").


Then your system will have "udev" installed as well as "vdev". But only 
"vdev" is in operation, because when it is installed, it tucks away all 
"udev" control files so as to "render it harmless". However, since many 
other packages declare a dependency on "udev", this is left as if 
installed for the package management system. In other words, "udev" 
shows up as installed, but it is not in use.


At that point, it's also useful to "pin" udev, so as to avoid it being 
upgraded and taking over (eventually you'll need it upgraded, but "vdev" 
includes a special handshake for that).


Another thing to note is that the above installations and purges will 
rebuild initrd several times. That's no worry if it works nicely, but as 
precaution, it's good to make copies of intermediate, working initrd.


(I ran out of time here... need to rush)

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

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Arnt Karlsen]

On Wed, 26 Apr 2017 17:51:15 +0200, Arnt wrote in message 
<20170426175115.3d487...@nb6.lan>:

> On Wed, 26 Apr 2017 23:06:53 +1000, Ralph wrote in message 
> <039e14e4-8f63-878a-5878-0e01bcb57...@gmail.com>:
> 
> > 
> > 
> > Arnt Karlsen wrote on 26/04/17 22:01:
> > > On Wed, 26 Apr 2017 18:52:58 +1000, Ralph wrote in message
> > > :
> > >
> > >>
> > >>
> > >> Arnt Karlsen wrote on 26/04/17 17:26:
> > >>> On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message
> > >>> <2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:
> > >>>
> > 
> > 
> >  Arnt Karlsen wrote on 26/04/17 11:18:
> > > [cut]
> > 
> >  I believe keyboard and mouse needs the "evdev" module to be
> >  loaded before something; certainly before starting X.
> > >>>
> > >>> ..aye: root@box:~# lsmod |grep evdev
> > >>> evdev  24576  26
> > >>> root@box:~# lsmod |grep vdev |grep -v evdev
> > >>> root@box:~# lsmod |grep dev |grep -v evdev
> > >>> input_polldev  16384  1 lis3lv02d
> > >>> ipmi_devintf   20480  0
> > >>> ipmi_msghandler49152  3
> > >>> ipmi_devintf,ipmi_poweroff,ipmi_watchdog ppdev
> > >>> 20480  0 parport49152  3 lp,parport_pc,ppdev
> > >>> videodev  180224  3
> > >>> uvcvideo,videobuf2_core,videobuf2_v4l2 media
> > >>> 40960  2 uvcvideo,videodev joydev 20480  0
> > >>> root@box:~#
> > >>
> > >> Yeah, you would do "lsmod | grep -w evdev" only, and apparently
> > >> it's loaded, so probably not the issue. You can check inside
> > >> initrd image that "evdev" is mentioned in the "conf/modules" file
> > >> to ensure/verify that it happens early enough.
> > >>
> > >> Note that "vdev" itself is not a module, but is present in a
> > >> number of pre-pivot init scripts, the vdevd daemon, and its
> > >> configuration files. The vdevd daemon is run twice: once
> > >> pre-pivot, then that one is killed and another is started via
> > >> the /etc/init.d/vdev script.
> > >>
> >  [cut]
> > >>
> > >> Perhaps /var/log/Xorg.0.log tells something.
> > >
> > > ..3 of them here: https://pastebin.com/qsNGW8G0
> > >
> > >> And I have this vague
> > >> memory of being in that same situation, but I can't remember the
> > >> resolution.
> > >>
> > >> Ralph.
> > >
> > > ..aye, had I remembered what I did last time around... ;oD
> > >
> > 
> > Right. My guess from those is in fact that evdev is not loaded
> > early enough, because your logs don't mention it at all. I think
> > the story is that evdev needs to be loaded to handle "device
> > events" from vdev when it populates /dev/input, which it does at
> > its pre-pivot run. Loading it later (perhaps automatically by the
> > start of X) is of little help, because there are no new device
> > events.
> > 
> > You can test that theory manually by the following sequence:
> > # kill $(cat /run/vdev/vdevd.pif)
> > # rm -r /dev/input && /etc/init.d/vdev start
> > 
> > NOTE THOUGH that "rm -r /dev/input" may well kill your console
> > input instead, and you might need to power-toggle to recover.
> 
> ..we'll see about that, I have a ssh session handy. ;o)
> 
> > BUT, it's also believable (to me) that the restart of vdev after
> > having removed all /dev/input/* entries will cause it to
> > re-populate /dev/input, and now (since evdev has been loaded) it
> > should also tickle evdev usefully. By that idea it should recover
> > any lost console input as well as setting up evdev for the X input.
> > 
> > In either case, you need to make sure that evdev is indeed in the 
> > "conf/modules" list in the initrd image, which is how it's loaded.
> 
> ..no mention of it down my /etc/initramfs-tools/ tree, and, it 
> should have been in /usr/share/initramfs-tools/modules or in e.g. 
> /usr/share/initramfs-tools/modules.d/modules.vdev ?
> 
> ..aaand, my initrd.img-4.9.0-2-rt-amd64 played tough, so more torture
> ideas were needed, Osamu Aoki's getinitramfs script from Debian's
> #790095 squeezed out my trashed cpio archive, which contains evdev
> and vdev and a suspect "/conf/modules" with no mention of neither 
> vdev nor evdev.  But it works and I wanna know how and why. ;oD
> 
> > If 
> > it's not already in there, your initrd is likely to be a remnant
> > from your Gnuinos' vdev experiments, or at least, not an initrd
> > including the Devuan's vdev scripting. In that case, a --reinstall
> > could do wonders.
> > 
> > Ralph.
> 
> ..could, indeed. ;oD

..this is getting hilarious, I now have the mousepad working in 
X, but not the keyboard joystick nor any keys or buttons.  
Everything except the keyboard joystick and the top 3 buttons on 
the mousepad, works in the console.  
In my last goof boot, I found the hardware sound volume buttons 
cleared the frame-buffer ;oD, so I carried on.

..and, I'm getting confused, I need your vdev-0.1.1, _and_ udev?
Which version, udev 220:3.2.2-2 amd64? 

..udev whines about missing vdev's hwdb, should udev not have 
its own 

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Arnt Karlsen]

On Wed, 26 Apr 2017 23:06:53 +1000, Ralph wrote in message 
<039e14e4-8f63-878a-5878-0e01bcb57...@gmail.com>:

> 
> 
> Arnt Karlsen wrote on 26/04/17 22:01:
> > On Wed, 26 Apr 2017 18:52:58 +1000, Ralph wrote in message
> > :
> >
> >>
> >>
> >> Arnt Karlsen wrote on 26/04/17 17:26:
> >>> On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message
> >>> <2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:
> >>>
> 
> 
>  Arnt Karlsen wrote on 26/04/17 11:18:
> > [cut]
> 
>  I believe keyboard and mouse needs the "evdev" module to be
>  loaded before something; certainly before starting X.
> >>>
> >>> ..aye: root@box:~# lsmod |grep evdev
> >>> evdev  24576  26
> >>> root@box:~# lsmod |grep vdev |grep -v evdev
> >>> root@box:~# lsmod |grep dev |grep -v evdev
> >>> input_polldev  16384  1 lis3lv02d
> >>> ipmi_devintf   20480  0
> >>> ipmi_msghandler49152  3
> >>> ipmi_devintf,ipmi_poweroff,ipmi_watchdog ppdev
> >>> 20480  0 parport49152  3 lp,parport_pc,ppdev
> >>> videodev  180224  3
> >>> uvcvideo,videobuf2_core,videobuf2_v4l2 media
> >>> 40960  2 uvcvideo,videodev joydev 20480  0
> >>> root@box:~#
> >>
> >> Yeah, you would do "lsmod | grep -w evdev" only, and apparently
> >> it's loaded, so probably not the issue. You can check inside
> >> initrd image that "evdev" is mentioned in the "conf/modules" file
> >> to ensure/verify that it happens early enough.
> >>
> >> Note that "vdev" itself is not a module, but is present in a number
> >> of pre-pivot init scripts, the vdevd daemon, and its configuration
> >> files. The vdevd daemon is run twice: once pre-pivot, then that one
> >> is killed and another is started via the /etc/init.d/vdev script.
> >>
>  [cut]
> >>
> >> Perhaps /var/log/Xorg.0.log tells something.
> >
> > ..3 of them here: https://pastebin.com/qsNGW8G0
> >
> >> And I have this vague
> >> memory of being in that same situation, but I can't remember the
> >> resolution.
> >>
> >> Ralph.
> >
> > ..aye, had I remembered what I did last time around... ;oD
> >
> 
> Right. My guess from those is in fact that evdev is not loaded early 
> enough, because your logs don't mention it at all. I think the story
> is that evdev needs to be loaded to handle "device events" from vdev
> when it populates /dev/input, which it does at its pre-pivot run.
> Loading it later (perhaps automatically by the start of X) is of
> little help, because there are no new device events.
> 
> You can test that theory manually by the following sequence:
> # kill $(cat /run/vdev/vdevd.pif)
> # rm -r /dev/input && /etc/init.d/vdev start
> 
> NOTE THOUGH that "rm -r /dev/input" may well kill your console input 
> instead, and you might need to power-toggle to recover.

..we'll see about that, I have a ssh session handy. ;o)

> BUT, it's also believable (to me) that the restart of vdev after
> having removed all /dev/input/* entries will cause it to re-populate 
> /dev/input, and now (since evdev has been loaded) it should also
> tickle evdev usefully. By that idea it should recover any lost
> console input as well as setting up evdev for the X input.
> 
> In either case, you need to make sure that evdev is indeed in the 
> "conf/modules" list in the initrd image, which is how it's loaded.

..no mention of it down my /etc/initramfs-tools/ tree, and, it 
should have been in /usr/share/initramfs-tools/modules or in e.g. 
/usr/share/initramfs-tools/modules.d/modules.vdev ?

..aaand, my initrd.img-4.9.0-2-rt-amd64 played tough, so more torture
ideas were needed, Osamu Aoki's getinitramfs script from Debian's
#790095 squeezed out my trashed cpio archive, which contains evdev
and vdev and a suspect "/conf/modules" with no mention of neither 
vdev nor evdev.  But it works and I wanna know how and why. ;oD

> If 
> it's not already in there, your initrd is likely to be a remnant
> from your Gnuinos' vdev experiments, or at least, not an initrd
> including the Devuan's vdev scripting. In that case, a --reinstall
> could do wonders.
> 
> Ralph.

..could, indeed. ;oD



-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Ralph Ronnquist]

Arnt Karlsen wrote on 26/04/17 22:01:

On Wed, 26 Apr 2017 18:52:58 +1000, Ralph wrote in message
:




Arnt Karlsen wrote on 26/04/17 17:26:

On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message
<2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:




Arnt Karlsen wrote on 26/04/17 11:18:

[cut]


I believe keyboard and mouse needs the "evdev" module to be loaded
before something; certainly before starting X.


..aye: root@box:~# lsmod |grep evdev
evdev  24576  26
root@box:~# lsmod |grep vdev |grep -v evdev
root@box:~# lsmod |grep dev |grep -v evdev
input_polldev  16384  1 lis3lv02d
ipmi_devintf   20480  0
ipmi_msghandler49152  3
ipmi_devintf,ipmi_poweroff,ipmi_watchdog ppdev
20480  0 parport49152  3 lp,parport_pc,ppdev
videodev  180224  3
uvcvideo,videobuf2_core,videobuf2_v4l2 media
40960  2 uvcvideo,videodev joydev 20480  0
root@box:~#


Yeah, you would do "lsmod | grep -w evdev" only, and apparently it's
loaded, so probably not the issue. You can check inside initrd image
that "evdev" is mentioned in the "conf/modules" file to ensure/verify
that it happens early enough.

Note that "vdev" itself is not a module, but is present in a number
of pre-pivot init scripts, the vdevd daemon, and its configuration
files. The vdevd daemon is run twice: once pre-pivot, then that one
is killed and another is started via the /etc/init.d/vdev script.


[cut]


Perhaps /var/log/Xorg.0.log tells something.


..3 of them here: https://pastebin.com/qsNGW8G0


And I have this vague
memory of being in that same situation, but I can't remember the
resolution.

Ralph.


..aye, had I remembered what I did last time around... ;oD



Right. My guess from those is in fact that evdev is not loaded early 
enough, because your logs don't mention it at all. I think the story is 
that evdev needs to be loaded to handle "device events" from vdev when 
it populates /dev/input, which it does at its pre-pivot run. Loading it 
later (perhaps automatically by the start of X) is of little help, 
because there are no new device events.


You can test that theory manually by the following sequence:
# kill $(cat /run/vdev/vdevd.pif)
# rm -r /dev/input && /etc/init.d/vdev start

NOTE THOUGH that "rm -r /dev/input" may well kill your console input 
instead, and you might need to power-toggle to recover.


BUT, it's also believable (to me) that the restart of vdev after having 
removed all /dev/input/* entries will cause it to re-populate 
/dev/input, and now (since evdev has been loaded) it should also tickle 
evdev usefully. By that idea it should recover any lost console input as 
well as setting up evdev for the X input.


In either case, you need to make sure that evdev is indeed in the 
"conf/modules" list in the initrd image, which is how it's loaded. If 
it's not already in there, your initrd is likely to be a remnant from 
your Gnuinos' vdev experiments, or at least, not an initrd including the 
Devuan's vdev scripting. In that case, a --reinstall could do wonders.


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

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Arnt Karlsen]

On Wed, 26 Apr 2017 18:52:58 +1000, Ralph wrote in message 
:

> 
> 
> Arnt Karlsen wrote on 26/04/17 17:26:
> > On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message
> > <2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:
> >
> >>
> >>
> >> Arnt Karlsen wrote on 26/04/17 11:18:
> >>> [cut]
> >>
> >> I believe keyboard and mouse needs the "evdev" module to be loaded
> >> before something; certainly before starting X.
> >
> > ..aye: root@box:~# lsmod |grep evdev
> > evdev  24576  26
> > root@box:~# lsmod |grep vdev |grep -v evdev
> > root@box:~# lsmod |grep dev |grep -v evdev
> > input_polldev  16384  1 lis3lv02d
> > ipmi_devintf   20480  0
> > ipmi_msghandler49152  3
> > ipmi_devintf,ipmi_poweroff,ipmi_watchdog ppdev
> > 20480  0 parport49152  3 lp,parport_pc,ppdev
> > videodev  180224  3
> > uvcvideo,videobuf2_core,videobuf2_v4l2 media
> > 40960  2 uvcvideo,videodev joydev 20480  0
> > root@box:~#
> 
> Yeah, you would do "lsmod | grep -w evdev" only, and apparently it's 
> loaded, so probably not the issue. You can check inside initrd image 
> that "evdev" is mentioned in the "conf/modules" file to ensure/verify 
> that it happens early enough.
> 
> Note that "vdev" itself is not a module, but is present in a number
> of pre-pivot init scripts, the vdevd daemon, and its configuration
> files. The vdevd daemon is run twice: once pre-pivot, then that one
> is killed and another is started via the /etc/init.d/vdev script.
> 
> >> [cut]
> 
> Perhaps /var/log/Xorg.0.log tells something.

..3 of them here: https://pastebin.com/qsNGW8G0

> And I have this vague 
> memory of being in that same situation, but I can't remember the
> resolution.
> 
> Ralph.

..aye, had I remembered what I did last time around... ;oD

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Ralph Ronnquist]

Arnt Karlsen wrote on 26/04/17 17:26:

On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message
<2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:




Arnt Karlsen wrote on 26/04/17 11:18:

[cut]


I believe keyboard and mouse needs the "evdev" module to be loaded
before something; certainly before starting X.


..aye: root@box:~# lsmod |grep evdev
evdev  24576  26
root@box:~# lsmod |grep vdev |grep -v evdev
root@box:~# lsmod |grep dev |grep -v evdev
input_polldev  16384  1 lis3lv02d
ipmi_devintf   20480  0
ipmi_msghandler49152  3 ipmi_devintf,ipmi_poweroff,ipmi_watchdog
ppdev  20480  0
parport49152  3 lp,parport_pc,ppdev
videodev  180224  3 uvcvideo,videobuf2_core,videobuf2_v4l2
media  40960  2 uvcvideo,videodev
joydev 20480  0
root@box:~#


Yeah, you would do "lsmod | grep -w evdev" only, and apparently it's 
loaded, so probably not the issue. You can check inside initrd image 
that "evdev" is mentioned in the "conf/modules" file to ensure/verify 
that it happens early enough.


Note that "vdev" itself is not a module, but is present in a number of 
pre-pivot init scripts, the vdevd daemon, and its configuration files.
The vdevd daemon is run twice: once pre-pivot, then that one is killed 
and another is started via the /etc/init.d/vdev script.



[cut]


Perhaps /var/log/Xorg.0.log tells something. And I have this vague 
memory of being in that same situation, but I can't remember the resolution.


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

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Arnt Karlsen]

On Wed, 26 Apr 2017 12:08:48 +1000, Ralph wrote in message 
<2fab2208-e0dc-27f5-dd3d-f9d7156bb...@gmail.com>:

> 
> 
> Arnt Karlsen wrote on 26/04/17 11:18:
> > On Mon, 24 Apr 2017 14:49:06 +1000, Ralph wrote in message
> > :
> >
> >>
> >> Arnt Karlsen wrote on 24/04/17 09:13:
> >>> On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message
> >>> <20170419185407.228cd...@nb6.lan>:
> >>>
>  On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message
>  :
> 
> >
> >
> > Arnt Karlsen wrote on 19/04/17 23:17:
> > [cut]
> >>
> >> ...wiped udev off my box and wound up with a box that boots oh
> >> soo fine until it tries to load my new vdev
> >> initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try
> >> this on a rt kernel?
> >>
> >> ..recovery ideas?  Do we have any vdev live-cd?
> >>
> >> ..last time I did this stunt, I chrooted in off a Knoppix? iso,
> >> I have memdisk and a few iso links handy in /boot, and Debian's
> >> Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
> >> vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they
> >> all depend on a working install of udev AFAIK, and I'd prefer
> >> pushing thru with vdev rather than going back to udev.
> >>
> >> ..has anyone here tried downgrading to Debian Wheezy era udev?
> >>
> >>
> >> ..looking for recovery live-cd idea starting points, I came
> >> across 32-bit
> >> https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
> >> which could work both as a starting point for a live-cd and as
> >> a starting point for an upgrade path for stuck Debian Wheezy
> >> people via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.
> >>
> >> ..according to https://debiandog.github.io/doglinux/ "DebianDog
> >> is very small Debian Live CD shaped to look and act like Puppy
> >> Linux. Debian structure and Debian behaviour are untouched and
> >> Debian documentation is 100% valid for DebianDog. You have
> >> access to all debian repositories using apt-get or synaptic.",
> >> creating "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their
> >> repos for ours, update, upgrade and remaster, the 64-bit
> >> version likely needs to be built off deb-src lines.
> >>
> >>
> >> ..but first comes the classic chicken-and-egg 64 bit recovery
> >> I need now. ;o)
> >>
> >
> > I'm not sure it helps you, but I've made a vdev variant of most
> > recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
> > 2017-Mar-27 20:57) that I got from the official mirror
> > http://mirror.sfo12.us.leaseweb.net/devuan/
> >
> > I purged a couple of things from it, then added and installed
> > "my" vdev_0.1.1_amd64.deb, and made a refractasnapshot of this,
> > into devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is
> > downloadable at https://www.uk.realsam.co.uk/files/devuan/
> >
> > It boots with vdev rather than udev, and udev remains installed,
> > though with all its "competing" files tucked away. As you might
> > know, this vdev packaging is different from aitor's packaging
> > for gnuinos by not declaring a udev competition, but rather
> > attempting to manage a dynamic choice of which one is in use.
> > The software is otherwise the same, I believe.
> 
>  ..thanks, we shall find out. ;o)
> >>>
> >>> ..no joy this far, vdev does not work with any of my installed
> >>> kernels, neither my dpkg variant of your vdev-assistant nor your
> >>> original restores udev, so I'm stuck with live-CDs when I need to
> >>> go online to chk things to read up on.
> >>>
> >>> ..you packaged your vdev differently than aitor, do I then use
> >>> your deb(-src) lines in /etc/apt/sources.list and comment out
> >>> his?
> >>>
> >>> ..another approach is ignore apt and dpkg, and simply drop in all
> >>> files with tar or cpio or somesuch, haven't done that kinda stunt
> >>> since my RH-5.2 days.
> >>>
> >>> ..if that fails, are you able to build me an old fashion monster
> >>> monolithic kernel with nouveau, vdev and everything else compiled
> >>> into the kernel, and not as modules, that I can boot without an
> >>> initrd?
> >>> Big size is no problem, I have 8GB ram, but no build box.
> >>>
> >>> ..if not, what do I need to build a vdev kernel myself on my
> >>> box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?
> >>
> >> If the live iso works, you can restore udev via chroot to your root
> >> file system. It's a relatively simple sequence:
> >> # mnt /dev/sdaX /mnt
> >> # chroot /mnt
> >> # mount -t proc none proc
> >> # mount -t sysfs none /sys
> >> # mount -t devpts none /dev/pts
> >> # apt-get install udev
> >> # apt-get purge *vdev*   <-- all aitor's vdev packages
> >
> > ..er, something went wrong here, I forgot? to 

Re: [DNG] ..vdev input in X, was:..vdev box recovery ideas?

[Ralph Ronnquist]

Arnt Karlsen wrote on 26/04/17 11:18:

On Mon, 24 Apr 2017 14:49:06 +1000, Ralph wrote in message
:



Arnt Karlsen wrote on 24/04/17 09:13:

On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message
<20170419185407.228cd...@nb6.lan>:


On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message
:




Arnt Karlsen wrote on 19/04/17 23:17:
[cut]


...wiped udev off my box and wound up with a box that boots oh
soo fine until it tries to load my new vdev
initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try
this on a rt kernel?

..recovery ideas?  Do we have any vdev live-cd?

..last time I did this stunt, I chrooted in off a Knoppix? iso,
I have memdisk and a few iso links handy in /boot, and Debian's
Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
depend on a working install of udev AFAIK, and I'd prefer pushing
thru with vdev rather than going back to udev.

..has anyone here tried downgrading to Debian Wheezy era udev?


..looking for recovery live-cd idea starting points, I came
across 32-bit
https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
which could work both as a starting point for a live-cd and as a
starting point for an upgrade path for stuck Debian Wheezy people
via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.

..according to https://debiandog.github.io/doglinux/ "DebianDog
is very small Debian Live CD shaped to look and act like Puppy
Linux. Debian structure and Debian behaviour are untouched and
Debian documentation is 100% valid for DebianDog. You have
access to all debian repositories using apt-get or synaptic.",
creating "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their
repos for ours, update, upgrade and remaster, the 64-bit version
likely needs to be built off deb-src lines.


..but first comes the classic chicken-and-egg 64 bit recovery
I need now. ;o)



I'm not sure it helps you, but I've made a vdev variant of most
recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
2017-Mar-27 20:57) that I got from the official mirror
http://mirror.sfo12.us.leaseweb.net/devuan/

I purged a couple of things from it, then added and installed "my"
vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into
devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is
downloadable at https://www.uk.realsam.co.uk/files/devuan/

It boots with vdev rather than udev, and udev remains installed,
though with all its "competing" files tucked away. As you might
know, this vdev packaging is different from aitor's packaging for
gnuinos by not declaring a udev competition, but rather attempting
to manage a dynamic choice of which one is in use. The software is
otherwise the same, I believe.


..thanks, we shall find out. ;o)


..no joy this far, vdev does not work with any of my installed
kernels, neither my dpkg variant of your vdev-assistant nor your
original restores udev, so I'm stuck with live-CDs when I need to
go online to chk things to read up on.

..you packaged your vdev differently than aitor, do I then use
your deb(-src) lines in /etc/apt/sources.list and comment out
his?

..another approach is ignore apt and dpkg, and simply drop in all
files with tar or cpio or somesuch, haven't done that kinda stunt
since my RH-5.2 days.

..if that fails, are you able to build me an old fashion monster
monolithic kernel with nouveau, vdev and everything else compiled
into the kernel, and not as modules, that I can boot without an
initrd?
Big size is no problem, I have 8GB ram, but no build box.

..if not, what do I need to build a vdev kernel myself on my
box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?


If the live iso works, you can restore udev via chroot to your root
file system. It's a relatively simple sequence:
# mnt /dev/sdaX /mnt
# chroot /mnt
# mount -t proc none proc
# mount -t sysfs none /sys
# mount -t devpts none /dev/pts
# apt-get install udev
# apt-get purge *vdev*   <-- all aitor's vdev packages


..er, something went wrong here, I forgot? to mention
my bad apt database means doing things rpm-hell style
with dpkg or tarball style, and forgot to umount -v \
/mnt/proc et al before exiting my chroot, and wound
up hitting the power button, on reboot, it decided to
fsck a weird "/rootfs" and failed, so I did one off a
live iso and tried a new boot, and now I just need to
get vdev's mousepad 'n keybd input working in X too,
all is fine in the console. ;oD


[cut]


I believe keyboard and mouse needs the "evdev" module to be loaded 
before something; certainly before starting X. "My" vdev scripts for 
initramfs does that by adding a line "vdev" to the file "/conf/modules" 
in the initrd, which makes it be loaded at the pre-pivot stage.


Actually, as I'm confused about which vdev variant you are using, maybe 
we can identify the as "Gnuinos' vdev" and "Devuan's vdev" hence.


In any 

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[fsmithred]

On 04/24/2017 03:59 PM, Arnt Karlsen wrote:
> On Mon, 24 Apr 2017 14:16:03 -0400, fsmithred wrote in message 
> :
> 
>> On 04/24/2017 10:39 AM, Arnt Karlsen wrote:
>>> On Mon, 24 Apr 2017 08:43:35 -0400, fsmithred wrote in message 
>>> <1b574913-ccd5-2395-1c8d-2647d7e40...@gmail.com>:
>>>
 On 04/24/2017 07:21 AM, Arnt Karlsen wrote:
> On Mon, 24 Apr 2017 05:18:32 -0400, fsmithred wrote in message 
> :

 

>>>
>>
>> I don't know if this would be of any help to you, but I have a
>> vdev live iso that I made using Ralph's vdev packages back in
>> October. After reading this thread, I decided to install it and
>> upgrade to the 4.9rt kernel. It boots normally.
>>
>> What I can't seem to do is make a bootable iso with the 4.9rt,
>> even after upgrading live-boot, et. al. to the ascii versions.
>> (There's a problem with the bpo versions of live-boot missing
>> some parts in the initrd related to overlayfs and nls_ascii).
>>
>> If you want to try the October live iso, let me know.
>
> ..yup, url?
>

 jessie-vdev2 iso:
 http://distro.ibiblio.org/refracta/files/experimental/

 Notes:
 - boots to console, startx to get to openbox
 - If you want to get rid of the desktop background, it's in the
 spacefm settings.
 - usernames:passwords are root:root and user:user
 - There's a gear icon on the panel that opens a terminal running
 the... (I forget what it's called) script that lets you switch
 between udev and vdev. I assume that it still works, but I didn't
 test it on this install.
 - I think I have it set to not install recommends.
 - *systemd* is pinned, so no libsystemd0 or libpam-systemd

 (these are older than the vdev in the repo)
 vdevd-2.0.2, libudev_compat_1.2.1, vdev-initramfs_1.2.7

 fsmithred
>>>
>>> ..thanks, DL in progress. :o)
>>>
>>
>> Update: I removed the 4.9rt kernel and replaced it with the regular
>> 4.9-bpo kernel. 
> 
> ..looks like these are set up the same way as the Sid/Ceres ones, my
> diff is also 222 lines.
> 
>> System still boots, and the live iso I made with it
>> boots.
>>
>> http://paste.debian.net/929150/
>> I ran a diff on the kernel configs, but I don't see anything obvious.
>> A few months ago, there were problems with the 4.8-bpo kernel and
>> live-boot. Some overlayfs and nls_ascii were missing from the initrd.
>> That was fixed in the 2017 version of live-boot.
> 
> ..one good thing about distractions is they buys me time to have other
> people find out things for me. ;o)
> 
> ..mounting it after dd'ing it, I see isolinux and boot/grub, but also 
> boot/grub/efiboot.img and efi/boot/bootx64.efi, and my box didn't
> like Qubes-R3.2's way to "efi-boot", next boot to grub took an hour. 
> 
> ..your iso boots directly into isolinux or grub without messing up my 
> "efi stuffed bios"?
> 
> 

If you're using uefi instead of legacy bios, it should boot with grub, and
it shouldn't mess anything up. CAVEAT: There's no uniformity in uefi
implementations across manufacturers. If you want to install it, the
safest way is if you have another linux on the machine, install this one
without a bootloader, and add it to the menu of the linux that handles the
boot.

Now that I think about it, grub-pc is installed in that image. If you want
to install the bootloader, the grub-efi debs are in the root directory.
The installer should find them and ask if you want it to install them (in
a chroot) for you, which will cause grub to take over the boot, or it will
provide you with a fully-prepared chroot terminal where you could install
them yourself with dpkg, or you can continue without a bootloader.

See /usr/lib/refractainstaller/uefi_install.readme
That one is newer than the one in user's home.

Oh, and if you want to do a manual chroot for something, there's a script
in user's bin that will do the bind mounts for sys proc and dev.

fsmithred

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

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Arnt Karlsen]

On Mon, 24 Apr 2017 14:16:03 -0400, fsmithred wrote in message 
:

> On 04/24/2017 10:39 AM, Arnt Karlsen wrote:
> > On Mon, 24 Apr 2017 08:43:35 -0400, fsmithred wrote in message 
> > <1b574913-ccd5-2395-1c8d-2647d7e40...@gmail.com>:
> > 
> >> On 04/24/2017 07:21 AM, Arnt Karlsen wrote:
> >>> On Mon, 24 Apr 2017 05:18:32 -0400, fsmithred wrote in message 
> >>> :
> >>
> >> 
> >>
> >
> 
>  I don't know if this would be of any help to you, but I have a
>  vdev live iso that I made using Ralph's vdev packages back in
>  October. After reading this thread, I decided to install it and
>  upgrade to the 4.9rt kernel. It boots normally.
> 
>  What I can't seem to do is make a bootable iso with the 4.9rt,
>  even after upgrading live-boot, et. al. to the ascii versions.
>  (There's a problem with the bpo versions of live-boot missing
>  some parts in the initrd related to overlayfs and nls_ascii).
> 
>  If you want to try the October live iso, let me know.
> >>>
> >>> ..yup, url?
> >>>
> >>
> >> jessie-vdev2 iso:
> >> http://distro.ibiblio.org/refracta/files/experimental/
> >>
> >> Notes:
> >> - boots to console, startx to get to openbox
> >> - If you want to get rid of the desktop background, it's in the
> >> spacefm settings.
> >> - usernames:passwords are root:root and user:user
> >> - There's a gear icon on the panel that opens a terminal running
> >> the... (I forget what it's called) script that lets you switch
> >> between udev and vdev. I assume that it still works, but I didn't
> >> test it on this install.
> >> - I think I have it set to not install recommends.
> >> - *systemd* is pinned, so no libsystemd0 or libpam-systemd
> >>
> >> (these are older than the vdev in the repo)
> >> vdevd-2.0.2, libudev_compat_1.2.1, vdev-initramfs_1.2.7
> >>
> >> fsmithred
> > 
> > ..thanks, DL in progress. :o)
> > 
> 
> Update: I removed the 4.9rt kernel and replaced it with the regular
> 4.9-bpo kernel. 

..looks like these are set up the same way as the Sid/Ceres ones, my
diff is also 222 lines.

> System still boots, and the live iso I made with it
> boots.
> 
> http://paste.debian.net/929150/
> I ran a diff on the kernel configs, but I don't see anything obvious.
> A few months ago, there were problems with the 4.8-bpo kernel and
> live-boot. Some overlayfs and nls_ascii were missing from the initrd.
> That was fixed in the 2017 version of live-boot.

..one good thing about distractions is they buys me time to have other
people find out things for me. ;o)

..mounting it after dd'ing it, I see isolinux and boot/grub, but also 
boot/grub/efiboot.img and efi/boot/bootx64.efi, and my box didn't
like Qubes-R3.2's way to "efi-boot", next boot to grub took an hour. 

..your iso boots directly into isolinux or grub without messing up my 
"efi stuffed bios"?


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[fsmithred]

On 04/24/2017 10:39 AM, Arnt Karlsen wrote:
> On Mon, 24 Apr 2017 08:43:35 -0400, fsmithred wrote in message 
> <1b574913-ccd5-2395-1c8d-2647d7e40...@gmail.com>:
> 
>> On 04/24/2017 07:21 AM, Arnt Karlsen wrote:
>>> On Mon, 24 Apr 2017 05:18:32 -0400, fsmithred wrote in message 
>>> :
>>
>> 
>>
>

 I don't know if this would be of any help to you, but I have a vdev
 live iso that I made using Ralph's vdev packages back in October.
 After reading this thread, I decided to install it and upgrade to
 the 4.9rt kernel. It boots normally.

 What I can't seem to do is make a bootable iso with the 4.9rt, even
 after upgrading live-boot, et. al. to the ascii versions. (There's
 a problem with the bpo versions of live-boot missing some parts in
 the initrd related to overlayfs and nls_ascii).

 If you want to try the October live iso, let me know.
>>>
>>> ..yup, url?
>>>
>>
>> jessie-vdev2 iso:
>> http://distro.ibiblio.org/refracta/files/experimental/
>>
>> Notes:
>> - boots to console, startx to get to openbox
>> - If you want to get rid of the desktop background, it's in the
>> spacefm settings.
>> - usernames:passwords are root:root and user:user
>> - There's a gear icon on the panel that opens a terminal running
>> the... (I forget what it's called) script that lets you switch
>> between udev and vdev. I assume that it still works, but I didn't
>> test it on this install.
>> - I think I have it set to not install recommends.
>> - *systemd* is pinned, so no libsystemd0 or libpam-systemd
>>
>> (these are older than the vdev in the repo)
>> vdevd-2.0.2, libudev_compat_1.2.1, vdev-initramfs_1.2.7
>>
>> fsmithred
> 
> ..thanks, DL in progress. :o)
> 

Update: I removed the 4.9rt kernel and replaced it with the regular
4.9-bpo kernel. System still boots, and the live iso I made with it boots.

http://paste.debian.net/929150/
I ran a diff on the kernel configs, but I don't see anything obvious. A
few months ago, there were problems with the 4.8-bpo kernel and live-boot.
Some overlayfs and nls_ascii were missing from the initrd. That was fixed
in the 2017 version of live-boot.

fsmithred

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

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Arnt Karlsen]

On Mon, 24 Apr 2017 08:43:35 -0400, fsmithred wrote in message 
<1b574913-ccd5-2395-1c8d-2647d7e40...@gmail.com>:

> On 04/24/2017 07:21 AM, Arnt Karlsen wrote:
> > On Mon, 24 Apr 2017 05:18:32 -0400, fsmithred wrote in message 
> > :
> 
> 
> 
> >>>
> >>
> >> I don't know if this would be of any help to you, but I have a vdev
> >> live iso that I made using Ralph's vdev packages back in October.
> >> After reading this thread, I decided to install it and upgrade to
> >> the 4.9rt kernel. It boots normally.
> >>
> >> What I can't seem to do is make a bootable iso with the 4.9rt, even
> >> after upgrading live-boot, et. al. to the ascii versions. (There's
> >> a problem with the bpo versions of live-boot missing some parts in
> >> the initrd related to overlayfs and nls_ascii).
> >>
> >> If you want to try the October live iso, let me know.
> > 
> > ..yup, url?
> > 
> 
> jessie-vdev2 iso:
> http://distro.ibiblio.org/refracta/files/experimental/
> 
> Notes:
> - boots to console, startx to get to openbox
> - If you want to get rid of the desktop background, it's in the
> spacefm settings.
> - usernames:passwords are root:root and user:user
> - There's a gear icon on the panel that opens a terminal running
> the... (I forget what it's called) script that lets you switch
> between udev and vdev. I assume that it still works, but I didn't
> test it on this install.
> - I think I have it set to not install recommends.
> - *systemd* is pinned, so no libsystemd0 or libpam-systemd
> 
> (these are older than the vdev in the repo)
> vdevd-2.0.2, libudev_compat_1.2.1, vdev-initramfs_1.2.7
> 
> fsmithred

..thanks, DL in progress. :o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[fsmithred]

On 04/24/2017 07:21 AM, Arnt Karlsen wrote:
> On Mon, 24 Apr 2017 05:18:32 -0400, fsmithred wrote in message 
> :



>>>
>>
>> I don't know if this would be of any help to you, but I have a vdev
>> live iso that I made using Ralph's vdev packages back in October.
>> After reading this thread, I decided to install it and upgrade to the
>> 4.9rt kernel. It boots normally.
>>
>> What I can't seem to do is make a bootable iso with the 4.9rt, even
>> after upgrading live-boot, et. al. to the ascii versions. (There's a
>> problem with the bpo versions of live-boot missing some parts in the
>> initrd related to overlayfs and nls_ascii).
>>
>> If you want to try the October live iso, let me know.
> 
> ..yup, url?
> 

jessie-vdev2 iso:
http://distro.ibiblio.org/refracta/files/experimental/

Notes:
- boots to console, startx to get to openbox
- If you want to get rid of the desktop background, it's in the spacefm
settings.
- usernames:passwords are root:root and user:user
- There's a gear icon on the panel that opens a terminal running the... (I
forget what it's called) script that lets you switch between udev and
vdev. I assume that it still works, but I didn't test it on this install.
- I think I have it set to not install recommends.
- *systemd* is pinned, so no libsystemd0 or libpam-systemd

(these are older than the vdev in the repo)
vdevd-2.0.2, libudev_compat_1.2.1, vdev-initramfs_1.2.7

fsmithred



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

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Arnt Karlsen]

On Mon, 24 Apr 2017 05:18:32 -0400, fsmithred wrote in message 
:

> On 04/23/2017 07:13 PM, Arnt Karlsen wrote:
> > On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message 
> > <20170419185407.228cd...@nb6.lan>:
> > 
> >> On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message 
> >> :
> >>
> >>>
> >>>
> >>> Arnt Karlsen wrote on 19/04/17 23:17:
> >>> [cut]
> 
>  ...wiped udev off my box and wound up with a box that boots oh
>  soo fine until it tries to load my new vdev
>  initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try
>  this on a rt kernel?
> 
>  ..recovery ideas?  Do we have any vdev live-cd?
> 
>  ..last time I did this stunt, I chrooted in off a Knoppix? iso,
>  I have memdisk and a few iso links handy in /boot, and Debian's
>  Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
>  vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
>  depend on a working install of udev AFAIK, and I'd prefer pushing
>  thru with vdev rather than going back to udev.
> 
>  ..has anyone here tried downgrading to Debian Wheezy era udev?
> 
> 
>  ..looking for recovery live-cd idea starting points, I came
>  across 32-bit
>  https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
>  which could work both as a starting point for a live-cd and as a
>  starting point for an upgrade path for stuck Debian Wheezy people
>  via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.
> 
>  ..according to https://debiandog.github.io/doglinux/ "DebianDog
>  is very small Debian Live CD shaped to look and act like Puppy
>  Linux. Debian structure and Debian behaviour are untouched and
>  Debian documentation is 100% valid for DebianDog. You have
>  access to all debian repositories using apt-get or synaptic.",
>  creating "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their
>  repos for ours, update, upgrade and remaster, the 64-bit version
>  likely needs to be built off deb-src lines.
> 
> 
>  ..but first comes the classic chicken-and-egg 64 bit recovery
>  I need now. ;o)
> 
> >>>
> >>> I'm not sure it helps you, but I've made a vdev variant of most
> >>> recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
> >>> 2017-Mar-27 20:57) that I got from the official mirror
> >>> http://mirror.sfo12.us.leaseweb.net/devuan/
> >>>
> >>> I purged a couple of things from it, then added and installed
> >>> "my" vdev_0.1.1_amd64.deb, and made a refractasnapshot of this,
> >>> into devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is
> >>> downloadable at https://www.uk.realsam.co.uk/files/devuan/
> >>>
> >>> It boots with vdev rather than udev, and udev remains installed,
> >>> though with all its "competing" files tucked away. As you might
> >>> know, this vdev packaging is different from aitor's packaging for
> >>> gnuinos by not declaring a udev competition, but rather attempting
> >>> to manage a dynamic choice of which one is in use. The software is
> >>> otherwise the same, I believe.
> >>
> >> ..thanks, we shall find out. ;o)
> > 
> > ..no joy this far, vdev does not work with any of my installed
> > kernels, neither my dpkg variant of your vdev-assistant nor your
> > original restores udev, so I'm stuck with live-CDs when I need to
> > go online to chk things to read up on.
> > 
> > ..you packaged your vdev differently than aitor, do I then use 
> > your deb(-src) lines in /etc/apt/sources.list and comment out 
> > his?
> > 
> > ..another approach is ignore apt and dpkg, and simply drop in all 
> > files with tar or cpio or somesuch, haven't done that kinda stunt 
> > since my RH-5.2 days.
> > 
> > ..if that fails, are you able to build me an old fashion monster
> > monolithic kernel with nouveau, vdev and everything else compiled 
> > into the kernel, and not as modules, that I can boot without an
> > initrd?  
> > Big size is no problem, I have 8GB ram, but no build box.
> > 
> > ..if not, what do I need to build a vdev kernel myself on my 
> > box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?
> > 
> > 
> 
> I don't know if this would be of any help to you, but I have a vdev
> live iso that I made using Ralph's vdev packages back in October.
> After reading this thread, I decided to install it and upgrade to the
> 4.9rt kernel. It boots normally.
> 
> What I can't seem to do is make a bootable iso with the 4.9rt, even
> after upgrading live-boot, et. al. to the ascii versions. (There's a
> problem with the bpo versions of live-boot missing some parts in the
> initrd related to overlayfs and nls_ascii).
> 
> If you want to try the October live iso, let me know.

..yup, url?

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets 

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[fsmithred]

On 04/23/2017 07:13 PM, Arnt Karlsen wrote:
> On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message 
> <20170419185407.228cd...@nb6.lan>:
> 
>> On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message 
>> :
>>
>>>
>>>
>>> Arnt Karlsen wrote on 19/04/17 23:17:
>>> [cut]

 ...wiped udev off my box and wound up with a box that boots oh soo
 fine until it tries to load my new vdev
 initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try this
 on a rt kernel?

 ..recovery ideas?  Do we have any vdev live-cd?

 ..last time I did this stunt, I chrooted in off a Knoppix? iso,
 I have memdisk and a few iso links handy in /boot, and Debian's
 Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
 vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
 depend on a working install of udev AFAIK, and I'd prefer pushing
 thru with vdev rather than going back to udev.

 ..has anyone here tried downgrading to Debian Wheezy era udev?


 ..looking for recovery live-cd idea starting points, I came across
 32-bit
 https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
 which could work both as a starting point for a live-cd and as a
 starting point for an upgrade path for stuck Debian Wheezy people
 via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.

 ..according to https://debiandog.github.io/doglinux/ "DebianDog is
 very small Debian Live CD shaped to look and act like Puppy Linux.
 Debian structure and Debian behaviour are untouched and Debian
 documentation is 100% valid for DebianDog. You have access to all
 debian repositories using apt-get or synaptic.", creating
 "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their repos for
 ours, update, upgrade and remaster, the 64-bit version likely
 needs to be built off deb-src lines.


 ..but first comes the classic chicken-and-egg 64 bit recovery
 I need now. ;o)

>>>
>>> I'm not sure it helps you, but I've made a vdev variant of most
>>> recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
>>> 2017-Mar-27 20:57) that I got from the official mirror
>>> http://mirror.sfo12.us.leaseweb.net/devuan/
>>>
>>> I purged a couple of things from it, then added and installed "my" 
>>> vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into
>>> devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is downloadable
>>> at https://www.uk.realsam.co.uk/files/devuan/
>>>
>>> It boots with vdev rather than udev, and udev remains installed,
>>> though with all its "competing" files tucked away. As you might
>>> know, this vdev packaging is different from aitor's packaging for
>>> gnuinos by not declaring a udev competition, but rather attempting
>>> to manage a dynamic choice of which one is in use. The software is
>>> otherwise the same, I believe.
>>
>> ..thanks, we shall find out. ;o)
> 
> ..no joy this far, vdev does not work with any of my installed kernels,
> neither my dpkg variant of your vdev-assistant nor your original
> restores udev, so I'm stuck with live-CDs when I need to go online to
> chk things to read up on.
> 
> ..you packaged your vdev differently than aitor, do I then use 
> your deb(-src) lines in /etc/apt/sources.list and comment out 
> his?
> 
> ..another approach is ignore apt and dpkg, and simply drop in all 
> files with tar or cpio or somesuch, haven't done that kinda stunt 
> since my RH-5.2 days.
> 
> ..if that fails, are you able to build me an old fashion monster
> monolithic kernel with nouveau, vdev and everything else compiled 
> into the kernel, and not as modules, that I can boot without an
> initrd?  
> Big size is no problem, I have 8GB ram, but no build box.
> 
> ..if not, what do I need to build a vdev kernel myself on my 
> box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?
> 
> 

I don't know if this would be of any help to you, but I have a vdev live
iso that I made using Ralph's vdev packages back in October. After reading
this thread, I decided to install it and upgrade to the 4.9rt kernel. It
boots normally.

What I can't seem to do is make a bootable iso with the 4.9rt, even after
upgrading live-boot, et. al. to the ascii versions. (There's a problem
with the bpo versions of live-boot missing some parts in the initrd
related to overlayfs and nls_ascii).

If you want to try the October live iso, let me know.

-fsmithred

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

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Ralph Ronnquist]

Arnt Karlsen wrote on 24/04/17 09:13:

On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message
<20170419185407.228cd...@nb6.lan>:


On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message
:




Arnt Karlsen wrote on 19/04/17 23:17:
[cut]


...wiped udev off my box and wound up with a box that boots oh soo
fine until it tries to load my new vdev
initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try this
on a rt kernel?

..recovery ideas?  Do we have any vdev live-cd?

..last time I did this stunt, I chrooted in off a Knoppix? iso,
I have memdisk and a few iso links handy in /boot, and Debian's
Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
depend on a working install of udev AFAIK, and I'd prefer pushing
thru with vdev rather than going back to udev.

..has anyone here tried downgrading to Debian Wheezy era udev?


..looking for recovery live-cd idea starting points, I came across
32-bit
https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
which could work both as a starting point for a live-cd and as a
starting point for an upgrade path for stuck Debian Wheezy people
via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.

..according to https://debiandog.github.io/doglinux/ "DebianDog is
very small Debian Live CD shaped to look and act like Puppy Linux.
Debian structure and Debian behaviour are untouched and Debian
documentation is 100% valid for DebianDog. You have access to all
debian repositories using apt-get or synaptic.", creating
"Devuan-0.x Wheezy Live-CD" etc is trivial, toss their repos for
ours, update, upgrade and remaster, the 64-bit version likely
needs to be built off deb-src lines.


..but first comes the classic chicken-and-egg 64 bit recovery
I need now. ;o)



I'm not sure it helps you, but I've made a vdev variant of most
recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
2017-Mar-27 20:57) that I got from the official mirror
http://mirror.sfo12.us.leaseweb.net/devuan/

I purged a couple of things from it, then added and installed "my"
vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into
devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is downloadable
at https://www.uk.realsam.co.uk/files/devuan/

It boots with vdev rather than udev, and udev remains installed,
though with all its "competing" files tucked away. As you might
know, this vdev packaging is different from aitor's packaging for
gnuinos by not declaring a udev competition, but rather attempting
to manage a dynamic choice of which one is in use. The software is
otherwise the same, I believe.


..thanks, we shall find out. ;o)


..no joy this far, vdev does not work with any of my installed kernels,
neither my dpkg variant of your vdev-assistant nor your original
restores udev, so I'm stuck with live-CDs when I need to go online to
chk things to read up on.

..you packaged your vdev differently than aitor, do I then use
your deb(-src) lines in /etc/apt/sources.list and comment out
his?

..another approach is ignore apt and dpkg, and simply drop in all
files with tar or cpio or somesuch, haven't done that kinda stunt
since my RH-5.2 days.

..if that fails, are you able to build me an old fashion monster
monolithic kernel with nouveau, vdev and everything else compiled
into the kernel, and not as modules, that I can boot without an
initrd?
Big size is no problem, I have 8GB ram, but no build box.

..if not, what do I need to build a vdev kernel myself on my
box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?


If the live iso works, you can restore udev via chroot to your root file 
system. It's a relatively simple sequence:

# mnt /dev/sdaX /mnt
# chroot /mnt
# mount -t proc none proc
# mount -t sysfs none /sys
# mount -t devpts none /dev/pts
# apt-get install udev
# apt-get purge *vdev*   <-- all aitor's vdev packages
# apt-get install --reinstall udev
# exit

The end result of that should be that udev is reinstalled to the 
/dev/sdaX root file system, including the update of its initramfs. And 
that your system boots up without fuss. (hopefully)


If then you wish to try vdev again, it is available in "experimental"; 
that's "my" variant. You need to have the experimental entry in 
sources.list, and perhaps a -1 pinning of it in the preferences (to 
avoid gaining other experimental babies), and then use explicit "-t 
experimental" to get it.

# apt-get install -t experimental vdev

You might also want to consider using eudev instead, which (like aitor's 
vdev packaging) is a full replacement for udev. (afaik 'eudev' makes use 
of the udev rules, and in that way it's much friendlier to other 
products that currently tie in to udev)


All in all, there is nothing needed to be compiled into the kernel for 
vdev or udev (or eudev I think). But if you can't come forward, there is 
also the option of hand crafting an initrd enough to get the system 

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Arnt Karlsen]

On Wed, 19 Apr 2017 18:54:07 +0200, Arnt wrote in message 
<20170419185407.228cd...@nb6.lan>:

> On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message 
> :
> 
> > 
> > 
> > Arnt Karlsen wrote on 19/04/17 23:17:
> > [cut]
> > >
> > > ...wiped udev off my box and wound up with a box that boots oh soo
> > > fine until it tries to load my new vdev
> > > initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try this
> > > on a rt kernel?
> > >
> > > ..recovery ideas?  Do we have any vdev live-cd?
> > >
> > > ..last time I did this stunt, I chrooted in off a Knoppix? iso,
> > > I have memdisk and a few iso links handy in /boot, and Debian's
> > > Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
> > > vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
> > > depend on a working install of udev AFAIK, and I'd prefer pushing
> > > thru with vdev rather than going back to udev.
> > >
> > > ..has anyone here tried downgrading to Debian Wheezy era udev?
> > >
> > >
> > > ..looking for recovery live-cd idea starting points, I came across
> > > 32-bit
> > > https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
> > > which could work both as a starting point for a live-cd and as a
> > > starting point for an upgrade path for stuck Debian Wheezy people
> > > via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.
> > >
> > > ..according to https://debiandog.github.io/doglinux/ "DebianDog is
> > > very small Debian Live CD shaped to look and act like Puppy Linux.
> > > Debian structure and Debian behaviour are untouched and Debian
> > > documentation is 100% valid for DebianDog. You have access to all
> > > debian repositories using apt-get or synaptic.", creating
> > > "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their repos for
> > > ours, update, upgrade and remaster, the 64-bit version likely
> > > needs to be built off deb-src lines.
> > >
> > >
> > > ..but first comes the classic chicken-and-egg 64 bit recovery
> > > I need now. ;o)
> > >
> > 
> > I'm not sure it helps you, but I've made a vdev variant of most
> > recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
> > 2017-Mar-27 20:57) that I got from the official mirror
> > http://mirror.sfo12.us.leaseweb.net/devuan/
> > 
> > I purged a couple of things from it, then added and installed "my" 
> > vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into
> > devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is downloadable
> > at https://www.uk.realsam.co.uk/files/devuan/
> > 
> > It boots with vdev rather than udev, and udev remains installed,
> > though with all its "competing" files tucked away. As you might
> > know, this vdev packaging is different from aitor's packaging for
> > gnuinos by not declaring a udev competition, but rather attempting
> > to manage a dynamic choice of which one is in use. The software is
> > otherwise the same, I believe.
> 
> ..thanks, we shall find out. ;o)

..no joy this far, vdev does not work with any of my installed kernels,
neither my dpkg variant of your vdev-assistant nor your original
restores udev, so I'm stuck with live-CDs when I need to go online to
chk things to read up on.

..you packaged your vdev differently than aitor, do I then use 
your deb(-src) lines in /etc/apt/sources.list and comment out 
his?

..another approach is ignore apt and dpkg, and simply drop in all 
files with tar or cpio or somesuch, haven't done that kinda stunt 
since my RH-5.2 days.

..if that fails, are you able to build me an old fashion monster
monolithic kernel with nouveau, vdev and everything else compiled 
into the kernel, and not as modules, that I can boot without an
initrd?  
Big size is no problem, I have 8GB ram, but no build box.

..if not, what do I need to build a vdev kernel myself on my 
box running your devuan_jessie_RC_amd64_minimal_live_vdev.iso?


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[KatolaZ]

On Wed, Apr 19, 2017 at 11:37:32PM +0200, Arnt Karlsen wrote:

[cut]

> 
> ..what nasty command line tricks do I use to get online with
> devuan_jessie_RC_amd64_minimal_live_vdev.iso? 
> (Ideally wifi, but eth0 will work.) 
> 


Hi Arnt,

if it comes from a minimal-live RC, you have setnet in there. Just run:

 # setnet.sh

It also has a manpage, but simple comfiguration should be pretty
straightforward. Any feedback is welcome. 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Arnt Karlsen]

On Thu, 20 Apr 2017 02:21:53 +1000, Ralph wrote in message 
:

> 
> 
> Arnt Karlsen wrote on 19/04/17 23:17:
> [cut]
> >
> > ...wiped udev off my box and wound up with a box that boots oh soo
> > fine until it tries to load my new vdev
> > initrd.img-4.9.0-2-rt-amd64 ...am I the first one here to try this
> > on a rt kernel?
> >
> > ..recovery ideas?  Do we have any vdev live-cd?
> >
> > ..last time I did this stunt, I chrooted in off a Knoppix? iso,
> > I have memdisk and a few iso links handy in /boot, and Debian's
> > Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
> > vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
> > depend on a working install of udev AFAIK, and I'd prefer pushing
> > thru with vdev rather than going back to udev.
> >
> > ..has anyone here tried downgrading to Debian Wheezy era udev?
> >
> >
> > ..looking for recovery live-cd idea starting points, I came across
> > 32-bit https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
> > which could work both as a starting point for a live-cd and as a
> > starting point for an upgrade path for stuck Debian Wheezy people
> > via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.
> >
> > ..according to https://debiandog.github.io/doglinux/ "DebianDog is
> > very small Debian Live CD shaped to look and act like Puppy Linux.
> > Debian structure and Debian behaviour are untouched and Debian
> > documentation is 100% valid for DebianDog. You have access to all
> > debian repositories using apt-get or synaptic.", creating
> > "Devuan-0.x Wheezy Live-CD" etc is trivial, toss their repos for
> > ours, update, upgrade and remaster, the 64-bit version likely needs
> > to be built off deb-src lines.
> >
> >
> > ..but first comes the classic chicken-and-egg 64 bit recovery
> > I need now. ;o)
> >
> 
> I'm not sure it helps you, but I've made a vdev variant of most
> recent devuan_jessie_RC_amd64_minimal_live.iso (time stamped
> 2017-Mar-27 20:57) that I got from the official mirror
> http://mirror.sfo12.us.leaseweb.net/devuan/
> 
> I purged a couple of things from it, then added and installed "my" 
> vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into
> devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is downloadable at
> https://www.uk.realsam.co.uk/files/devuan/
> 
> It boots with vdev rather than udev, and udev remains installed,
> though with all its "competing" files tucked away. As you might know,
> this vdev packaging is different from aitor's packaging for gnuinos
> by not declaring a udev competition, but rather attempting to manage
> a dynamic choice of which one is in use. The software is otherwise
> the same, I believe.

..thanks, we shall find out. ;o)


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..vdev box recovery ideas?, was: gvfs depends on libsystemd0

[Ralph Ronnquist]

Arnt Karlsen wrote on 19/04/17 23:17:
[cut]


...wiped udev off my box and wound up with a box that boots oh soo fine
until it tries to load my new vdev initrd.img-4.9.0-2-rt-amd64 ...am I
the first one here to try this on a rt kernel?

..recovery ideas?  Do we have any vdev live-cd?

..last time I did this stunt, I chrooted in off a Knoppix? iso,
I have memdisk and a few iso links handy in /boot, and Debian's
Sid vmlinuz-4.8.0-2-amd64, vmlinuz-4.8.0-2-rt-amd64 and
vmlinuz-4.9.0-1-rt-amd64 with systemd-udev initrd's, but they all
depend on a working install of udev AFAIK, and I'd prefer pushing
thru with vdev rather than going back to udev.

..has anyone here tried downgrading to Debian Wheezy era udev?


..looking for recovery live-cd idea starting points, I came across
32-bit https://debiandog.github.io/doglinux/zz02debiandogwheezy.html
which could work both as a starting point for a live-cd and as a
starting point for an upgrade path for stuck Debian Wheezy people
via "Devuan-0.x Wheezy" to current Devuan-1.x Jessie.

..according to https://debiandog.github.io/doglinux/ "DebianDog is very
small Debian Live CD shaped to look and act like Puppy Linux. Debian
structure and Debian behaviour are untouched and Debian documentation
is 100% valid for DebianDog. You have access to all debian repositories
using apt-get or synaptic.", creating "Devuan-0.x Wheezy Live-CD" etc
is trivial, toss their repos for ours, update, upgrade and remaster,
the 64-bit version likely needs to be built off deb-src lines.


..but first comes the classic chicken-and-egg 64 bit recovery
I need now. ;o)



I'm not sure it helps you, but I've made a vdev variant of most recent 
devuan_jessie_RC_amd64_minimal_live.iso (time stamped 2017-Mar-27 20:57) 
that I got from the official mirror

http://mirror.sfo12.us.leaseweb.net/devuan/

I purged a couple of things from it, then added and installed "my" 
vdev_0.1.1_amd64.deb, and made a refractasnapshot of this, into

devuan_jessie_RC_amd64_minimal_live_vdev.iso, which is downloadable at
https://www.uk.realsam.co.uk/files/devuan/

It boots with vdev rather than udev, and udev remains installed, though 
with all its "competing" files tucked away. As you might know, this vdev 
packaging is different from aitor's packaging for gnuinos by not 
declaring a udev competition, but rather attempting to manage a dynamic 
choice of which one is in use. The software is otherwise the same, I 
believe.


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

Re: [DNG] vdev packaging status (was eudev status)

[Ralph Ronnquist]

Eeh, the vdev package is now moved to 
https://git.devuan.org/devuan-packages/vdev


Sorry about my confusion

Ralph.

Ralph Ronnquist wrote on 2017-01-17 18:48:

Note, I've *removed the release directory* from gitlab, as I figured it
is for keeping only the source rather. But, in a rather near future, the
vdev packages should be available in "unstable". Meanwhile, don't
hesitate to grab the sources from
https://git.devuan.org/ralph.ronnquist/vdev for yourself.

Ralph.

Ralph Ronnquist wrote on 2017-01-16 14:00:

Guided by this and other good emailed feedback, I've updated the code
slightly, and made a new build for amd64, plus added the source bundles
to the release area. As far as I remember, there's no change to
function, apart from some very slight polishing to the "action" files.
The source is however restructured, and I've added the debian packaging
files.

At: https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

regards,

Ralph.

Anto wrote on 2017-01-09 01:52:


On 06/01/17 05:57, Ralph Ronnquist wrote:

The devuan/debian packaging of vdev is so far only in "my" repository.
But I've only fitted it out with the packaging files that differ from
the "defaults", as generated by "dh_make -a". Please look at the make
file "debian.mk" for specifics.

I also started on a habit to build it all in a firejail overlay so as
to not pollute my workspace; the bottom of the top level Makefile
gives the hint to that. Though, I'm happy to learn and change to "the
proper way". My forward plan is to merge "my" repository into
"unsystemd", and then also adapt it to fit into the automagic build
process.

I suppose I should also (learn how to) make the source packages; (this
might require some changes to the source structure, since as it
stands, the various "vdev packages" get composed by cherry picking in
the build tree. It could be cleaner)

Anyhow, at the moment, in "ralph.ronnquist/vdev" you find three
"debian" sub directories for building three packages: "vdevd",
"libudev1-compat" and "vdev-initramfs". These directories contain only
the non-default packaging files, while the rest are as generated by
"dh_make -a".

Ralph.



Thanks Ralph,

It took me months to build my own debian packaging files for eudev and
try the available ones on https://git.devuan.org/unsystemd/devuan-eudev
and https://git.devuan.org/pkgs-utopia-substitution/devuan-eudev (this
one has been deleted) *without success*, until Jaret uploaded his on
https://git.devuan.org/jaretcantu/eudev. Even if I got eudev package
successfully compiled, I had other issues like the issues with initramfs
hook.

So I don't want to repeat that for vdev and I think I will just wait for
a complete vdev source package with debian packaging files, to try to
compile and test it.

Cheers,

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




--
Chief Scientist
Realthing Entertainment Pty Ltd
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging status (was eudev status)

[Ralph Ronnquist]

Note, I've *removed the release directory* from gitlab, as I figured it 
is for keeping only the source rather. But, in a rather near future, the 
vdev packages should be available in "unstable". Meanwhile, don't 
hesitate to grab the sources from 
https://git.devuan.org/ralph.ronnquist/vdev for yourself.


Ralph.

Ralph Ronnquist wrote on 2017-01-16 14:00:

Guided by this and other good emailed feedback, I've updated the code
slightly, and made a new build for amd64, plus added the source bundles
to the release area. As far as I remember, there's no change to
function, apart from some very slight polishing to the "action" files.
The source is however restructured, and I've added the debian packaging
files.

At: https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

regards,

Ralph.

Anto wrote on 2017-01-09 01:52:


On 06/01/17 05:57, Ralph Ronnquist wrote:

The devuan/debian packaging of vdev is so far only in "my" repository.
But I've only fitted it out with the packaging files that differ from
the "defaults", as generated by "dh_make -a". Please look at the make
file "debian.mk" for specifics.

I also started on a habit to build it all in a firejail overlay so as
to not pollute my workspace; the bottom of the top level Makefile
gives the hint to that. Though, I'm happy to learn and change to "the
proper way". My forward plan is to merge "my" repository into
"unsystemd", and then also adapt it to fit into the automagic build
process.

I suppose I should also (learn how to) make the source packages; (this
might require some changes to the source structure, since as it
stands, the various "vdev packages" get composed by cherry picking in
the build tree. It could be cleaner)

Anyhow, at the moment, in "ralph.ronnquist/vdev" you find three
"debian" sub directories for building three packages: "vdevd",
"libudev1-compat" and "vdev-initramfs". These directories contain only
the non-default packaging files, while the rest are as generated by
"dh_make -a".

Ralph.



Thanks Ralph,

It took me months to build my own debian packaging files for eudev and
try the available ones on https://git.devuan.org/unsystemd/devuan-eudev
and https://git.devuan.org/pkgs-utopia-substitution/devuan-eudev (this
one has been deleted) *without success*, until Jaret uploaded his on
https://git.devuan.org/jaretcantu/eudev. Even if I got eudev package
successfully compiled, I had other issues like the issues with initramfs
hook.

So I don't want to repeat that for vdev and I think I will just wait for
a complete vdev source package with debian packaging files, to try to
compile and test it.

Cheers,

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


--
Chief Scientist
Realthing Entertainment Pty Ltd
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging status (was eudev status)

[Ralph Ronnquist]

Guided by this and other good emailed feedback, I've updated the code 
slightly, and made a new build for amd64, plus added the source bundles 
to the release area. As far as I remember, there's no change to 
function, apart from some very slight polishing to the "action" files. 
The source is however restructured, and I've added the debian packaging 
files.


At: https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

regards,

Ralph.

Anto wrote on 2017-01-09 01:52:


On 06/01/17 05:57, Ralph Ronnquist wrote:

The devuan/debian packaging of vdev is so far only in "my" repository.
But I've only fitted it out with the packaging files that differ from
the "defaults", as generated by "dh_make -a". Please look at the make
file "debian.mk" for specifics.

I also started on a habit to build it all in a firejail overlay so as
to not pollute my workspace; the bottom of the top level Makefile
gives the hint to that. Though, I'm happy to learn and change to "the
proper way". My forward plan is to merge "my" repository into
"unsystemd", and then also adapt it to fit into the automagic build
process.

I suppose I should also (learn how to) make the source packages; (this
might require some changes to the source structure, since as it
stands, the various "vdev packages" get composed by cherry picking in
the build tree. It could be cleaner)

Anyhow, at the moment, in "ralph.ronnquist/vdev" you find three
"debian" sub directories for building three packages: "vdevd",
"libudev1-compat" and "vdev-initramfs". These directories contain only
the non-default packaging files, while the rest are as generated by
"dh_make -a".

Ralph.



Thanks Ralph,

It took me months to build my own debian packaging files for eudev and
try the available ones on https://git.devuan.org/unsystemd/devuan-eudev
and https://git.devuan.org/pkgs-utopia-substitution/devuan-eudev (this
one has been deleted) *without success*, until Jaret uploaded his on
https://git.devuan.org/jaretcantu/eudev. Even if I got eudev package
successfully compiled, I had other issues like the issues with initramfs
hook.

So I don't want to repeat that for vdev and I think I will just wait for
a complete vdev source package with debian packaging files, to try to
compile and test it.

Cheers,

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

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

Re: [DNG] vdev packaging status (was eudev status)

[aitor_czr]

Hi anto,

On 01/09/2017 08:32 AM, Anto wrote:


Thanks Aitor,

I think I will just use your debian packaging files of vdev from 
http://packages.gnuinos.org/unsystemd/pool/main/v/vdev/vdev_20161228-jessie1.debian.tar.xz. 



And looking at the control file of vdev inside that tar file, I also 
need to compile and install libfskit-dev and libfskit-fuse-dev (which 
I assume) from https://github.com/jcnelson/fskit and libpstat-dev from 
https://github.com/jcnelson/libpstat.


That's right, they are needed for the frontend filesystem vdevfs.

For the latter one, I think I will also use your debian packaging 
files on 
http://packages.gnuinos.org/unsystemd/pool/main/libp/libpstat/libpstat_0.1-20160326-jessie1.debian.tar.xz. 
Let's see how it goes.


The only non-technical issue that I see is that, there is no version 
of vdev set on its source code. I know that I can set it to any 
version, but it would be great if we could have it on the source code.


In a previous version, i used the date of Jude Nelson's latest commit, 
but keep in mind that some changes have been done since then. Basically 
Ralph's manpages and some changes in the Makefile of libudev1-compat too.


I think I will just set the vdev version to the same version as fskit 
and libpstat, i.e. version 1.0.2.


Cheers,

Ant


That would be a good idea.

Cheers,

  Aitor.




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

Re: [DNG] vdev packaging status (was eudev status)

[Anto]

On 08/01/17 20:09, aitor_czr wrote:


Hi Anto,


On 01/08/2017 04:02 PM, Anto wrote:



[snip]...

Thanks Aitor,

I am actually looking for vdev source package which includes its 
debian packaging files. Your repository does not seem to have the 
source package of vdev as below.


Yes, it has:

http://packages.gnuinos.org/unsystemd/pool/main/v/vdev/



[snip]...
After that, install the vdev-assistant package and run: # 
vdev-assistant dialog Cheers, and good luck :) Aitor. * NOTE * .- The 
current version of live-boot isn't compatible with vdev; so, if it's 
present in your system, remove it before installing vdev. Remove also 
any previous residue of vdev, whether coming from my repository or 
from Ralph's repository, in order to avoid any possible 
incompatibility between them.


Thanks Aitor,

I think I will just use your debian packaging files of vdev from 
http://packages.gnuinos.org/unsystemd/pool/main/v/vdev/vdev_20161228-jessie1.debian.tar.xz.


And looking at the control file of vdev inside that tar file, I also 
need to compile and install libfskit-dev and libfskit-fuse-dev (which I 
assume) from https://github.com/jcnelson/fskit and libpstat-dev from 
https://github.com/jcnelson/libpstat. For the latter one, I think I will 
also use your debian packaging files on 
http://packages.gnuinos.org/unsystemd/pool/main/libp/libpstat/libpstat_0.1-20160326-jessie1.debian.tar.xz. 
Let's see how it goes.


The only non-technical issue that I see is that, there is no version of 
vdev set on its source code. I know that I can set it to any version, 
but it would be great if we could have it on the source code. I think I 
will just set the vdev version to the same version as fskit and 
libpstat, i.e. version 1.0.2.


Cheers,

Anto

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

Re: [DNG] vdev packaging status (was eudev status)

[aitor_czr]

Hi Anto,


On 01/08/2017 04:02 PM, Anto wrote:


On 08/01/17 02:33, aitor_czr wrote:


Hi Anto,


[snip]...
deb http://packages.gnuinos.org/unsystemd jessie main 



But use it at your own risk :)

I recommend you to separate the " / " partition from the " / home " 
partition, so far as you can always restore the first one, without 
affecting to the second one, in the case of an incidence.



[snip]...


HTH,

  Aitor.




Thanks Aitor,

I am actually looking for vdev source package which includes its 
debian packaging files. Your repository does not seem to have the 
source package of vdev as below.


Yes, it has:

http://packages.gnuinos.org/unsystemd/pool/main/v/vdev/


Or perhaps that was due to there is no valid public PGP key. I am not 
sure.


Cheers,

Anto

.
.
Reading package lists... Done
W: GPG error: http://packages.gnuinos.org jessie InRelease: The 
following signatures couldn't be verified because the public key is 
not available: NO_PUBKEY 9C242C3D64CF1949

root@hp8530w:~#
root@hp8530w:~# gpg --recv-keys 9C242C3D64CF1949
gpg: requesting key 64CF1949 from hkp server keys.gnupg.net
gpgkeys: key 9C242C3D64CF1949 not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
root@hp8530w:~#
root@hp8530w:~# apt-get install --simulate vdev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libudev1-compat rpl
Recommended packages:
  libvdev-hwdb
The following NEW packages will be installed:
  libudev1-compat rpl vdev
0 upgraded, 3 newly installed, 0 to remove and 2 not upgraded.
Inst libudev1-compat (20161228-jessie1 Devuan Jessie packages:stable 
[amd64])

Inst rpl (1.5.5-1 Devuan:1.0/stable [all])
Inst vdev (20161228-jessie1 Devuan Jessie packages:stable [amd64])
Conf libudev1-compat (20161228-jessie1 Devuan Jessie packages:stable 
[amd64])

Conf rpl (1.5.5-1 Devuan:1.0/stable [all])
Conf vdev (20161228-jessie1 Devuan Jessie packages:stable [amd64])
root@hp8530w:~#
root@hp8530w:~# apt-get source vdev
Reading package lists... Done
Building dependency tree
Reading state information... Done
WARNING: The following packages cannot be authenticated!
  vdev
E: Some packages could not be authenticated
root@hp8530w:~#


This is a gpg-keyring issue. Install the gpg key following the 
indications on the website, that is:


# curl http://packages.gnuinos.org/gnuinos_pk.asc | apt-key add - After 
that, install the vdev-assistant package and run: # vdev-assistant 
dialog Cheers, and good luck :) Aitor. * NOTE * .- The current version 
of live-boot isn't compatible with vdev; so, if it's present in your 
system, remove it before installing vdev. Remove also any previous 
residue of vdev, whether coming from my repository or from Ralph's 
repository, in order to avoid any possible incompatibility between them.


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

Re: [DNG] vdev packaging status (was eudev status)

[Anto]

On 08/01/17 02:33, aitor_czr wrote:


Hi Anto,


[snip]...
deb http://packages.gnuinos.org/unsystemd jessie main 



But use it at your own risk :)

I recommend you to separate the " / " partition from the " / home " 
partition, so far as you can always restore the first one, without 
affecting to the second one, in the case of an incidence.



[snip]...


HTH,

  Aitor.




Thanks Aitor,

I am actually looking for vdev source package which includes its debian 
packaging files. Your repository does not seem to have the source 
package of vdev as below. Or perhaps that was due to there is no valid 
public PGP key. I am not sure.


Cheers,

Anto

.
.
Reading package lists... Done
W: GPG error: http://packages.gnuinos.org jessie InRelease: The 
following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 9C242C3D64CF1949

root@hp8530w:~#
root@hp8530w:~# gpg --recv-keys 9C242C3D64CF1949
gpg: requesting key 64CF1949 from hkp server keys.gnupg.net
gpgkeys: key 9C242C3D64CF1949 not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
root@hp8530w:~#
root@hp8530w:~# apt-get install --simulate vdev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libudev1-compat rpl
Recommended packages:
  libvdev-hwdb
The following NEW packages will be installed:
  libudev1-compat rpl vdev
0 upgraded, 3 newly installed, 0 to remove and 2 not upgraded.
Inst libudev1-compat (20161228-jessie1 Devuan Jessie packages:stable 
[amd64])

Inst rpl (1.5.5-1 Devuan:1.0/stable [all])
Inst vdev (20161228-jessie1 Devuan Jessie packages:stable [amd64])
Conf libudev1-compat (20161228-jessie1 Devuan Jessie packages:stable 
[amd64])

Conf rpl (1.5.5-1 Devuan:1.0/stable [all])
Conf vdev (20161228-jessie1 Devuan Jessie packages:stable [amd64])
root@hp8530w:~#
root@hp8530w:~# apt-get source vdev
Reading package lists... Done
Building dependency tree
Reading state information... Done
WARNING: The following packages cannot be authenticated!
  vdev
E: Some packages could not be authenticated
root@hp8530w:~#
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging status (was eudev status)

[Anto]

On 06/01/17 05:57, Ralph Ronnquist wrote:
The devuan/debian packaging of vdev is so far only in "my" repository. 
But I've only fitted it out with the packaging files that differ from 
the "defaults", as generated by "dh_make -a". Please look at the make 
file "debian.mk" for specifics.


I also started on a habit to build it all in a firejail overlay so as 
to not pollute my workspace; the bottom of the top level Makefile 
gives the hint to that. Though, I'm happy to learn and change to "the 
proper way". My forward plan is to merge "my" repository into 
"unsystemd", and then also adapt it to fit into the automagic build 
process.


I suppose I should also (learn how to) make the source packages; (this 
might require some changes to the source structure, since as it 
stands, the various "vdev packages" get composed by cherry picking in 
the build tree. It could be cleaner)


Anyhow, at the moment, in "ralph.ronnquist/vdev" you find three 
"debian" sub directories for building three packages: "vdevd", 
"libudev1-compat" and "vdev-initramfs". These directories contain only 
the non-default packaging files, while the rest are as generated by 
"dh_make -a".


Ralph.



Thanks Ralph,

It took me months to build my own debian packaging files for eudev and 
try the available ones on https://git.devuan.org/unsystemd/devuan-eudev 
and https://git.devuan.org/pkgs-utopia-substitution/devuan-eudev (this 
one has been deleted) *without success*, until Jaret uploaded his on 
https://git.devuan.org/jaretcantu/eudev. Even if I got eudev package 
successfully compiled, I had other issues like the issues with initramfs 
hook.


So I don't want to repeat that for vdev and I think I will just wait for 
a complete vdev source package with debian packaging files, to try to 
compile and test it.


Cheers,

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

Re: [DNG] vdev packaging status (was eudev status)

[Ralph Ronnquist]

The devuan/debian packaging of vdev is so far only in "my" repository. 
But I've only fitted it out with the packaging files that differ from 
the "defaults", as generated by "dh_make -a". Please look at the make 
file "debian.mk" for specifics.


I also started on a habit to build it all in a firejail overlay so as to 
not pollute my workspace; the bottom of the top level Makefile gives the 
hint to that. Though, I'm happy to learn and change to "the proper way". 
My forward plan is to merge "my" repository into "unsystemd", and then 
also adapt it to fit into the automagic build process.


I suppose I should also (learn how to) make the source packages; (this 
might require some changes to the source structure, since as it stands, 
the various "vdev packages" get composed by cherry picking in the build 
tree. It could be cleaner)


Anyhow, at the moment, in "ralph.ronnquist/vdev" you find three "debian" 
sub directories for building three packages: "vdevd", "libudev1-compat" 
and "vdev-initramfs". These directories contain only the non-default 
packaging files, while the rest are as generated by "dh_make -a".


Ralph.

Anto wrote on 2017-01-05 00:39:

On 24/12/16 00:17, fsmithred wrote:

On 12/23/2016 05:42 PM, Rob Owens wrote:

On Thu, Dec 22, 2016 at 10:56:58AM -0500, Haines Brown wrote:

I installed jessie-beta on a disk some time ago, and off hand it boots
and runs just fine. However I didn't migrate it to from my current
Debian
Wheezy because I was waiting for the eudev/vdev/udev issue to be
resolved, figuring that migrating up from present udev to one of the
others could well be traumatic. I didn't want to do it on a system
on which I relied for work.

Two questions, if I may:

Is eudev being actively worked on, and is it likely to be in
the upcoming  non-beta Jessie Devuan?

vdev was/is being developed by a Devuan user specifically with Devuan in
mind.  eudev, as others have already stated, is a Gentoo project.  I'm
not sure the status of vdev.


It has been packaged, and it works. (i.e. It works for me and a few
others. If more people try it, then it will work for more people.)

Here are vdev packages made by Ralph Ronnquist:
https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

Here are vdev packages made by Aitor:
http://packages.gnuinos.org/pool/main/v/vdev/

I should add that the two sets of packages are probably not compatible
with each other. Pick one.

Here's a live-CD iso I made with a sparse devuan install with openbox wm
and...  vdev. I used Ralph's deb packages for this build, and I only made
an amd64 iso. It's already isohybrid, so you can dd or cat it to a usb
stick.
http://distro.ibiblio.org/refracta/files/experimental/jessie-vdev2-20161013_0159.iso


-fsmithred


Hello fsmithred and everybody,

As fas as I understood, a proper debian package must have the debian
packaging files, i.e. the debian directory and its files, so that people
can compile and test it on any supported platforms. So I don't believe
that vdev has been properly packaged so far as I cannot find any debian
packaging files either on
https://git.devuan.org/unsystemd/vdev/tree/master or
https://git.devuan.org/ralph.ronnquist/vdev/tree/master. Or perhaps I am
out of date on the packaging approach used in Devuan. But I believe
Devuan still follows the same packaging method as Debian.

For me, I will be more confident to install a package that has never
been packaged before, when I can successfully compile it under my
environment using dpkg-buildpackage. Especially for device manager
packages, I have to be very careful as the chances to break my PC is
quite high. At the first stage of vdev development, I always broke my
test PC until I decided to stop testing and just wait for a vdev package
with debian packaging files available.

So is there anywhere I can find the debian packaging files of vdev?

Thanks in advance.

Cheers,

Anto

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

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

Re: [DNG] vdev - the next generation

[aiitor_czr]

On 10/11/2016 02:00 PM, Ralph Ronnquist  wrote:

Good documentation is the next best thing.

Yes, i think so :)

  Aitor.


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

Re: [DNG] vdev - the next generation

[Ralph Ronnquist]

Ralph Ronnquist wrote on 09/10/16 10:54:

I've now uploaded a first beta, vdevd_2.0, that includes the mechanism
for dealing with (hand) compiled udev rules, and also includes the
scanner rules and modem mode switching rules


Working version is vdevd_2.0.2 ... for the moment

Now, in order for VDEV to be of use to us mere mortals, there needs to 
be better documentation. Although I like reading documentation, and know 
how to enjoy well-documented functionality, I'm not especially good at 
writing it. So this is a call for a technical writer, or anyone with 
comparable skills, to step forward and volunteer for the VDEV 
documentation page(s).


Presently there are a "man vdevd" page and a "man vdevd-actions" page. 
Neither is more than adequate, at best. Given the central function VDEV 
is supposed to take on, I think it needs to be quite well documented. 
Especially since any other function that wishes to include hotplugging 
aspects will need to integrate with it, and thus the developer(s) of 
that function will want straight-forward, to-the-point and accurate 
documentation.


In real life, I suppose they or we will want the push-button "my Udev 
rules" to "my Vdev rules" compiler, but that won't be available very 
immediately. Good documentation is the next best thing.


Also, though of lesser priority (in my mind), there's some drive towards 
end-user oriented documentation, since some end-user(s) may want to tie 
in their personal hotplug actions.


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

Re: [DNG] vdev - the next generation

[Ismael L. Donis Garcia]

- Original Message - 
From: "Ralph Ronnquist" <ralph.ronnqu...@gmail.com>
To: <Dng@lists.dyne.org>
Sent: Saturday, October 08, 2016 7:54 PM
Subject: Re: [DNG] vdev - the next generation


> I've now uploaded a first beta, vdevd_2.0, that includes the mechanism 
> for dealing with (hand) compiled udev rules, and also includes the 
> scanner rules and modem mode switching rules. The mechanism is just a 
> straight-forward (extended) use of the "hwdb" database, which already 
> was set up to hold properties keyed by device identification 
> (essentially vendor+product). So I added a helper that processes these 
> properties, and e.g, sets group ownership to "scanner" when the device 
> has the property "GROUP=scanner".
> 
> This only affects the vdevd package, which now is version 2.0, and 
> otherwise you'd use the latest libudev1-compat_1.2.1 and 
> vdev-initramfs_1.2_5.
> 
> If you are keen you should touch "/root/ralph.log", and then vdevd will 
> drop log pearls from the helper script "/lib/vdev/compiled.sh" into it 
> when devices are added. This particular feature will of course be 
> removed at 2.1.
> 
> With that mechanism and it's pre-seeding, vdevd is essentially ready, 
> and so is libudev1-compat (although I haven't really plunged into that 
> bath yet, so I don't know for sure).
> 
> However, vdev-initramfs still needs attention. At the moment it combines 
> initramfs building of vdev in competition with udev, and the set up for 
> sysvinit, also in competition with udev. (The latter of course only 
> makes sense where sysvinit is used, and maybe it should be separated 
> out. But then one would need two hands to manage the udev competition, 
> and it'd double (or more) the possible strange failure cases, and my 
> work load)
> 
> Note that the start/stop script in /etc/init.d/vdev still belongs to the 
> vdevd package, which thus also shows preference for sysvinit. But, if 
> you don't want vdevd in the initramfs (who does, really?) and/or have a 
> different init scheme, you should skip installing the vdev-initramfs 
> package, and with some manual blessing you'll easily get the vdevd magic 
> happening where you need it.
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

Thank you very much. Your work is dear for us all since it is vitally important.


| ISMAEL |

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

Re: [DNG] vdev - the next generation

[hal]

Ralph Ronnquist wrote on 10/08/2016 06:54 PM:

> With that mechanism and it's pre-seeding, vdevd is essentially ready, and so 
> is libudev1-compat (although I haven't really plunged into that bath yet, so 
> I don't know for sure).


Thanks so much for all your work on this!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - the next generation

[Ralph Ronnquist]

I've now uploaded a first beta, vdevd_2.0, that includes the mechanism 
for dealing with (hand) compiled udev rules, and also includes the 
scanner rules and modem mode switching rules. The mechanism is just a 
straight-forward (extended) use of the "hwdb" database, which already 
was set up to hold properties keyed by device identification 
(essentially vendor+product). So I added a helper that processes these 
properties, and e.g, sets group ownership to "scanner" when the device 
has the property "GROUP=scanner".


This only affects the vdevd package, which now is version 2.0, and 
otherwise you'd use the latest libudev1-compat_1.2.1 and 
vdev-initramfs_1.2_5.


If you are keen you should touch "/root/ralph.log", and then vdevd will 
drop log pearls from the helper script "/lib/vdev/compiled.sh" into it 
when devices are added. This particular feature will of course be 
removed at 2.1.


With that mechanism and it's pre-seeding, vdevd is essentially ready, 
and so is libudev1-compat (although I haven't really plunged into that 
bath yet, so I don't know for sure).


However, vdev-initramfs still needs attention. At the moment it combines 
initramfs building of vdev in competition with udev, and the set up for 
sysvinit, also in competition with udev. (The latter of course only 
makes sense where sysvinit is used, and maybe it should be separated 
out. But then one would need two hands to manage the udev competition, 
and it'd double (or more) the possible strange failure cases, and my 
work load)


Note that the start/stop script in /etc/init.d/vdev still belongs to the 
vdevd package, which thus also shows preference for sysvinit. But, if 
you don't want vdevd in the initramfs (who does, really?) and/or have a 
different init scheme, you should skip installing the vdev-initramfs 
package, and with some manual blessing you'll easily get the vdevd magic 
happening where you need it.


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

Re: [DNG] vdev - the next generation

[Robert Storey]

Just want to say Ralph that your work on this is really appreciated. I
consider vdev to be one of the most important projects going. I wish I was
more competent at development work, because I'd like to help with it. When
you get to scanner support, I'm going to definitely get more involved with
testing and reporting. I make heavy use of my scanner, so I can give it a
good workout.

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

Re: [DNG] vdev - scanner

[Dave Turner]

On 02/09/16 23:39, Ralph Ronnquist wrote:

Dave Turner wrote on 02/09/16 20:12:

On 02/09/16 01:38, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 01/09/16 08:51:


My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners. 
Comparing

with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...


I'm a little bit at a loss here, as I can't find anything in the vdev
tree dealing with, say, scanners or, say, mode switching USB devices.
Since those are major chunks in udev rules, I'm just confused. Have I
misunderstood?

I find "scanner" mentioned in the hwdb, but there is no formal
classification of those other than identifying as usb (or pci);
nothing classifying them as scanners (unless you'd regard the model
label as such). I wish someone could explain things for me...

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


I loathe the 'feature' of udev that forces you to create or modify
/etc/udev/rules.d/51-android to let your cheap'n'cheerful unlisted
Android Device get through udev security. And now it seems that vdev is
about to force the same thing. I know it isn't easy to completely
re-think how things should be done, do OSX and the BSDs have a different
and better way of doing this sort of thing?

I want to ask you why a database of $V/$P/$N mappings is needed. It is
my laptop and my cheap Android tablet and I want to plug it into the USB
socket and have them play nicely together. God knows what I would have
done if I was just a normal ordinary person. I would have concluded that
linux was shit and gone back to my Mac or Windoze.

dmesg knew all about my android tablet when I plugged it in, why can't
vdev pick it up from there?

this is what I had to add into 51-android having had a look at dmesg 
first.


#my cheap Android tablet
ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"


I suppose the issue is to make sure that the right user have the right 
access to the right devices when she wants to use the computer, whilst 
making sure that the wrong user doesn't have the wrong access 
regardless of what he wants to do.


Traditionally on Linux, the means to achieve this would be to use file 
permissions. Then more recently, the notion of access control lists 
was invented to offer a more dynamic access control. And then even 
more recently "people" have decided that this is an insanely hard 
problem, which requires an insane solution.


Given the scope of possible use cases, perhaps the permission handling 
should be taken elsewhere, and make the hotplug handler only deal with 
ensuring the device is functional and available to the permission 
handling sub system. Maybe even the latter could be PAM (although I 
don't know if PAM can make device access be allowed rather than just 
judging whether or not it is allowed).


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



So, what if some daemon or other knows I have plugged in my Android 
device and brings up a window telling me to click here to access my 
Android device or Cancel? The daemon then does the necessary things and 
it Just Works.


(managed to hit Reply List 1st time!)

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

Re: [DNG] vdev - scanner

[Ralph Ronnquist]

Dave Turner wrote on 02/09/16 20:12:

On 02/09/16 01:38, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 01/09/16 08:51:


My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners. Comparing
with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...


I'm a little bit at a loss here, as I can't find anything in the vdev
tree dealing with, say, scanners or, say, mode switching USB devices.
Since those are major chunks in udev rules, I'm just confused. Have I
misunderstood?

I find "scanner" mentioned in the hwdb, but there is no formal
classification of those other than identifying as usb (or pci);
nothing classifying them as scanners (unless you'd regard the model
label as such). I wish someone could explain things for me...

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


I loathe the 'feature' of udev that forces you to create or modify
/etc/udev/rules.d/51-android to let your cheap'n'cheerful unlisted
Android Device get through udev security. And now it seems that vdev is
about to force the same thing. I know it isn't easy to completely
re-think how things should be done, do OSX and the BSDs have a different
and better way of doing this sort of thing?

I want to ask you why a database of $V/$P/$N mappings is needed. It is
my laptop and my cheap Android tablet and I want to plug it into the USB
socket and have them play nicely together. God knows what I would have
done if I was just a normal ordinary person. I would have concluded that
linux was shit and gone back to my Mac or Windoze.

dmesg knew all about my android tablet when I plugged it in, why can't
vdev pick it up from there?

this is what I had to add into 51-android having had a look at dmesg first.

#my cheap Android tablet
ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"


I suppose the issue is to make sure that the right user have the right 
access to the right devices when she wants to use the computer, whilst 
making sure that the wrong user doesn't have the wrong access regardless 
of what he wants to do.


Traditionally on Linux, the means to achieve this would be to use file 
permissions. Then more recently, the notion of access control lists was 
invented to offer a more dynamic access control. And then even more 
recently "people" have decided that this is an insanely hard problem, 
which requires an insane solution.


Given the scope of possible use cases, perhaps the permission handling 
should be taken elsewhere, and make the hotplug handler only deal with 
ensuring the device is functional and available to the permission 
handling sub system. Maybe even the latter could be PAM (although I 
don't know if PAM can make device access be allowed rather than just 
judging whether or not it is allowed).


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

Re: [DNG] vdev - android

[Ron]

On Fri, 2 Sep 2016 09:59:29 -0400
Hendrik Boom  wrote:

> Have things changed?

ISTR that they changed between Android 4 and Android 5; my 4 tablet mounted 
directly, while for my daughter's 5 phone I had to install some packages.
 
Cheers,
 
Ron.
-- 
 When men are pure, laws are useless;
when men are corrupt, laws are broken.
  -- Benjamin Disraeli

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - android

[Hendrik Boom]

On Fri, Sep 02, 2016 at 11:12:00AM +0100, Dave Turner wrote:
> 
> dmesg knew all about my android tablet when I plugged it in, why can't vdev
> pick it up from there?
> 
> this is what I had to add into 51-android having had a look at dmesg first.
> 
> #my cheap Android tablet
> ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"

The real question is whether there's another way to identify what a kind of
device it is.

Androids see to be mtp devices if you want to mount them as a file 
system.  Linux has some obscure command to mount such things.  I forget 
what.
 
They aren't USB storage devices.  At least, mine wasn't.

If you don't want to mount it, you use adb to access it.

At least, mtp and adb are the official ways to access them.
Have things changed?

-- hendrik

> 
> DaveT
> 
> (idiot boy managed to hit Reply instead of Reply List, icedove isn't as good
> as it thinks it is...)
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - scanner

[Arnt Gulbrandsen]

The key here is that linux doesn't assume one user. You get to answer, from 
first principles, whether a particular USB device belongs to user x or to 
root, etc. The mac has a stronger assumption that your mac belongs to you 
(which is why the default hostname is "Dave Turner's Mac", etc) and what 
you plug in does too.


I like the way KDE handles/handled USB sticks: The version of KDE I'm 
running asks me about USB sticks the first time and remembers each stick 
forever, so if I plug in my keyring stick now the linux box will automount 
it. That would be a fine way to handle phones too.


Arnt

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

Re: [DNG] vdev - scanner

[Dave Turner]

On 02/09/16 01:38, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 01/09/16 08:51:


My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners. Comparing
with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...


I'm a little bit at a loss here, as I can't find anything in the vdev 
tree dealing with, say, scanners or, say, mode switching USB devices. 
Since those are major chunks in udev rules, I'm just confused. Have I 
misunderstood?


I find "scanner" mentioned in the hwdb, but there is no formal 
classification of those other than identifying as usb (or pci); 
nothing classifying them as scanners (unless you'd regard the model 
label as such). I wish someone could explain things for me...


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


I loathe the 'feature' of udev that forces you to create or modify 
/etc/udev/rules.d/51-android to let your cheap'n'cheerful unlisted 
Android Device get through udev security. And now it seems that vdev is 
about to force the same thing. I know it isn't easy to completely 
re-think how things should be done, do OSX and the BSDs have a different 
and better way of doing this sort of thing?


I want to ask you why a database of $V/$P/$N mappings is needed. It is 
my laptop and my cheap Android tablet and I want to plug it into the USB 
socket and have them play nicely together. God knows what I would have 
done if I was just a normal ordinary person. I would have concluded that 
linux was shit and gone back to my Mac or Windoze.


dmesg knew all about my android tablet when I plugged it in, why can't 
vdev pick it up from there?


this is what I had to add into 51-android having had a look at dmesg first.

#my cheap Android tablet
ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"

DaveT

(idiot boy managed to hit Reply instead of Reply List, icedove isn't as 
good as it thinks it is...)


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

Re: [DNG] vdev - scanner

[Ralph Ronnquist]

Ralph Ronnquist wrote on 01/09/16 08:51:


My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners. Comparing
with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...


I'm a little bit at a loss here, as I can't find anything in the vdev 
tree dealing with, say, scanners or, say, mode switching USB devices. 
Since those are major chunks in udev rules, I'm just confused. Have I 
misunderstood?


I find "scanner" mentioned in the hwdb, but there is no formal 
classification of those other than identifying as usb (or pci); nothing 
classifying them as scanners (unless you'd regard the model label as 
such). I wish someone could explain things for me...


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

Re: [DNG] vdev - scanner

[Ralph Ronnquist]

fsmithred wrote on 01/09/16 06:17:

...

OS_TYPE=255/255/255
...


My worry is that the OS_TYPE=255/255/255 condition is not distinct 
enough to make the action apply exactly and only for scanners. Comparing 
with udev rules, you'll find there are more than a few rules for USB 
devices, and almost all of them make their classification based on the 
vendor/product pair (rather than the capability declarations).


Translated to vdev, it would mean to use match criteria of the form 
OS_PRODUCT=$V/$P/$N with $V=vendor, $P=product, $N=version. The value 
match processing is literal, and you'd thus need a separate action for 
every $V/$P/$N. (Like udev)


Alternatively, one could have the one action (without OS_PRODUCT), and a 
new, clever helper to assign access group via a database of 
$V/$P/$N->group mappings. Perhaps people previously involved in vdev 
development would have a view on this? The helper itself is trivial, but 
it'll depend on the database, and the major work would be in preparing 
that database (or finding and adapting an already existing one).


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

Re: [DNG] vdev - scanner

[fsmithred]

On 08/31/2016 11:08 AM, info at smallinnovations.nl wrote:
> On 31-08-16 16:38, fsmithred wrote:
>> On 08/31/2016 07:17 AM, fsmithred wrote:
>>> On 08/31/2016 05:03 AM, Ralph Ronnquist wrote:
>> Our discussion in irc was productive. The following works with the stock
>> permissions.sh (without the lines for setfacl). The acl does not get set,
>> but the scanner works. And if I unplug and re-plug the usb cable, the
>> scanner gets the next device number, and it works!
>>
>> cat /etc/vdev/actions/scanner.act
>>
>> [vdev-action]
>> event=add
>> path=^bus/usb/*/[001-999]
>> OS_SUBSYSTEM=usb
>> OS_TYPE=255/255/255
>> VAR_PERMISSIONS_OWNER=root
>> VAR_PERMISSIONS_GROUP=scanner
>> VAR_PERMISSIONS_MODE=0664
>> helper=permissions.sh
>> if_exists=run
>> daemonlet=true
>>
>> -fsr
>>
> And if you give the device free with a event=remove action file? Does it
> then keep it's old device number with reconnecting?
> 
> Grtz
> 
> Nick

I don't know. Not sure what would go in that file, either. I can test that
later. I did just try it in the system I'm using now, which is running
udev, and it gets a new number. I see that the number is now up to 36, so
that must increment every time I add/remove a usb thumb drive, scanner,
and maybe any other usb device. On this machine, the scanner is on
005/036, and there's nothing between that and 005/001. I believe that I've
plugged and removed a thumb drive around 30 times since my last reboot.

Edit: or maybe by some other logic. I just plugged in a flash drive, and
it's on 002/048

-fsr


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

Re: [DNG] vdev - scanner

[info at smallinnovations.nl]

On 31-08-16 16:38, fsmithred wrote:

On 08/31/2016 07:17 AM, fsmithred wrote:

On 08/31/2016 05:03 AM, Ralph Ronnquist wrote:

Our discussion in irc was productive. The following works with the stock
permissions.sh (without the lines for setfacl). The acl does not get set,
but the scanner works. And if I unplug and re-plug the usb cable, the
scanner gets the next device number, and it works!

cat /etc/vdev/actions/scanner.act

[vdev-action]
event=add
path=^bus/usb/*/[001-999]
OS_SUBSYSTEM=usb
OS_TYPE=255/255/255
VAR_PERMISSIONS_OWNER=root
VAR_PERMISSIONS_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
if_exists=run
daemonlet=true

-fsr

And if you give the device free with a event=remove action file? Does it 
then keep it's old device number with reconnecting?


Grtz

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

Re: [DNG] vdev - scanner

[fsmithred]

On 08/31/2016 07:17 AM, fsmithred wrote:
> On 08/31/2016 05:03 AM, Ralph Ronnquist wrote:
>> Ralph Ronnquist wrote on 31/08/16 15:54:
>>> Ralph Ronnquist wrote on 31/08/16 10:21:


 fsmithred wrote on 31/08/16 07:54:
> ...
> I got it to work. Here's the action file and the helper script. The
> helper
> script is a modified permissions.sh. I added a test for $VDEV_MAJOR and
> $VDEV_MINOR to trigger setfacl. Scanner now works on my installation.
> ...

 Great. I'll roll it into the package.
>>>
>>> On looking at this, I saw the action file  was rather different from
>>> other action files, and (as I'm slowly picking on this up) I'd like to
>>> check with you whether the following action file might do the work:
>>>
>>> /etc/vdev/actions/scanner.act
>>> [vdev-action]
>>> event=add
>>> path=^bus/usb/*/[001-999]
>>> OS_SUBSYSTEM=usb
>>> VAR_PERMISSIONS_OWNER=root
>>> VAR_PERMISSIONS_GROUP=scanner
>>> VAR_PERMISSIONS_MODE=0664
>>> helper=permissions.sh
>>> daemonlet=true
>>>
>>> Afaict, the acls should follow the file permissions and you shouldn't
>>> need to set those.
>>>
>>> Ralph.
>>
>> oops, I seem to have lost the "OS_TYPE=255/255/255" line. Probably important.
>>
>> Ralph.
> 
> 
> That didn't work, even with the OS_TYPE=255/255/255. The file permissions
> get set, but not the acl. I played with some variations, and the following
> works, but only if I add the lines for setfacl to permissions.sh. (i.e.
> test for major and minor number then run setfacl)
> 
> /etc/vdev/actions/scanner.act
> [vdev-action]
> event=add
> path=^bus/usb/*/[001-999]
> OS_SUBSYSTEM=usb
> OS_TYPE=255/255/255
> VAR_PERMISSIONS_OWNER=root
> VAR_PERMISSIONS_GROUP=scanner
> VAR_PERMISSIONS_MODE=0664
> helper=permissions.sh
> if_exists=run
> 
> 
> One other problem with all the ways I've tried is that if I unplug the
> scanner and plug it in again, the acl does not get set. A reboot is
> required for that.
> 
> -fsr
> 
> 

Our discussion in irc was productive. The following works with the stock
permissions.sh (without the lines for setfacl). The acl does not get set,
but the scanner works. And if I unplug and re-plug the usb cable, the
scanner gets the next device number, and it works!

cat /etc/vdev/actions/scanner.act

[vdev-action]
event=add
path=^bus/usb/*/[001-999]
OS_SUBSYSTEM=usb
OS_TYPE=255/255/255
VAR_PERMISSIONS_OWNER=root
VAR_PERMISSIONS_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
if_exists=run
daemonlet=true

-fsr


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

Re: [DNG] vdev - scanner

[fsmithred]

On 08/31/2016 05:03 AM, Ralph Ronnquist wrote:
> Ralph Ronnquist wrote on 31/08/16 15:54:
>> Ralph Ronnquist wrote on 31/08/16 10:21:
>>>
>>>
>>> fsmithred wrote on 31/08/16 07:54:
 ...
 I got it to work. Here's the action file and the helper script. The
 helper
 script is a modified permissions.sh. I added a test for $VDEV_MAJOR and
 $VDEV_MINOR to trigger setfacl. Scanner now works on my installation.
 ...
>>>
>>> Great. I'll roll it into the package.
>>
>> On looking at this, I saw the action file  was rather different from
>> other action files, and (as I'm slowly picking on this up) I'd like to
>> check with you whether the following action file might do the work:
>>
>> /etc/vdev/actions/scanner.act
>> [vdev-action]
>> event=add
>> path=^bus/usb/*/[001-999]
>> OS_SUBSYSTEM=usb
>> VAR_PERMISSIONS_OWNER=root
>> VAR_PERMISSIONS_GROUP=scanner
>> VAR_PERMISSIONS_MODE=0664
>> helper=permissions.sh
>> daemonlet=true
>>
>> Afaict, the acls should follow the file permissions and you shouldn't
>> need to set those.
>>
>> Ralph.
> 
> oops, I seem to have lost the "OS_TYPE=255/255/255" line. Probably important.
> 
> Ralph.


That didn't work, even with the OS_TYPE=255/255/255. The file permissions
get set, but not the acl. I played with some variations, and the following
works, but only if I add the lines for setfacl to permissions.sh. (i.e.
test for major and minor number then run setfacl)

/etc/vdev/actions/scanner.act
[vdev-action]
event=add
path=^bus/usb/*/[001-999]
OS_SUBSYSTEM=usb
OS_TYPE=255/255/255
VAR_PERMISSIONS_OWNER=root
VAR_PERMISSIONS_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
if_exists=run


One other problem with all the ways I've tried is that if I unplug the
scanner and plug it in again, the acl does not get set. A reboot is
required for that.

-fsr


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

Re: [DNG] vdev - scanner

[Ralph Ronnquist]

Ralph Ronnquist wrote on 31/08/16 15:54:

Ralph Ronnquist wrote on 31/08/16 10:21:



fsmithred wrote on 31/08/16 07:54:

...
I got it to work. Here's the action file and the helper script. The
helper
script is a modified permissions.sh. I added a test for $VDEV_MAJOR and
$VDEV_MINOR to trigger setfacl. Scanner now works on my installation.
...


Great. I'll roll it into the package.


On looking at this, I saw the action file  was rather different from
other action files, and (as I'm slowly picking on this up) I'd like to
check with you whether the following action file might do the work:

/etc/vdev/actions/scanner.act
[vdev-action]
event=add
path=^bus/usb/*/[001-999]
OS_SUBSYSTEM=usb
VAR_PERMISSIONS_OWNER=root
VAR_PERMISSIONS_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
daemonlet=true

Afaict, the acls should follow the file permissions and you shouldn't
need to set those.

Ralph.


oops, I seem to have lost the "OS_TYPE=255/255/255" line. Probably 
important.


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

Re: [DNG] vdev - scanner

[Ralph Ronnquist]

Ralph Ronnquist wrote on 31/08/16 10:21:



fsmithred wrote on 31/08/16 07:54:

...
I got it to work. Here's the action file and the helper script. The
helper
script is a modified permissions.sh. I added a test for $VDEV_MAJOR and
$VDEV_MINOR to trigger setfacl. Scanner now works on my installation.
...


Great. I'll roll it into the package.


On looking at this, I saw the action file  was rather different from 
other action files, and (as I'm slowly picking on this up) I'd like to 
check with you whether the following action file might do the work:


/etc/vdev/actions/scanner.act
[vdev-action]
event=add
path=^bus/usb/*/[001-999]
OS_SUBSYSTEM=usb
VAR_PERMISSIONS_OWNER=root
VAR_PERMISSIONS_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
daemonlet=true

Afaict, the acls should follow the file permissions and you shouldn't 
need to set those.


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

Re: [DNG] vdev - scanner

[Ralph Ronnquist]

fsmithred wrote on 31/08/16 07:54:

...
I got it to work. Here's the action file and the helper script. The helper
script is a modified permissions.sh. I added a test for $VDEV_MAJOR and
$VDEV_MINOR to trigger setfacl. Scanner now works on my installation.
...


Great. I'll roll it into the package.

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

Re: [DNG] vdev packaging

[Ralph Ronnquist]

shraptor wrote on 31/08/16 07:14:

...

Tried to setup the arm-sdk on vbox devuan with vdev

Getting a lot of errors about udev, guess that is to be expected at this
stage.

does the vdev packages "provides" udev?

including full output of apt-get command below

Guess I have todo the arm-sdk stuff on a vanilla devuan for now.
...


Right. Yes, it's probably due to vdev, which at the moment doesn't play 
nice with udev as it removes all udev's initramfs configurations. That's 
something I brought in from the earlier vdev testing, but probably it's 
not actually needed, and almost certainly the wrong thing to do. It 
should be possible to keep both udev and vdev set ups available for 
initramfs (meaning that vdev should not remove it), and only deal with 
the fact that the original init script favours udev; as I understood it, 
it kind of "enforces" udev. That's why the vdev package also takes over 
that init script, which it shouldn't.


Secondly, one will need to deal with having the right init.d scripts 
activated. This is a more competitive choice, probably, although I guess 
the actual choice is made in the hotplug registration.


I believe Daniel Reurich has the intention to dive into this when his 
schedule will allow it.


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

Re: [DNG] vdev - scanner

[fsmithred]

On 08/16/2016 08:35 PM, fsmithred wrote:
> On 08/16/2016 07:54 PM, Ralph Ronnquist wrote:
>> fsmithred wrote on 17/08/16 09:34:
>>> On 08/16/2016 12:49 PM, shraptor wrote:
 On 2016-08-16 18:19, shraptor wrote:
> On 2016-08-16 18:11, shraptor wrote:
>>> I got the scanner working.
>>>
>>> If I boot with udev, the scanner works, and the permissions on the
>>> device
>>> look like this:
>>>
>>> ls -l /dev/bus/usb/002/
>>> crw-rw-r--+ 1 root root 189, 137 Aug 16 10:30 010
>>>
>>> and with vdev, it looks like this:
>>> crw--- 1 root root 189, 131 Aug 16 10:39 004
>>>
>>> I changed the permissions and added myself to the scanner group (oops!)
>>> and now xsane finds the scanner when I'm running vdev. I hope someone
>>> knows what to do with this information, because I'm in new territory
>>> here.
>>> (and I don't know C.)
>>>
>>> If udevadm output for the scanner would help, I'll post it. The udev
>>> rules
>>> for scanners are in /lib/udev/rules.d/60-libsane.rules
>>
>>
>> Maybe you should write a vdev action for your scanner
>> on my system they actions are in /etc/vdev/actions
>>
>> for instance optical.act contains
>>
>> [vdev-action]
>> event=any
>> path=^sr[0-9]*$
>> VAR_OPTICAL_OWNER=root
>> VAR_OPTICAL_GROUP=optical
>> VAR_OPTICAL_MODE=0660
>> helper=optical.sh
>> daemonlet=true
>> if_exists=run
>>
>>
>>
>> No C is needed. Write something that matches path like for optical
>> path=^sr[0-9]*$
>> then set needed permissions and group and vdev will fix it for you
>>
>>
>> When you succeed you may contribute that .act file for others, yeah?
>
>
> Maybe you can use something like null.act
>
> [vdev-action]
> event=add
> path=^null$
> VAR_PERMISSIONS_MODE=0666
> helper=permissions.sh
> if_exists=run
>
>
>
> I mean the permissions.sh
>
>
> so something like
>
> scanner.act
>
> [vdev-action]
> event=add
> path=^null$

> VAR_PERMISSIONS_MODE=0664
> helper=permissions.sh
> if_exists=run
>
> Dunnow wot path you should use but maybe you could figure it out?


 perhaps?

 scanner.act

 [vdev-action]
 event=add
 path=^bus/usb/1$
 VAR_OWNER=root
 VAR_GROUP=scanner
 VAR_PERMISSIONS_MODE=0664
 helper=permissions.sh
 if_exists=run


 Does debian use something like /dev/usbscanner0 or /dev/usb/scanner0?
 Then maybe a new helper scanner.sh is needed, like optical.sh?

 In the beginning of vdev creation we dreamt of a udev rules to vdev action
 parser


>>>
>>> I now have a better idea of what such dreams would entail. Getting close...
>>>
>>>
>>> This mostly works. I can get the right permissions on the device, but when
>>> I add the setfacl command, vdev fails. Error is "Invalid action" and it
>>> lists /usr/etc/vdev/actions/scanner.act. If I run the command in the
>>> console, it works correctly. I tried it with the command before and after
>>> "if_exists=run".
>>>
>>>
>>> [vdev-action]
>>> event=add
>>> path=^bus/usb/*/[001-999]
>>> OS_SUBSYSTEM=usb
>>> OS_TYPE=255/255/255
>>> VAR_OWNER=root
>>> VAR_GROUP=scanner
>>> VAR_PERMISSIONS_MODE=0664
>>> helper=permissions.sh
>>> if_exists=run
>>> command:/usr/bin/setfacl -m g:scanner:rw $VDEV_MOUNTPOINT/$VDEV_PATH
>>>
>>> Any ideas on how to get setfacl to work are welcome. Thanks.
>>>
>>
>> devuan% which setfacl
>> /bin/setfacl
>>
>> maybe? Ralph.
> 
> That's weird. When I run 'which setfacl' I'm told it's at
> /usr/bin/setfacl. On further examination, that's a symlink to
> /bin/setfacl. Changing it in the action file didn't make a difference.
> 
> Assuming this will eventually work, would daemonlet=true need to be added
> to get vdev to deal with plugging and unplugging the scanner after boot?
> 
> -fsr
> 

I got it to work. Here's the action file and the helper script. The helper
script is a modified permissions.sh. I added a test for $VDEV_MAJOR and
$VDEV_MINOR to trigger setfacl. Scanner now works on my installation.

The scanner doesn't work when I'm running from a live usb. It seems that
aufs does not support acls. If I boot with udev, the scanner gets the acl
and works. I don't know how udev gets around the aufs problem. I also
don't know how it will work with newer versions of live-config and
live-boot that use overlayfs instead.

-fsr

/etc/vdev/actions/scanner.act

[vdev-action]
event=add
path=^bus/usb/*/[001-999]
OS_SUBSYSTEM=usb
OS_TYPE=255/255/255
VAR_OWNER=root
VAR_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=scanner.sh
if_exists=run


/lib/vdev/scanner.sh

#!/bin/dash

# vdevd helper to set permissions and ownership.
# takes the owner from the VDEV_VAR_PERMISSIONS_OWNER environment variable.
# takes the group from the VDEV_VAR_PERMISSIONS_GROUP environment 

Re: [DNG] vdev packaging

[shraptor]

On 2016-08-30 21:13, shraptor wrote:

On 2016-08-28 12:36, fsmithred wrote:

On 08/27/2016 11:13 PM, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 28/08/16 11:37:


fsmithred wrote on 28/08/16 01:12:

...

Sadly, I'm not getting Ralph's i386 build to boot. It's hanging on 
usb
(keyboard). Any time I type, I get a usb disconnect and connect 
message.




I'm afraid it was a worse problem. I had updated (improved) the
initramfs hook and then packaged it all without proper testing. This
also affected the amd64 version, which thus fails to build the 
initrd
properly. The amd64 packages are now corrected, and I'll also update 
the

i386 packages shortly.

If on inspection you find /usr/share/initramfs-tools/hooks/vdev 
being
non-executable, you should refetch vdev_1.0beta-1_amd64.deb (or all 
of
them) and reinstall. (If it already is executable, you have the 
initial

release, i.e., without the improved script, and can thus sit back to
enjoy life as usual)


Corrected packages available at the same place as before:
https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

Note that there is now an explicit dependency on makedev, which might
cause a slight hiccup for an i386 installation. If so, a normal 
"apt-get

-f install" will sort it out.

Ralph.


The corrected amd64 packages work. I just downloaded, installed and
rebooted with the new initrd. Smooth as silk.



smooth a silk indeed, Good Job Mr, Ronnquist.

Am happy now!

Tried it in a virtualbox install, will set up one of my comps
with devuan now so I can run it for real.

Can't wait to get it on my rpi3 :)



/scooby



Tried to setup the arm-sdk on vbox devuan with vdev

Getting a lot of errors about udev, guess that is to be expected at this 
stage.


does the vdev packages "provides" udev?

including full output of apt-get command below

Guess I have todo the arm-sdk stuff on a vanilla devuan for now.


/scooby



# apt-get install build-essential gnupg2 debootstrap curl rsync 
gcc-arm-none-eabi parted kpartx qemu-user-static sudo git-core parted 
gcc-multilib lib32z1 u-boot-tools device-x32gcc-4.9-dev libx32gcc1

  libx32gomp1 libx32itm1 libx32quadmath0 libx32ubsan0
Suggested packages:
  libnewlib-doc
The following NEW packages will be installed:
  binutils-arm-none-eabi cgpt debootstrap device-tree-compiler
  gcc-4.9-multilib gcc-arm-none-eabi gcc-multilib git-core kpartx 
lib32asan1
  lib32atomic1 lib32cilkrts5 lib32gcc-4.9-dev lib32gcc1 lib32gomp1 
lib32itm1
  lib32quadmath0 lib32stdc++6 lib32ubsan0 lib32z1 libc6-dev-i386 
libc6-dev-x32

  libc6-i386 libc6-x32 libnewlib-arm-none-eabi libnewlib-dev
  libstdc++-arm-none-eabi-newlib libx32asan1 libx32atomic1 
libx32cilkrts5

  libx32gcc-4.9-dev libx32gcc1 libx32gomp1 libx32itm1 libx32quadmath0
  libx32ubsan0 lzop qemu-user-static u-boot-tools
0 upgraded, 39 newly installed, 0 to remove and 4 not upgraded.
5 not fully installed or removed.
Need to get 14.8 MB/81.0 MB of archives.
After this operation, 584 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://auto.mirror.devuan.org/merged/ jessie/main libc6-i386 amd64 
2.19-18+deb8u4 [2,377 kB]
Get:2 http://auto.mirror.devuan.org/merged/ jessie/main libc6-dev-i386 
amd64 2.19-18+deb8u4 [1,319 kB]
Get:3 http://auto.mirror.devuan.org/merged/ jessie/main libc6-x32 amd64 
2.19-18+deb8u4 [2,603 kB]
Get:4 http://auto.mirror.devuan.org/merged/ jessie/main libc6-dev-x32 
amd64 2.19-18+deb8u4 [1,587 kB]
Get:5 http://auto.mirror.devuan.org/merged/ jessie/main git-core all 
1:2.1.4-2.1+deb8u2 [1,496 B]
Get:6 http://auto.mirror.devuan.org/merged/ jessie/main qemu-user-static 
amd64 1:2.1+dfsg-12+deb8u6 [6,913 kB]

Fetched 14.8 MB in 7s (1,852 kB/s)
Extracting templates from packages: 100%
Selecting previously unselected package libc6-i386.
(Reading database ... 101777 files and directories currently installed.)
Preparing to unpack .../libc6-i386_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-i386 (2.19-18+deb8u4) ...
Selecting previously unselected package libc6-dev-i386.
Preparing to unpack .../libc6-dev-i386_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-dev-i386 (2.19-18+deb8u4) ...
Selecting previously unselected package libc6-x32.
Preparing to unpack .../libc6-x32_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-x32 (2.19-18+deb8u4) ...
Selecting previously unselected package libc6-dev-x32.
Preparing to unpack .../libc6-dev-x32_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-dev-x32 (2.19-18+deb8u4) ...
Selecting previously unselected package lib32gcc1.
Preparing to unpack .../lib32gcc1_1%3a4.9.2-10_amd64.deb ...
Unpacking lib32gcc1 (1:4.9.2-10) ...
Selecting previously unselected package libx32gcc1.
Preparing to unpack .../libx32gcc1_1%3a4.9.2-10_amd64.deb ...
Unpacking libx32gcc1 (1:4.9.2-10) ...
Selecting previously unselected package lib32gomp1.
Preparing to unpack .../lib32gomp1_4.9.2-10_amd64.deb ...
Unpacking lib32gomp1 (4.9.2-10) ...
Selecting previously unselected package libx32gomp1.
Preparing to unpack 

Re: [DNG] vdev packaging

[shraptor]

On 2016-08-28 12:36, fsmithred wrote:

On 08/27/2016 11:13 PM, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 28/08/16 11:37:


fsmithred wrote on 28/08/16 01:12:

...

Sadly, I'm not getting Ralph's i386 build to boot. It's hanging on 
usb
(keyboard). Any time I type, I get a usb disconnect and connect 
message.




I'm afraid it was a worse problem. I had updated (improved) the
initramfs hook and then packaged it all without proper testing. This
also affected the amd64 version, which thus fails to build the initrd
properly. The amd64 packages are now corrected, and I'll also update 
the

i386 packages shortly.

If on inspection you find /usr/share/initramfs-tools/hooks/vdev being
non-executable, you should refetch vdev_1.0beta-1_amd64.deb (or all 
of
them) and reinstall. (If it already is executable, you have the 
initial

release, i.e., without the improved script, and can thus sit back to
enjoy life as usual)


Corrected packages available at the same place as before:
https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

Note that there is now an explicit dependency on makedev, which might
cause a slight hiccup for an i386 installation. If so, a normal 
"apt-get

-f install" will sort it out.

Ralph.


The corrected amd64 packages work. I just downloaded, installed and
rebooted with the new initrd. Smooth as silk.



smooth a silk indeed, Good Job Mr, Ronnquist.

Am happy now!

Tried it in a virtualbox install, will set up one of my comps
with devuan now so I can run it for real.

Can't wait to get it on my rpi3 :)



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

Re: [DNG] vdev packaging

[Didier Kryn]

Le 29/08/2016 16:49, Ralph Ronnquist a écrit :

Didier Kryn wrote on 29/08/16 22:40:

Le 27/08/2016 00:45, Ralph Ronnquist a écrit :


You can also build your own deb's by cloning
https://git.devuan.org/ralph.ronnquist/vdev


Hi Ralph.

I had a look at the above-mentioned link with my web browser. I
think all the text is from Jude and part of it is at the first person,
however I couldn't find a mention of his name, which, probably Jude
forgot to insert.

Do you think there's a way to mention that this is the beginning of
the take-over of an orphaned software authored by Jude Nelson and he is
still the author of all of it, including the description and the FAQ? Or
maybe the documentation should be re-written.

I noticed with great interest that libudev-compat is completely
independent of vdev, which is a very smart design decision of Jude. He
further explicitly states that any other hotplugger can be used in
place of vdev or udev, while still benefiting of libudev-compat. This,
in my opinion, means that simpler hotpluggers, like mdev, can be used
and allow Xserver.xorg to work, because what xorg requires is libudev's
API. This confirms that the design of vdev is much smarter than udev, or
that udev authors deliberately introduced a lock-in.

Didier


Good point. I have revised the project front page. The files otherwise 
remain as copies, apart from the minor changes to the Makefiles and 
the additions of "debian" subdirectories for package configurations. 
Plus that I've started the drafting of man pages. Though I can't keep 
up the pace with my day-job craving attention.



Sure, there are priorities... :-)

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

Re: [DNG] vdev packaging

[Ralph Ronnquist]

Didier Kryn wrote on 29/08/16 22:40:

Le 27/08/2016 00:45, Ralph Ronnquist a écrit :


You can also build your own deb's by cloning
https://git.devuan.org/ralph.ronnquist/vdev


Hi Ralph.

I had a look at the above-mentioned link with my web browser. I
think all the text is from Jude and part of it is at the first person,
however I couldn't find a mention of his name, which, probably Jude
forgot to insert.

Do you think there's a way to mention that this is the beginning of
the take-over of an orphaned software authored by Jude Nelson and he is
still the author of all of it, including the description and the FAQ? Or
maybe the documentation should be re-written.

I noticed with great interest that libudev-compat is completely
independent of vdev, which is a very smart design decision of Jude. He
further explicitly states that any other hotplugger can be used in
place of vdev or udev, while still benefiting of libudev-compat. This,
in my opinion, means that simpler hotpluggers, like mdev, can be used
and allow Xserver.xorg to work, because what xorg requires is libudev's
API. This confirms that the design of vdev is much smarter than udev, or
that udev authors deliberately introduced a lock-in.

Didier


Good point. I have revised the project front page. The files otherwise 
remain as copies, apart from the minor changes to the Makefiles and the 
additions of "debian" subdirectories for package configurations. Plus 
that I've started the drafting of man pages. Though I can't keep up the 
pace with my day-job craving attention.


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