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 |