1 |
> From: Alan Mackenzie [mailto:acm@×××.de] |
2 |
> |
3 |
> Hi, Alan. |
4 |
> |
5 |
> On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: |
6 |
> > On Tue, 27 Mar 2012 21:24:22 +0000 |
7 |
> > Alan Mackenzie <acm@×××.de> wrote: |
8 |
> |
9 |
> > > That is precisely what the question was NOT about. The idea was to |
10 |
> > > copy (not move) booting software to /sbin instead of an initramfs - |
11 |
> > > the exact same programs, modulo noise - to have the SW in /sbin |
12 |
> > > necessary to mount /usr. |
13 |
> |
14 |
> > Two words: |
15 |
> |
16 |
> > shared libraries |
17 |
> |
18 |
> > Copying binaries is not enough. You have to find and copy every shared |
19 |
> > library those binaries use. Plus all the data and other files they |
20 |
> > might need. |
21 |
> |
22 |
> > This is non-trivial. |
23 |
> |
24 |
> <silently screams>. It's equally non-trivial for initramfs, yet nobody |
25 |
> seems to be raising this objection for that. |
26 |
> |
27 |
> Why is nobody else on this thread willing to take up its main point, the |
28 |
> exact equivalence between the known, ugly, initramfs solution and the as |
29 |
> yet half-baked idea of putting the same binaries into /sbin? |
30 |
|
31 |
Well, for one, the initramfs solution is not generally considered "ugly" |
32 |
except by a select vocal few who object to it on vague, unarticulated |
33 |
grounds. That notwithstanding: |
34 |
|
35 |
The binaries on the initramfs are not always the same as the ones installed |
36 |
in the system; frequently they are statically linked versions, or |
37 |
stripped-down versions, or otherwise unsuitable for being used after the |
38 |
full system is booted. (Dracut, for example, forces you to add |
39 |
USE=static-libs to a lot of the packages it wants to put into your initramfs |
40 |
image.) Putting those binaries into the execution path of the system is a |
41 |
bad idea because you don't always them to run once the system has booted -- |
42 |
I want the full set of udev rules, not the bare handful that my initramfs |
43 |
has on it. |
44 |
|
45 |
You could fix this by arranging for them to be put somewhere outside the |
46 |
normal path, where they can be found by the init system at boot-time but |
47 |
then ignored once /usr was up. This would also mean managing two copies of |
48 |
these packages on your system, which means the package manager would need to |
49 |
ensure that both static and dynamic versions, or full and minimal version, |
50 |
or whatever else, were built and installed in the correct locations. And |
51 |
this is ignoring the possible side-effects of reordering the boot scripts to |
52 |
unilaterally try to mount /usr very early; I don't know what, if any, those |
53 |
would be but someone would need to figure those out. The initramfs solution |
54 |
doesn't change the order of boot scripts, so people who are not using one |
55 |
see no change. |
56 |
|
57 |
Again, this is all *possible*. It is one option for solving the |
58 |
missing-/usr-at-boot problem, it is just not the option that has taken hold |
59 |
in the community. The people who are writing the software consider an |
60 |
initramfs a more elegant, cleaner, *less* ugly solution that what you are |
61 |
proposing, in the context of a general-purpose solution suitable for the |
62 |
most number of users. As they are the ones doing all the work, they get to |
63 |
make that call. The fact that most of us seem to agree with, or at least not |
64 |
actively disagree with, that opinion is just an added bonus. |
65 |
|
66 |
Your solution would be equally as successful at solving the problem, once |
67 |
someone put in the effort to actually make it work, make it repeatable, make |
68 |
it stable, and document/automate it for others to use. All of those steps |
69 |
have /already happened/ for an initramfs, so until someone comes up with a |
70 |
concrete reason why initramfs will not work, there is absolutely no |
71 |
motivation to waste time on anything else. |
72 |
|
73 |
--Mike |