vdev testing

chrisw · 2016-12-30 23:12:18

First off, many thanks to Jude Nelson, Ralph Ronnquist and all others who have helped with vdev.
Below is some feedback from my initial try with vdev and request for help (see item 8) to get me a bit further.

Testing vdev on old Dell Inspiron 1525 running devuan beta2, kernel 3.16.0-4-amd64

1) I copied Ralph's packages from https://git.devuan.org/ralph.ronnquist/vdev/tree/master:
libudev1-compat_1.2.1_amd64.deb
libudev1-compat_1.2.1_i386.deb
vdev-initramfs_1.2.7_amd64.deb
vdev-initramfs_1.2.7_i386.deb
vdevd_2.0.2_amd64.deb
vdevd_2.0.2_i386.deb
to a local repository I maintain using aptly (this mostly contains mythtv packages I have compliled for devuan)

2) ensured my local repository was in /etc/apt/sources.lst

3) ran synaptic and "reloaded" (updated) then selected and installed libudev1-compat, vdev-initramfs and vdevd
NOTE: package libudev1-compat would not install properly with error message:
"trying to overwite '/usr/include/libudev.h', which is also in package libudev-dev_215-17+deb8u5"
I therefore uninstalled libudev-dev and retried libudev1-compat which then installed without error

4) As root ran: /usr/share/vdev/vdev-install.sh dialog
and choose vdev then rebooted.

5) All appeared to work as expected (including WiFi)

6) Tried setting PERSISTENT_INTERFACE_NAMEs in /etc/vdev/ifnames.conf
for three network adapters internal WiFi, internal ethernet & external USB ethernet adapter
This apparently had no effect even after reboot until I reran vdev-install.sh and rebooted (this is presumably
expected behaviour? but probably wants documenting)

7) Attaching a USB stick or a USB disk drive did not produce a "mounting" icon on the xfce4 desktop (as would happen with udev on this machine)
although everything was setup okay for manual mounting. Is this expected behavior? Running vdev-install.sh, choosing udev and reboot
and the xfce4 "mounting" icons again worked as expected, reverting to vdev and the xfce4 "mounting" icons failed to work.

8) I attached an external USB HDTV adapter (PCTV 290e) and the expected /dev/dvb devices were created.
However for to test this further on a proper multi-tuner mythtv backend (with the need for consistent and meaningful names),
I would need to be able to recreate the following udev rules in vdev:

# PCTV 290e single tuner USB stick
# --------------------------------
# Create symlinks /dev/dvb/adapterPCTV290e/* pointing to PCTV 290e adapter (has unique attributes, so can find wherever it is)
KERNEL=="*demux0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/demux0"
KERNEL=="*dvr0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/dvr0"
KERNEL=="*frontend0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/frontend0"
KERNEL=="*net0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/net0"

I have no idea how to do this! Any help with this would be appreciated.

9) Any other tests you would like doing?

dzz · 2016-12-31 12:41:17

Old "emachines" laptop running Trinity Desktop and eudev, otherwise current (Devuan-) Jessie. Simply used dpkg -i on the three amd64 vdev debs.

Same result here with a plugged USB, no desktop notification. It does show in blkid and I can pmount it. Perhaps then, not your xfce4 configs at fault. Other machines here have xfce4, can test later.

I don't see any other problems. Last time I tried vdev there were lots including no mouse.

Last edited by dzz (2016-12-31 12:50:54)

fsmithred · 2016-12-31 13:55:55

1 - 5 look right.
6. I never looked in that file before.
7. My guess is that gvfs needs some function in udev to tell it something. I run without gvfs here, so I wouldn't have noticed that.
Does your trash icon work?
8. You might need to alter some action files or a helper script. The most I've done with that was edit a pattern to find a device and change permissions.

Read Jude's documentation on the action files, (Appendix A)
https://git.devuan.org/unsystemd/vdev/b … to-test.md
https://github.com/jcnelson/vdev/blob/m … to-test.md

Look inside the helper scripts for clues. (in /lib/vdev)

Sorry I can't be more specific. It's a big black box. That I was able to do anything with the action files and permissions.sh was a surprise to me.

Last edited by fsmithred (2016-12-31 13:57:01)

dzz · 2016-12-31 14:55:11

Same machine, got xfce4 installed and running now. Using gvfs from angband.pl (it doesn't depend libsystemd0) and consolekit2. I know from before that combination works with full functionality for user usb handling and shutdown/suspend/reboot.

With (e)udev : plugged USB appears on desktop and in thunar, correctly labelled (“sandisk”), can mount/umount/eject normally, as user

With vdev: Appears as “64 GB Volume”, No label. Cannot mount as user (except with pmount), as if it's seen as a fixed disk.

With udev:

:~$ /usr/sbin/hwinfo --usb|grep "/dev/sd"
Device File: /dev/sdb (/dev/sg2)
Device Files: /dev/sdb, /dev/disk/by-id/usb-_USB_Flash_Memory_0013729B6877EB8156390022-0:0, /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0

:~$ dmesg| tail -n 1|grep removable
[ 2058.054823] sd 5:0:0:0: [sdb] Attached SCSI removable disk

With vdev, hwinfo shows less complete detection:

:~$ /usr/sbin/hwinfo --usb|grep "/dev/sd"
Device File: /dev/sdb

:~$ dmesg| tail -n 1|grep removable
[ 183.446863] sd 5:0:0:0: [sdb] Attached SCSI removable disk

I can't find any way to mark the above in a code box..

Last edited by dzz (2016-12-31 15:09:49)

fsmithred · 2016-12-31 15:11:54

You have to add code tags manually here.

I had a problem with refracta2usb in vdev. For some reason, it didn't recognize /dev/disk/by-id so I changed it to by-uuid. On the command line, it seems to work normally.

dzz · 2016-12-31 15:55:22

Confirmed here, using vdev "sdb1" is referenced and symlinked in /dev/disk/by-label and /dev/disk/by-uuid but nothing for it in /dev/disk/by-id.

chrisw · 2017-01-01 17:52:11

fsmithred wrote:

...
7. My guess is that gvfs needs some function in udev to tell it something. I run without gvfs here, so I wouldn't have noticed that.
Does your trash icon work?
8. You might need to alter some action files or a helper script. The most I've done with that was edit a pattern to find a device and change permissions.
Read Jude's documentation on the action files, (Appendix A)
https://git.devuan.org/unsystemd/vdev/b … to-test.md
https://github.com/jcnelson/vdev/blob/m … to-test.md
Look inside the helper scripts for clues. (in /lib/vdev)
Sorry I can't be more specific. It's a big black box. That I was able to do anything with the action files and permissions.sh was a surprise to me.

7. I don't have the trash icon configured - will give it a try

8. Thanks for the pointer - I'll report back if I can get anywhere (but don't hold your breath!)

chrisw · 2017-01-01 19:37:45

7. Wastebasket (trash icon) works as expected - both the desktop icon & the panel item

ralph.ronnquist · 2017-01-06 06:09:49

Re USB, (7): the overall issue is that several packages have been coded to utilize udev, via the rules files, for automagic hotplug handling, and they (of course) don't include a corresponding configuration (action+helper) for utilizing vdev. I did start on a "udev rules"-to-"vdev conf", but stopped (apart from incorporating scanner recognition into vdev), as I rather quickly saw it leading to insanity (mine). So, this aspect is in a state of pass the bucket game, where it really should be up to those other package developers to add their hotplug configuration wrt vdev.

That leads to your pt.8, and highlights the need for more/better documentations (and tools?) of how to "program" vdev.

(sorry. right now it's too hot here to think; I'll try again in the weekend...)

chrisw · 2017-01-07 20:32:59

Thanks Ralph,

In poking around trying to cobble together an .act file for the PCTV 290e I found two things:

A)
I managed to break vdev so that the initrd gave an error during boot (I didn't record at the time) boot then continued but something was obviously not setup as before because
the boot finished at a text terminal (rather than GUI login screen).

I think this was caused by my starting to create file /etc/vdev/actions/pctv290e.act(**) with entries certain to be
syntactically incorrect at that time, getting called away, saving the half done file and shutting down.
(**)

-----Content of /etc/vdev/actions/pctv290e.act-----
[vdev-action]
event=any
OS_SUBSYSTEM=dvb
rename_command=

[vdev-action]
event=any
OS_SUBSYSTEM=video4linux
VAR_V4L_OWNER=root
VAR_V4L_GROUP=video
VAR_V4L_MODE=0660
helper=v4l.sh
daemonlet=true

KERNEL=="*demux0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/demux0"
KERNEL=="*dvr0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/dvr0"
KERNEL=="*frontend0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/frontend0"
KERNEL=="*net0", SUBSYSTEM=="dvb", ATTRS{product}=="PCTV 290e", ATTRS{serial}=="00000006LKWJ", SYMLINK+="dvb/adapterPCTV290e/net0"
-----End of Content of /etc/vdev/actions/pctv290e.act-----

On return and reboot the system came up as described. I attempted to fix by login as root, rerun "/usr/share/vdev/vdev-install.sh vdev", reboot.

This made things worse and the boot process froze in the initrd stage and I had to use the power button to shurdown and recover by booting from a refracta
live USB stick, repairing the devuan partition, mounting & chrooting to the devuan partition then running "/usr/share/vdev/vdev-install.sh udev". This booted as normal to the GUI.

I then moved the file /etc/vdev/actions/pctv290e.act outside the vdev structure, ran "/usr/share/vdev/vdev-install.sh vdev" and rebooted. This booted as normal to the GUI

So it *appears* that vdev is not handling malfored rules/actions in a sensible way (or it might be me doing something really stupid!).
Obviously this would require further testing to prove and set out the steps to reproduce and to properly note the errors.
Shall I do this? If I do how/where file a bug report?

B)
I thought it would be helpful to watch what vdev was doing do I tried running vdevd in the foreground:
i) stop the deamon
/etc/init.d/vdev stop
ii) start vdevd in the foreground
vdevd -f -v1
This failed with the following error: "28581:00007FA49BEBF700: [ main.c:0053] main: ERROR: vdev_init rc = -22"

Any ideas what I did wrong?

Too hot to think? You need some good old Manchester cold grey drizzle!

ralph.ronnquist · 2017-01-07 23:29:12

ok. I've added (A) as issue for https://git.devuan.org/ralph.ronnquist/vdev. The daemon should indeed be robust against malformed action declarations as well as helper script errors.

Re (B): yes, most of the error messages are at a severe extreme of cryptic. Mostly they are s.c. standard error codes, and -22 would be called EINVAL. In your case, I'm guessing there was some output lines before that error line, such as:

Failed to set mountpoint, config->mountpoint = ...

or similar, which sometimes could help a geek to pinpoint the problem.

ralph.ronnquist · 2017-01-08 00:42:27

btw, re (8):

chrisw wrote:

8) I attached an external USB HDTV adapter (PCTV 290e) and the expected /dev/dvb devices were created.
However for to test this further on a proper multi-tuner mythtv backend (with the need for consistent and meaningful names), I would need to be able to recreate the following udev rules in vdev:
# PCTV 290e single tuner USB stick
# --------------------------------
# Create symlinks /dev/dvb/adapterPCTV290e/* pointing to PCTV 290e adapter (has unique attributes, so can find wherever it is)

I think I would consider having a separate naming script, with code like

ln -sTf adapter0  /dev/dvb/adapterPCTV290e

to be run when starting the mythtv app, or manually, rather than making it vdevd magic; especially since there might be several adapters of the same brand.

E.g., for my own TV system I have 4 receivers of the same brand, so I can't use your approach off hand. (A separate comment is that it's enough to symlink to the adapterX directory rather than symlink each "control interface" [or what it's called]) As you might know, the product name for /dev/dvb/adapterX is (currently) available at e.g.

cat /sys/class/dvb/dvbX.demux0/device/product

But, I suppose there could be a helper script improvement for this in some way.

ralph.ronnquist · 2017-01-08 11:21:28

As I restarted a vdev setup from scratch, I was reminded that the dvb adapter end points get rather restrictive file permissions, e.g:

crw------- 1 root root 212, 0 Jan  8 21:54 demux0
crw------- 1 root root 212, 1 Jan  8 21:54 dvr0
crw------- 1 root root 212, 3 Jan  8 21:54 frontend0
crw------- 1 root root 212, 2 Jan  8 21:54 net

This is something one can remedy by an action, say, "/etc/vdev/actions/dvb.act" as follows:

[vdev-action]
event=add
path=^dvb/adapter[0-9]+/[^/]+$
VAR_PERMISSIONS_GROUP=video
VAR_PERMISSIONS_MODE=0660
helper=permissions.sh

I.e., give rw permission for group video to all endpoints. I'm adding that action to the standard set in a forth-coming version.

The script in detail: the "event" category is limited to act on new path names, and the path name (following "/dev/") is restricted (through a POSIX regular expression) to the "adapterN/blah" end points. This action utilises the standard permissions setting helper, which makes good use of the given "VAR_*" variables.

The officially official Devuan Forum!

#1 2016-12-30 23:12:18

vdev testing

#2 2016-12-31 12:41:17

Re: vdev testing

#3 2016-12-31 13:55:55

Re: vdev testing

#4 2016-12-31 14:55:11

Re: vdev testing

#5 2016-12-31 15:11:54

Re: vdev testing

#6 2016-12-31 15:55:22

Re: vdev testing

#7 2017-01-01 17:52:11

Re: vdev testing

#8 2017-01-01 19:37:45

Re: vdev testing

#9 2017-01-06 06:09:49

Re: vdev testing

#10 2017-01-07 20:32:59

Re: vdev testing

#11 2017-01-07 23:29:12

Re: vdev testing

#12 2017-01-08 00:42:27

Re: vdev testing

#13 2017-01-08 11:21:28

Re: vdev testing

Board footer