1 |
> From: Alan Mackenzie [mailto:acm@×××.de] |
2 |
> Sent: Tuesday, March 27, 2012 10:27 AM |
3 |
> |
4 |
> On Tue, Mar 27, 2012 at 10:02:02AM -0400, Mike Edenfield wrote: |
5 |
> > > From: Alan Mackenzie [mailto:acm@×××.de] |
6 |
> > > Sent: Tuesday, March 27, 2012 9:37 AM |
7 |
> |
8 |
> > > My question: what, technically, prevents me from copying the booting |
9 |
> > > software instead to /sbin and booting the system that way? |
10 |
> |
11 |
> > Nothing; in fact, this was the general solution to the problem of |
12 |
> > "something else in /usr/{sbin,bin,lib} is needed at boot" for a long |
13 |
> > time. More and more software was getting moved into /{s,}bin, and in |
14 |
> > particular into /lib, to make it available in the early boot stages. |
15 |
> |
16 |
> > There's nothing wrong with that, as long as you can ensure that any |
17 |
> > hard-coded paths to those binaries are updated properly. |
18 |
> |
19 |
> Surely this is the same, whether one copies the booting software to |
20 |
initramfs |
21 |
> or /sbin, isn't it? |
22 |
|
23 |
No, because very little of my booting software is on my initramfs; it |
24 |
contains the kernel modules for my SATA drive and a script to mount /usr |
25 |
before launching /sbin/init. You *could* build an initramfs that included |
26 |
all of those other items, including udev and fsck tools if you wanted to, |
27 |
but you don't have to. (You might want to, for example, to have a more |
28 |
fully-features rescue shell, but I have a LiveCD for that.) |
29 |
|
30 |
The difference is what part of the booting process you need the software |
31 |
for. Without an initramfs, your boot loader loads your kernel, your kernel |
32 |
launches /sbin/init, and /sbin/init starts running your startup scripts. |
33 |
Everything that needs to happen must happen in those startup scripts. The |
34 |
problems occur when script #1 (say, start udev) sometimes needs script #2 |
35 |
(mount /usr) to have run, but script #2 sometimes needs script #1 to have |
36 |
run. You can solve this in a number of ways: |
37 |
|
38 |
* Fix script #1 to never need script #2 (move everything you need off /usr) |
39 |
* Fix script #2 to never need script #1 (put /usr on the same partition as |
40 |
/sbin/init) |
41 |
* Adjust the order of the scripts on a case-by-case bases (move script #2 to |
42 |
an initrd when needed) |
43 |
|
44 |
Option one has traditionally been the way to solve these kinds of problems, |
45 |
but with dynamic linking and external hooks the reach of the boot-time |
46 |
software is getting overly broad. Option #2 is the simplest and lowest-risk |
47 |
option, but not everyone has a hardware configuration that makes that a |
48 |
viable choice. So option #3 is basically "you do whatever you have to do to |
49 |
get a /usr before /sbin/init runs." |
50 |
|
51 |
> > As you move more and more software off of /usr into / you start to |
52 |
> > realize that the idea of "tiny partition that contains just what I |
53 |
> > need to boot and mount /usr" is becoming "not so tiny" anymore. The |
54 |
> > distinction between what is "boot" software versus "user" software gets |
55 |
> less clear. |
56 |
> |
57 |
> Again, isn't this the same for an initramfs? |
58 |
|
59 |
This part is, true, but the point of an initramfs is that, once you switch |
60 |
over to init, the initramfs is out of the picture. With a traditional boot, |
61 |
the stuff you move into your rootfs to make booting work is there forever. |
62 |
With an initramfs, you don't need (for example) all of the udev rules and |
63 |
libraries and such; you just need enough statically linked binaries to mount |
64 |
/usr; when the init switch happens, your real, production binaries show up |
65 |
and the trimmed-down copies from your initramfs go away. |
66 |
|
67 |
> > Then it's just question of how far you take this process before you |
68 |
> > reach your personal threshold of questioning why you have two |
69 |
> > partitions at all. Whether you reach that point or not depends on how |
70 |
> > complex your boot process is, what you actually need running to boot, |
71 |
> > and how personally invested in a split /usr you happen to be :) |
72 |
> |
73 |
> I've decided that, if push comes to shove, I'm going to go for /usr on / |
74 |
rather |
75 |
> than a fragile initramfs system. I've got everything bar / on RAID 1/LVM |
76 |
at |
77 |
> the moment, but I don't really use LVM, so I could dismantle that too, |
78 |
losing |
79 |
> all the baggage that brings with it. |
80 |
|
81 |
I'm using both on most of my systems now, though admittedly on my laptop |
82 |
it's just to get the boot animation from plymouth :) |
83 |
|
84 |
> Having said that, my system (including Gnome) is working perfectly well |
85 |
with |
86 |
> mdev, and see no reason why that shouldn't continue. |
87 |
|
88 |
And that's a perfectly legitimate option; you're continuing to use a process |
89 |
that has worked for decades. The problem with that option is not that it |
90 |
doesn't work for plenty of people, it's that it doesn't *scale* very well. |
91 |
If you're writing the software that needs to work out-of-the-box for every |
92 |
Fedora/Debian/Gentoo/etc system installed from this point forward, you need |
93 |
to worry about scale. If you're setting up a few hundred nearly identical |
94 |
servers with much more limited hardware that is under your direct control, |
95 |
you can focus your solution to a much narrow scope. |