Gentoo Archives: gentoo-user

From: Alan Mackenzie <acm@×××.de>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Date: Thu, 29 Mar 2012 16:00:03
Message-Id: 20120329155628.GC2961@acm.acm
In Reply to: RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs? by Mike Edenfield
1 Hi, Mike.
3 On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote:
4 > > From: Alan Mackenzie [mailto:acm@×××.de]
6 > > Hi, Alan.
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:
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?
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.
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.
28 I think that qualifies the initramfs solution as ugly.
30 > That notwithstanding:
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.
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.
47 > [ more criticism, a lot of which I accept. ]
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.
54 I accept that this solution will never happen. Sadly.
56 > --Mike
58 --
59 Alan Mackenzie (Nuremberg, Germany).