1 |
Hello again, Alan. |
2 |
|
3 |
On Wed, Mar 28, 2012 at 12:39:27AM +0200, Alan McKinnon wrote: |
4 |
> On Tue, 27 Mar 2012 22:01:28 +0000 |
5 |
> Alan Mackenzie <acm@×××.de> wrote: |
6 |
|
7 |
> > Hello, Neil. |
8 |
|
9 |
> > On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote: |
10 |
> > > On Tue, 27 Mar 2012 21:24:22 +0000, Alan Mackenzie wrote: |
11 |
|
12 |
> > > > That is precisely what the question was NOT about. The idea was |
13 |
> > > > to copy (not move) booting software to /sbin instead of an |
14 |
> > > > initramfs - the exact same programs, modulo noise - to have the |
15 |
> > > > SW in /sbin necessary to mount /usr. |
16 |
|
17 |
> > > Your package manager only knows about the copy in the original |
18 |
> > > location. |
19 |
|
20 |
> > So? The same applies to a copy in the initramfs. |
21 |
|
22 |
> No it doesn't. The initramfs is a transient file system contained |
23 |
> within a single file. To the package manager, it is just a file, one |
24 |
> with a rather unique name that portage is highly unlikely to try and |
25 |
> overwrite. |
26 |
|
27 |
> Copying binaries into / means you are copying a large number of files |
28 |
> into an area managed by the package manager. Those files have names and |
29 |
> locations that are rather likely to be used by ebuilds. |
30 |
|
31 |
Ah. I was looking forward to the sad time when package managers will be |
32 |
installing things exclusively on /usr. Well, OK, on /etc too, but |
33 |
certainly not to /sbin (which will probably have been abolished). |
34 |
|
35 |
> Do we really have to spell out to you why this is a bad idea? |
36 |
|
37 |
No, I can get that. ;-) |
38 |
|
39 |
> > > When you update you'll have multiple versions of the same program or |
40 |
> > > library in your path. |
41 |
|
42 |
> > Well, with the manual/script copying which needs doing either |
43 |
> > for /sbin or initramfs, that will be several copies of a program, not |
44 |
> > several versions. |
45 |
|
46 |
> Your copies will be used in preference to the originals in /usr. You |
47 |
> will have to detect this yourself when this occurs and re-copy them and |
48 |
> portage cannot help you. |
49 |
|
50 |
I was thinking of using /sbin for booting, then removing it from $PATH as |
51 |
soon as /usr gets mounted. |
52 |
|
53 |
> Remember the primary difference between / and an initramfs: |
54 |
|
55 |
> The initramfs is transient and it's contents are not available to |
56 |
> confuse the system once early boot is over. |
57 |
|
58 |
> / is a permanent file system that is always around, and always there to |
59 |
> confuse the issue. |
60 |
|
61 |
OK. I take /sbin off $PATH, like I said above. |
62 |
|
63 |
> This is not a small trivial issue, it is huge, and a magnificent |
64 |
> bug-injection system. |
65 |
|
66 |
OK2. I don't like BI systems. |
67 |
|
68 |
> > I'm still trying to see the reason why an /sbin with the same |
69 |
> > contents as a putative initramfs won't work. |
70 |
|
71 |
> Oh, it will work for booting all right. It's the issues it will cause |
72 |
> after booting when it should no longer be there that is the problem. |
73 |
|
74 |
We're going to be stuck with some issues anyway, no matter how we cope |
75 |
with things. At the moment, I've got my /usr on RAID1, which I think |
76 |
doubles up the speed things load at. (It's on LVM2 too, but that's by |
77 |
the way.) I really don't want a fragile initramfs. Sooner or later, I'd |
78 |
put some slight glitch into it and the result would be a dead PC. Either |
79 |
that or I'll be scared stiff of touching it, which isn't how a Gentoo |
80 |
user is supposed to be. Do I really want to take my /usr off RAID1, just |
81 |
so I can amalgamate it with /? |
82 |
|
83 |
There's no getting round duplicating executables once the single /usr |
84 |
crowd have got their way. The only question is where you put the |
85 |
duplicates, and how you make sure they don't foul things up. |
86 |
|
87 |
|
88 |
> -- |
89 |
> Alan McKinnnon |
90 |
> alan.mckinnon@×××××.com |
91 |
|
92 |
-- |
93 |
Alan Mackenzie (Nuremberg, Germany). |