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 ;-)
