On 29/04/15 02:03, Jude Nelson wrote:
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
Hello Jude,
Thanks a lot for the update.
I have pulled your latest commit
(https://github.com/jcnelson/vdev/commit/d402d549bfb7bc7922f59e3b91f523bac9a22ff2),
compiled and installed them as per your INSTALL.md instruction. However,
I cannot proceed further as the build of initramfs failed.
I initially did that on my HP 8530w PC. I realised that the installation
changed and removed some important files, like removing
/etc/init.d/udev. So I think for now on, I will use my D945GCLF Mini-ITX
PC that I dedicate it for testing your vdev and any other Devuan
packages. Please let me know whether this Mini-ITX board would be enough
for the testing or not. If it is too old, I have 2 other newer Mini-ITX
boards so I can just replace it.
I raised 2 issues on your vdev github repository to record my testing
results, i.e. https://github.com/jcnelson/vdev/issues/21 and
https://github.com/jcnelson/vdev/issues/22. So we can have discussions
there and minimise the noise that I make in this mailing list.
Cheers,
Anto
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
