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