Gentoo Archives: gentoo-user

From: Mike Edenfield <kutulu@××××××.org>
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 18:14:50
Message-Id: 004c01cd0dd7$3c15be00$b4413a00$
In Reply to: Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs? by Alan Mackenzie
1 > From: Alan Mackenzie [mailto:acm@×××.de]
3 > Hi, Mike.
4 >
5 > On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote:
6 > > > From: Alan Mackenzie [mailto:acm@×××.de]
7 >
8 > > > Hi, Alan.
9 >
10 > > > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote:
11 > > > > On Tue, 27 Mar 2012 21:24:22 +0000 Alan Mackenzie <acm@×××.de>
12 > > > > wrote:
13 >
14 > > > Why is nobody else on this thread willing to take up its main point,
15 > > > the exact equivalence between the known, ugly, initramfs solution
16 > > > and the as yet half-baked idea of putting the same binaries into
17 /sbin?
18 >
19 > > Well, for one, the initramfs solution is not generally considered "ugly"
20 > > except by a select vocal few who object to it on vague, unarticulated
21 > > grounds.
22 >
23 > I'll articulate a few. (i) The initramfs involves having two copies of
24 lots of
25 > software around. (ii) What's more, these two copies are often different,
26 one
27 > being built with static libraries, the other with dynamic ones. (iii)
28 This
29 > situation is not (as far as I know) yet handled by Portage, which means in
30 > building such software statically, you've got to save the dynamic version
31 > somewhere else whilst you're doing it. (iv) The initramfs requires a
32 > potentially long script to make it work.
34 > My idea was for /sbin to vanish from $PATH just as soon as the boot had
35 > been completed; PATH gets set anyway on the initialisation of something or
36 > other, so this would happen automatically, just like the initramfs
37 disappears
38 > when the switch_root is done.
40 The criticisms you made about an initramfs are valid, and your basic point
41 is correct: the ugliness of having a "shadow /sbin" is no worse than the
42 ugliness of an initramfs.
44 I admit that much of my criticism here is not of the idea but of trying to
45 come up with a working implementation. The major benefit of an initramfs
46 solution is that it fits into the existing Linux boot process with minimal
47 impact: all of the ugliness you pointed out vanishes as soon as it has
48 completed its work, and the existing /sbin/init startup code is launched
49 exactly as it would be without an initramfs. Your process would require
50 either changing that existing /sbin/init process, or changing the steps the
51 kernel takes on startup, in ways that I can't articulate because I haven't
52 gone through the exercise of making it work. Taking /sbin out of the path,
53 though works for me. As I understand it, /sbin *used* to be for "static
54 binaries", and only later did it retroactively become "system binaries",
55 which is silly. That's what DAC is for. The only benefit of a separate /bin
56 and /sbin is to have different binaries with the same name in both places,
57 which is just begging for trouble. Your approach actually seems to be
58 bringing /sbin back to its roots. :)
60 I can think of a few useful options, though; perhaps what you're calling
61 /sbin is actually /boot/bin; like now, /boot is rarely mounted once the live
62 system comes up. Perhaps the kernel is configured to look for and run a
63 /boot/bin/init before it tries to mount it's rootfs. You are basically
64 replicating the initramfs solution, just on the boot partition, as this is
65 almost exactly what happens now.
67 Alternatively, perhaps /sbin/init can get smarter; much of this problems
68 with getting /usr mounted at the right time stems from difficulties in
69 expressing the required order and dependency information in the init
70 scripts. If /sbin/init could be explicitly told "this is the 'mount my /usr'
71 script" and knew to run it or not, based on the existence of a /usr mount
72 point, that could happen very early in the boot process.
74 > > [ more criticism, a lot of which I accept. ]
75 >
76 > I think I have the elegant solution: that would be for the kernel to be
77 able to
78 > mount several partitions at system initialisation rather than just the
79 root
80 > partition. With this, all the issues we've been discussing simply
81 wouldn't
82 > arise.
84 That's one possible solution; I think there are several places where the
85 kernel could potentially be made "smarter" about what is going on in the
86 userland environment; for example, if udev always received block device
87 events first, *it* could be tasked with mounting /usr when it saw that
88 /dev/sda3 was available and in /etc/fstab, then it could happily run
89 alsaconf or bluetoothd or whatever else when those devices popped up. I also
90 admit I don't really understand autofs too much, but it seems like
91 automounter support should be able to do something like this as well.
93 Keep in mind, though, that the point of an initramfs is not to get /usr
94 mounted. It's to get / mounted; if your rootfs happens to be on some
95 hardware, network, or logical block device that needs special handling
96 before it can be used, you need *somewhere* to put those utilities that the
97 kernel can find them. The fact that you can also use an initramfs for all of
98 these other pre-init steps is just added benefit.
100 --Mike