1 |
Hi, Mike. |
2 |
|
3 |
On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote: |
4 |
> > From: Alan Mackenzie [mailto:acm@×××.de] |
5 |
|
6 |
> > Hi, Alan. |
7 |
|
8 |
> > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: |
9 |
> > > On Tue, 27 Mar 2012 21:24:22 +0000 |
10 |
> > > Alan Mackenzie <acm@×××.de> wrote: |
11 |
|
12 |
> > Why is nobody else on this thread willing to take up its main point, |
13 |
> > the exact equivalence between the known, ugly, initramfs solution and |
14 |
> > the as yet half-baked idea of putting the same binaries into /sbin? |
15 |
|
16 |
> Well, for one, the initramfs solution is not generally considered "ugly" |
17 |
> except by a select vocal few who object to it on vague, unarticulated |
18 |
> grounds. |
19 |
|
20 |
I'll articulate a few. (i) The initramfs involves having two copies of |
21 |
lots of software around. (ii) What's more, these two copies are often |
22 |
different, one being built with static libraries, the other with dynamic |
23 |
ones. (iii) This situation is not (as far as I know) yet handled by |
24 |
Portage, which means in building such software statically, you've got to |
25 |
save the dynamic version somewhere else whilst you're doing it. (iv) The |
26 |
initramfs requires a potentially long script to make it work. |
27 |
|
28 |
I think that qualifies the initramfs solution as ugly. |
29 |
|
30 |
> That notwithstanding: |
31 |
|
32 |
> The binaries on the initramfs are not always the same as the ones installed |
33 |
> in the system; frequently they are statically linked versions, or |
34 |
> stripped-down versions, or otherwise unsuitable for being used after the |
35 |
> full system is booted. (Dracut, for example, forces you to add |
36 |
> USE=static-libs to a lot of the packages it wants to put into your initramfs |
37 |
> image.) Putting those binaries into the execution path of the system is a |
38 |
> bad idea because you don't always them to run once the system has booted -- |
39 |
> I want the full set of udev rules, not the bare handful that my initramfs |
40 |
> has on it. |
41 |
|
42 |
My idea was for /sbin to vanish from $PATH just as soon as the boot had |
43 |
been completed; PATH gets set anyway on the initialisation of something |
44 |
or other, so this would happen automatically, just like the initramfs |
45 |
disappears when the switch_root is done. |
46 |
|
47 |
> [ more criticism, a lot of which I accept. ] |
48 |
|
49 |
I think I have the elegant solution: that would be for the kernel to be |
50 |
able to mount several partitions at system initialisation rather than |
51 |
just the root partition. With this, all the issues we've been discussing |
52 |
simply wouldn't arise. |
53 |
|
54 |
I accept that this solution will never happen. Sadly. |
55 |
|
56 |
> --Mike |
57 |
|
58 |
-- |
59 |
Alan Mackenzie (Nuremberg, Germany). |