[gentoo-dev] Implementing udev without an initramfs (Was: Stability of /sys api)

[Steven J Long]

Hey, William

William Hubbs wrote:
> Steven J Long wrote:
>> Thing is it runs before the real init[1] so if we are using a separate
>> /usr partition on LVM, will it still work? I'd have thought not, since we
>> need the device-mapper service and there's /etc/lvm.conf to consider, but
>> I'll gladly be told different.
>
> No, you are correct about this. This does not work if you have /usr on
> lvm, mdadm, or encrypted. The same applies to /. That is the situation
> where you would need an initramfs.
>
Let's not conflate the two: we never needed an initramfs before now*, unless 
/ were on lvm or mdadm (not sure about dmcrypt, but always thought it 
pointless without encrypting root.)

So the touted solution to Chainsaw's problem, as raised to Council, doesn't 
actually work for that use-case, and there is still no official support for 
both setups.

--
* If anyone wants to chip in with something along the lines of "you did but 
you didn't know it" or "this isn't safe" etc, please don't: I've heard it 
all before, and acknowledged technical points, and you'll just be adding 
noise and distracting from the topic. The users we're talking about have 
already set this up manually, if that's your concern.
--
> I'm curious, have you seen our initramfs guide yet [1]? Making and using
> an initramfs seems to be pretty well documented these days.
>
No, that is useful information to have, though all the detail is in links 
I've seen before. Also useful are:

NeddySeagoon's Rough Guide to udev-182+:
	http://forums.gentoo.org/viewtopic-t-920644.html
udeved's port of Arch's mkinitcpio:
	http://forums.gentoo.org/viewtopic-t-923168.html
..which seems like a really nice tool to build an initramfs.

But let's be frank: you're never going to persuade me, or many others[2], 
that merging udev and systemd, as well as / and /usr, and running an 
initramfs is the One True Way(TM). And the argument is boring, for all of us 
I'm sure, as the title of [2] should make clear.

So, let's agree that no-one needs to fork udev at this stage. There /are/ 
methods that work flawlessly[3] with lvm and separate /usr with no 
initramfs, at least for now, should people care to explore them[4], and give 
feedback to improve them.

What could spoil that and force a fork (or a switch to a patched mdev) 
instead of initscript-ordering?

1) Random linkage into /usr/lib

  It's simple enough to check linkage, and while it would be nice if there 
were a portage feature to check any binaries installed to /bin /sbin or 
/lib* and ewarn if they link outside /lib* (QA otherwise), we can happily 
implement a portage bashrc hook to do it for us. Since every package manager 
uses a staged build and install, it doesn't matter what the end-user's 
filesystem layout is; even if they've munged all binaries into /usr, the 
image won't use symlinks, but contain directories.

  I accept that this is something we're going to have to handle on our own, 
since initramfs-people aren't interested in the data, as their scripts 
already automate pulling in dependent libs.

  But atm this is a non-issue. Running this one-liner:
for f in /bin/* /sbin/*; do ldd "$f"|grep -q /usr || continue; echo "** $f";
ldd "$f"; done
..shows only /sbin/umount.udisks, an optional desktop dep, linking to /usr 
here.

 Ultimately, we may need a tiny overlay for the few packages that are both 
A) required in early boot before localmount, in the opinion of someone who 
wants to submit an ebuild or patches to it, and:
b) whose root-installed binaries link outside, or:
c) it uses: econf --prefix=/usr    and we'd like:
	  econf --prefix=/ --exec-prefix=/usr
and:
D) where upstream is unresponsive, and:
E) the ebuild maintainer doesn't want to accept a patch

  In most cases, we should be able to deal with (b) with portage hooks which 
move libs in "$D". I wouldn't like to do that automatically when a warning 
is flagged, though, as it should be specifically edited-in.

2) Hard dependency on systemd

  This is the killer, and would force a fork, or we'd have to start work on 
extensions to mdev. Outside our control, and pointless to speculate on, 
though given recent feedback, the old kernel.org udev repo[5] is a reference 
point for anyone who wants to check it out. I'd personally be wary of any 
changes to udev in systemd's repo[6] going forward, although it would only 
be an issue if and when unstable udev stopped working for openrc users.

Regards,
Steve.
 
> [1] http://www.gentoo.org/doc/en/initramfs-guide.xml
[2] http://forums.gentoo.org/viewtopic-t-921140.html
[3] http://forums.gentoo.org/viewtopic-t-901206.html
[4] http://forums.gentoo.org/viewtopic-t-918466.html
[5] http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)