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: Tue, 27 Mar 2012 19:57:55
Message-Id: 003e01cd0c53$a2e99b90$e8bcd2b0$@kutulu.org
In Reply to: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs? by che@chrekh.se
1 > From: che@××××××.se [mailto:che@××××××.se]
2 >
3 > Neil Bothwick <neil@××××××××××.uk> writes:
4 >
5 > > On Tue, 27 Mar 2012 14:26:46 +0000, Alan Mackenzie wrote:
6 > >
7 > >> > As you move more and more software off of /usr into / you start to
8 > >> > realize that the idea of "tiny partition that contains just what I
9 > >> > need to boot and mount /usr" is becoming "not so tiny" anymore. The
10 > >> > distinction between what is "boot" software versus "user" software
11 > >> > gets less clear.
12 > >>
13 > >> Again, isn't this the same for an initramfs?
14 > >
15 > > No, because an initramfs only needs enough to mount / and /usr, then
16 > > everything else comes from the usual source. If you're not using and
17 > > fancy block devices, the initramfs only needs busybox and an init
18 script.
19 > > Even adding LVM, RAID and encryption only requires three more binaries
20 > > - and those are all disposed of once switch_root is run and the tmpfs
21 > > released.
22 >
23 > The question remains. If it's possible to do that from an initramfs, then
24 > shouldn't it be possible to put the same tools and binarias on /, and
25 mount
26 > /usr early?
27 >
28
29 Yes , of course it's /possible/, it's just not /practical/.
30
31 Changing the contents of your initramfs is a decision you, as an admin, make
32 that affects your system(s).
33
34 Changing the installed location of, say, udevd and bluetoothd and whatever
35 other tools need to get pulled out of /usr is a decision that affects
36 everyone who is using those packages. Changing the order of init scripts is
37 an even bigger mess, but mostly because of the software requirements to make
38 it function.
39
40 Most Linux users, by a vast but very silent majority, are plenty happy to
41 put / and /usr on one partition, wipe their hands on their pants, and move
42 on with life. Thus, the people developing and packaging those required boot
43 packages can leave them right where they are, and everything works. Some
44 Linux users have reasons (largely legitimate ones) why this is not a valid
45 option. Those users have three choices
46
47 * Move the required packages away from their default installation locations
48 on their machines, as you're suggestion, and fix the order of your boot
49 scripts to mount /usr earlier than anything that needs it.
50 * Install (or develop) alternative versions of the tools that do not have
51 the same boot-time requirements, thus allowing you to ignore the whole mess.
52 This is what Walt and his mdev team are making happen.
53 * Use an initramfs to do whatever specific thing your machine(s) need to do
54 to make the rest of the software work out-of-the-box.
55
56 So, it's not a matter of one choice working and one not. It's a matter of
57 one choice being much lower maintenance for the people donating their time
58 to produce the software in the first place. If someone (maybe you) were to
59 figure out the actual steps needed to mount /usr early in the boot, without
60 and initramfs, without swapping out udev for busybox or whatever, I'm sure a
61 lot of people would be interested in seeing how that's done. There's a
62 possibility that it turns out to be way easier than anyone thought, and that
63 supporting a split /usr becomes "no big deal". In practice, I'm going to
64 guess that it turns out to be a way bigger maintenance nightmare (and
65 probably more fragile) than:
66
67 root # emerge dracut
68 root # dracut -H
69
70 And probably won't be something that the developers or package maintainers
71 are going to commit to supporting.
72
73 --Mike

Replies