1 |
Hey, William |
2 |
|
3 |
William Hubbs wrote: |
4 |
> Steven J Long wrote: |
5 |
>> Thing is it runs before the real init[1] so if we are using a separate |
6 |
>> /usr partition on LVM, will it still work? I'd have thought not, since we |
7 |
>> need the device-mapper service and there's /etc/lvm.conf to consider, but |
8 |
>> I'll gladly be told different. |
9 |
> |
10 |
> No, you are correct about this. This does not work if you have /usr on |
11 |
> lvm, mdadm, or encrypted. The same applies to /. That is the situation |
12 |
> where you would need an initramfs. |
13 |
> |
14 |
Let's not conflate the two: we never needed an initramfs before now*, unless |
15 |
/ were on lvm or mdadm (not sure about dmcrypt, but always thought it |
16 |
pointless without encrypting root.) |
17 |
|
18 |
So the touted solution to Chainsaw's problem, as raised to Council, doesn't |
19 |
actually work for that use-case, and there is still no official support for |
20 |
both setups. |
21 |
|
22 |
-- |
23 |
* If anyone wants to chip in with something along the lines of "you did but |
24 |
you didn't know it" or "this isn't safe" etc, please don't: I've heard it |
25 |
all before, and acknowledged technical points, and you'll just be adding |
26 |
noise and distracting from the topic. The users we're talking about have |
27 |
already set this up manually, if that's your concern. |
28 |
-- |
29 |
> I'm curious, have you seen our initramfs guide yet [1]? Making and using |
30 |
> an initramfs seems to be pretty well documented these days. |
31 |
> |
32 |
No, that is useful information to have, though all the detail is in links |
33 |
I've seen before. Also useful are: |
34 |
|
35 |
NeddySeagoon's Rough Guide to udev-182+: |
36 |
http://forums.gentoo.org/viewtopic-t-920644.html |
37 |
udeved's port of Arch's mkinitcpio: |
38 |
http://forums.gentoo.org/viewtopic-t-923168.html |
39 |
..which seems like a really nice tool to build an initramfs. |
40 |
|
41 |
But let's be frank: you're never going to persuade me, or many others[2], |
42 |
that merging udev and systemd, as well as / and /usr, and running an |
43 |
initramfs is the One True Way(TM). And the argument is boring, for all of us |
44 |
I'm sure, as the title of [2] should make clear. |
45 |
|
46 |
So, let's agree that no-one needs to fork udev at this stage. There /are/ |
47 |
methods that work flawlessly[3] with lvm and separate /usr with no |
48 |
initramfs, at least for now, should people care to explore them[4], and give |
49 |
feedback to improve them. |
50 |
|
51 |
What could spoil that and force a fork (or a switch to a patched mdev) |
52 |
instead of initscript-ordering? |
53 |
|
54 |
1) Random linkage into /usr/lib |
55 |
|
56 |
It's simple enough to check linkage, and while it would be nice if there |
57 |
were a portage feature to check any binaries installed to /bin /sbin or |
58 |
/lib* and ewarn if they link outside /lib* (QA otherwise), we can happily |
59 |
implement a portage bashrc hook to do it for us. Since every package manager |
60 |
uses a staged build and install, it doesn't matter what the end-user's |
61 |
filesystem layout is; even if they've munged all binaries into /usr, the |
62 |
image won't use symlinks, but contain directories. |
63 |
|
64 |
I accept that this is something we're going to have to handle on our own, |
65 |
since initramfs-people aren't interested in the data, as their scripts |
66 |
already automate pulling in dependent libs. |
67 |
|
68 |
But atm this is a non-issue. Running this one-liner: |
69 |
for f in /bin/* /sbin/*; do ldd "$f"|grep -q /usr || continue; echo "** $f"; |
70 |
ldd "$f"; done |
71 |
..shows only /sbin/umount.udisks, an optional desktop dep, linking to /usr |
72 |
here. |
73 |
|
74 |
Ultimately, we may need a tiny overlay for the few packages that are both |
75 |
A) required in early boot before localmount, in the opinion of someone who |
76 |
wants to submit an ebuild or patches to it, and: |
77 |
b) whose root-installed binaries link outside, or: |
78 |
c) it uses: econf --prefix=/usr and we'd like: |
79 |
econf --prefix=/ --exec-prefix=/usr |
80 |
and: |
81 |
D) where upstream is unresponsive, and: |
82 |
E) the ebuild maintainer doesn't want to accept a patch |
83 |
|
84 |
In most cases, we should be able to deal with (b) with portage hooks which |
85 |
move libs in "$D". I wouldn't like to do that automatically when a warning |
86 |
is flagged, though, as it should be specifically edited-in. |
87 |
|
88 |
2) Hard dependency on systemd |
89 |
|
90 |
This is the killer, and would force a fork, or we'd have to start work on |
91 |
extensions to mdev. Outside our control, and pointless to speculate on, |
92 |
though given recent feedback, the old kernel.org udev repo[5] is a reference |
93 |
point for anyone who wants to check it out. I'd personally be wary of any |
94 |
changes to udev in systemd's repo[6] going forward, although it would only |
95 |
be an issue if and when unstable udev stopped working for openrc users. |
96 |
|
97 |
Regards, |
98 |
Steve. |
99 |
|
100 |
> [1] http://www.gentoo.org/doc/en/initramfs-guide.xml |
101 |
[2] http://forums.gentoo.org/viewtopic-t-921140.html |
102 |
[3] http://forums.gentoo.org/viewtopic-t-901206.html |
103 |
[4] http://forums.gentoo.org/viewtopic-t-918466.html |
104 |
[5] http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary |
105 |
-- |
106 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |