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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng