On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote:
> [TODO]
>
> * I still need to figure out how to generate /dev/disk/by-partuuid and
> /dev/v4l/by-path, and possibly others.

/dev/disk/by-partuuid does not exist on my udev-based Jessie install.
It would presumably be the PARTUUID="..." field of blkid.

/dev/v4l/by-path/ seems to be the output of some mutilation of the canonical
sysfs path, with convoluted rules for "deduplication" that are a bit beyond
me; I haven't looked, just compared these:
devinfo /dev/video0
ls /dev/v4l/by-path/

> * 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).

Theoretically, it *should* work if /etc/{passwd,group} are present in the
initramfs, with those paths. It's possible to mistakenly copy them to /
instead of /etc, but I assume that you've already checked that.

Detail that shouldn't make a difference but might:
static or non-static busybox?

A couple shots in the dark:
-check that you're using properly spelled usernames/groups, and that
$IFS isn't something weird.
-double-check that you have a non-empty passwd/groups file, containing
the same users/groups and world-readable.

To debug it:
-Add ltrace (with dependencies) and a *non-static* busybox to your
initramfs and try running
ltrace busybox chown USER:GROUP FILE

This shows you the functions that are called, so you can check if they
return success.

> * 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.

Check what I did with mdev (in hooks/ directory of github.com/idunham/mdev);
I did *not* find that initramfs-tools was at all tightly coupled with udev,
to the point that dropping the correct scripts into
/usr/share/initramfs-tools and convincing dpkg that it didn't need udev
was quite adequate.

However, you *will* need to take care that there is only one script moving
/dev to the target filesystem, or you will almost certainly get a failed
boot.

Also, I cannot comment on whether LVM et al. are tightly coupled with udev.

> 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

Install config files, marked as such.

> * installs our versions of the initramfs scripts for things like lvm,
> suspend/resume, etc.
> * disables the udev versions, but does not uninstall them

It will be non-trivial to disable another package's scripts while leaving
them installed, unless you divert them.
What I did was install scripts that would become a no-op if udev was still
installed.

> * safely builds the initramfs from our scripts.

See my mdev repo, especially debian/postinst and hooks/.


> * (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).

I doubt that you could make the device manager safely selectable via
alternatives, unless you install the interchangeable files in
/lib/<hotplugger>/, have that selectable via alternatives, and have
everything that can conflict symlink into /etc/alternatives/device-manager/
or a directory that symlinks to that.

This is needed because otherwise, you are inviting an inconsistent state
that can render a system unbootable.

For example, this might be udev/mdev/initramfs-tools:
/lib/udev-rd:
devmanager-hook
devmanager-top
devmanager-bottom

/lib/mdev-rd:
devmanager-hook
devmanager-top
devmanager-bottom

/etc/init.d:
udev
mdev

/usr/share/initramfs-tools/hooks/devmanager ->
    /etc/alternatives/rd-dev-manager/devmanger-hook
/usr/share/initramfs-tools/scripts/init-top/devmanager ->
    /etc/alternatives/rd-dev-manager/devmanager-top
/usr/share/initramfs-tools/scripts/init-bottom/devmanager ->
    /etc/alternatives/rd-dev-manager/devmanager-bottom

An alternative is just have udev/vdev/mdev all Provide:/Conflict: device-manager,
and initramfs-tools can depend on that; but this is clumsy.

Thanks,
Isaac Dunham