1 |
On Wed, Mar 28, 2012 at 12:55:20AM +0200, Alan McKinnon wrote: |
2 |
> > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: |
3 |
> > > On Tue, 27 Mar 2012 21:24:22 +0000 |
4 |
> > > Alan Mackenzie <acm@×××.de> wrote: |
5 |
|
6 |
> > > > That is precisely what the question was NOT about. The idea was |
7 |
> > > > to copy (not move) booting software to /sbin instead of an |
8 |
> > > > initramfs - the exact same programs, modulo noise - to have the |
9 |
> > > > SW in /sbin necessary to mount /usr. |
10 |
|
11 |
> > > Two words: |
12 |
|
13 |
> > > shared libraries |
14 |
|
15 |
> > > Copying binaries is not enough. You have to find and copy every |
16 |
> > > shared library those binaries use. Plus all the data and other |
17 |
> > > files they might need. |
18 |
|
19 |
> > > This is non-trivial. |
20 |
|
21 |
> > <silently screams>. It's equally non-trivial for initramfs, yet |
22 |
> > nobody seems to be raising this objection for that. |
23 |
|
24 |
> > Why is nobody else on this thread willing to take up its main point, |
25 |
> > the exact equivalence between the known, ugly, initramfs solution and |
26 |
> > the as yet half-baked idea of putting the same binaries into /sbin? |
27 |
|
28 |
|
29 |
> Read my other mail and pay attention to the difference between |
30 |
> transient and persistent. |
31 |
|
32 |
In my proposed solution, the executables in /sbin would only exist until |
33 |
/usr had been mounted and the runtime PATH set up. After the unification |
34 |
of /usr, /sbin won't even exist (apart from in schemes like mine). |
35 |
|
36 |
> initramfs is an elegant engineering solution (albeit over-engineered |
37 |
> for our specific case of being Gentoo users). |
38 |
|
39 |
Maybe, maybe not. It couples the various bits of booting more tighly |
40 |
together. I look at Allan Gottlieb's bug "WARNING latest lvm2 breaks |
41 |
systems with older udev", and note that he recovered, essentially, by |
42 |
mounting non-/ partitions by hand and going back to an old lvm2 version. |
43 |
I had a similar problem when I was first trying out Walter's mdev |
44 |
solution, which I also recovered by mounting by hand. |
45 |
|
46 |
I look forward with foreboding to the time when such recovery will not be |
47 |
possible. Only a legacy Gentoo system or a recovery CD will help then. |
48 |
I think it highly probable that "can't boot" bugs will continue to happen |
49 |
occasionally. I'd like to carry on having a bootable skeleton system for |
50 |
when this happens. |
51 |
|
52 |
> Your questions are about an extremely ill-advised action that has no |
53 |
> sound basis. It copies stuff around to make one very specific thing |
54 |
> work but with zero consideration for what it will do to everything |
55 |
> else. That is bad, bad engineering. |
56 |
|
57 |
I don't think that's a fair summary. |
58 |
|
59 |
> If you want all this stuff in /, then do it correctly and modify the |
60 |
> ebuilds to put the originals there (and troubleshoot the fallout from |
61 |
> other faulty hard-coded stuffs). This is a lot of work, but it is sound. |
62 |
|
63 |
I doubt that would work, for the reasons you give. |
64 |
|
65 |
I feel I've been needlessly slammed, all for articulating an interesting |
66 |
idea. |
67 |
|
68 |
> -- |
69 |
> Alan McKinnnon |
70 |
> alan.mckinnon@×××××.com |
71 |
|
72 |
-- |
73 |
Alan Mackenzie (Nuremberg, Germany). |