On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote:
> Hi Isaac,
>
> [Snip]
>
> >
> > 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?
>
> Not sure; will find out and let you know if it makes a difference.

If you installed "busybox" and not "busybox-static", it's dynamically linked.

[snip]
> > -double-check that you have a non-empty passwd/groups file, containing
> > the same users/groups and world-readable.

> Does it have to be world-readable even if the chown(2) happens from a
> process with uid=0? I verified that they're non-empty, and verified that I
> was unable to (as root) use busybox chown from the initramfs shell.

In theory, you only need the process to be able to read /etc/passwd and
/etc/group, which should be enough for getpwent()/getgrent() to succeed.
Standard is chmod 0644, since every user and program may lookup the
username.

I've tried replicating, and cannot; I use busybox-static.
Example (from memory):

cat /etc/group
# note that "netdev" is a valid group
cat /etc/passwd
# note that only "root" is a user now
touch /tmp/tbnetdev
ls -l /tmp/tbnedev
# note that this is root:root
chown root:netdev /tmp/tbnetdev
ls -l /tmp/tbnetdev
# note that it is now root:netdev


> > 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.
>
> I will add ltrace (and ldd) to my initramfs and try this out :)

OK, I'm curious to hear your results.

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

> Thanks for the link! It's good to get feedback from someone who's packaged
> a device manager before :)

Glad to help.
Reading the mkinitramfs manpage, I see that "-d" looks like it would be
useful to you.

> Regarding setting up the initramfs, my experience is a bit more involved.
> I had to patch initramfs-tool's init script so it wouldn't try to mount
> devtmpfs, and wouldn't try to pull in udev config files or migrate udev's
> info from /run. This is because to the best of my knowledge, the only
> reason devtmpfs needs to be mounted at all is because udev no longer
> creates device files on its own (it only changes ownership and adds
> symlinks). However, using devtmpfs will be problematic for libudev-compat,
> which relies on inotify(2) to detect device changes (i.e. a device file
> that shows up in devtmpfs from the kernel does not generate an inotify
> event).

Rats.
Does mknod(...) = -1 EEXIST trigger an inotify event?

> > > 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.
>
> It's more involved than that--the /etc/vdev/ifnames.conf file needs to be
> generated from the host's network interfaces, for example (like the
> /etc/udev/rules.d directory). But obviously surmountable :)

Ah, yes. "*Persistent* device names".
Personally, I've never had an occasion to use them, and figure that
loading the drivers manually in order would be enough if I wanted that.

/sys/class/net/<interface>/ may have the information on Linux.

HTH,
Isaac Dunham