Gentoo Archives: gentoo-dev

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Implementing udev without an initramfs (Was: Stability of /sys api)
Date: Sat, 19 May 2012 19:33:20
Message-Id: jp8seq$s6a$
In Reply to: Re: [gentoo-dev] Re: Stability of /sys api by William Hubbs
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+: udeved's port of Arch's mkinitcpio: ..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 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. [2] [3] [4] [5];a=summary -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)