:: [Dng] [dng] vdev status updates
Góra strony
Delete this message
Reply to this message
Autor: Jude Nelson
Data:  
Dla: dng@lists.dyne.org
Temat: [Dng] [dng] vdev status updates
Hey everyone,

Sorry for being incommunicado these past two weeks--I was working on a
conference paper that was due last Friday. Thank you all for being patient!

I have the latest news for vdev:

[Status updates]

* Support for booting from LVM2 volumes has been added. vdevd will create
all /dev/VG/LV links, /dev/mapper/ symlinks, and
/dev/disk/by-id/lvm-pv-uuid-XXX links. I have successfully used vdev to
boot the Devuan QEMU image from April 24--the one with root and swap on LVM.

* Support for /dev/input/by-id has been added, but needs testing. In
particular, I'm not sure what kinds of devices other than USB input devices
go here. I think maybe old serial and MIDI joysticks might go here, but I
do not have any to test on (let alone a computer with a COM or MIDI port).
If you're not seeing a device symlink that should be here, please let me
know.

* vdevd's helper scripts now set device ownership and permissions
correctly, instead of defaulting to root.root and 0600.

[Development]

* Under the hood, I've refactored vdev's subr.sh shell library, such that
each vdev-specific method is appropriately prefixed (with "vdev_").

* With Scooby's help, I'm getting a list going for package dependencies
going for vdevd's helper scripts, to make it easier to package vdev. The
list is in pkg/dependencies.txt.

[Integration Testing]

* Scooby, Tom H, and Anto have been hitting vdev hard, and Scooby has been
able to boot to desktop with vdevd (but first by writing an xorg.conf).
Their reports have been instrumental in closing the functionality gap
between vdevd and udevd. Thank you to everyone who participated!

* On initramfs testing: Anto has helped me uncover some problems with my
very early, very hack-ish makefile for generating initramfs images. I
think the latest commit should fix at least some of the problems (but not
all of them), but I have not had time to look into whether or not the
process works for file-rc.

[TODO]

* I still need to figure out how to generate /dev/disk/by-partuuid and
/dev/v4l/by-path, and possibly others.

* Packaging. I'm working on a way to automatically build a .deb for vdevd
that will, among other things, safely generate and install an initramfs
without having to hack the initramfs tools (as is the case today). Please
see [Help Wanted].

* libudev-compat. No ETA on this, but I'm going to try to make some
progress on it next week. Fortunately, a lot of programs can be compiled
without libudev, so it's not as high of a priority right now.

[Help Wanted]

* Astute readers may notice that one method in vdev/helpers/LINUX/subr.sh
is called vdev_chown. This is because for whatever reason, Debian's
busybox chown does not accept usernames and group names when running in the
initramfs. I have tried:
-- copying over /etc/passwd, /etc/passwd-, /etc/group, /etc/group- to the
initramfs.
-- using GNU chown.
-- strace-ing both GNU chown and busybox to confirm that they access
/etc/passwd and /etc/group.

It does not appear to be specific to busybox chown; busybox ls doesn't
resolve UIDs and GIDs to usernames and groups either, for example. Anyone
familiar with busybox on this list want to weigh in? The vdev_chown shell
method is clearly a hack and I'd love to be rid of it, but until I figure
out why busybox chown is misbehaving, it's necessary to set device file
ownership in the initramfs (i.e. I think it's less evil than using opaque
UIDs and GIDs in vdevd's helper scripts).

* As Anto's experience shows, getting a working initramfs is tedious to do
and easy to get wrong. This is not only because there are multiple init
systems that vdevd will need to work with (e.g. sysv-rc, file-rc, openrc,
etc.), but also init scripts and initramfs scripts that come from packages
that depend on udev are (unsurprisingly) tightly coupled to udev. This
makes it difficult to install vdevd on a running Debian system without
removing udev (which is in itself undesirable, since it will take a large
swath of packages out with it), since I have to pretty much fork both sets
of scripts and try to mash them up into a custom initramfs without altering
/usr/share/initramfs-tools. This is effectively what my (extremely kludgy)
initramfs Makefile does.

What I'm going to make my next priority is making a .deb for vdevd that
automatically generates the initramfs in a "safe" manner. I'd need to do
this in a way that disables, but does not remove the udev scripts. This is
easier said than done due to tight integration with udev, but I don't think
it's insurmountable.

What we'll need is a well-written .deb post-install script that:
* sets up config files needed to generate persistent device names
* installs our versions of the initramfs scripts for things like lvm,
suspend/resume, etc.
* disables the udev versions, but does not uninstall them
* safely builds the initramfs from our scripts.
* (long-term) does the above in a way that is agnostic to the device
manager, since there are real-world use-cases for selecting mdev or a
static /dev/ over udev or vdev.

(That last point is why I'd like to work on making it possible to select a
device manager via the alternatives system--the user should be able to pick
whatever device manager they need, but without having to jump through all
these hoops).

That's all for now,
Jude