Hello again, Alan. On Wed, Mar 28, 2012 at 12:39:27AM +0200, Alan McKinnon wrote: > On Tue, 27 Mar 2012 22:01:28 +0000 > Alan Mackenzie <[email protected]> wrote:
> > Hello, Neil. > > On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote: > > > On Tue, 27 Mar 2012 21:24:22 +0000, Alan Mackenzie wrote: > > > > That is precisely what the question was NOT about. The idea was > > > > to copy (not move) booting software to /sbin instead of an > > > > initramfs - the exact same programs, modulo noise - to have the > > > > SW in /sbin necessary to mount /usr. > > > Your package manager only knows about the copy in the original > > > location. > > So? The same applies to a copy in the initramfs. > No it doesn't. The initramfs is a transient file system contained > within a single file. To the package manager, it is just a file, one > with a rather unique name that portage is highly unlikely to try and > overwrite. > Copying binaries into / means you are copying a large number of files > into an area managed by the package manager. Those files have names and > locations that are rather likely to be used by ebuilds. Ah. I was looking forward to the sad time when package managers will be installing things exclusively on /usr. Well, OK, on /etc too, but certainly not to /sbin (which will probably have been abolished). > Do we really have to spell out to you why this is a bad idea? No, I can get that. ;-) > > > When you update you'll have multiple versions of the same program or > > > library in your path. > > Well, with the manual/script copying which needs doing either > > for /sbin or initramfs, that will be several copies of a program, not > > several versions. > Your copies will be used in preference to the originals in /usr. You > will have to detect this yourself when this occurs and re-copy them and > portage cannot help you. I was thinking of using /sbin for booting, then removing it from $PATH as soon as /usr gets mounted. > Remember the primary difference between / and an initramfs: > The initramfs is transient and it's contents are not available to > confuse the system once early boot is over. > / is a permanent file system that is always around, and always there to > confuse the issue. OK. I take /sbin off $PATH, like I said above. > This is not a small trivial issue, it is huge, and a magnificent > bug-injection system. OK2. I don't like BI systems. > > I'm still trying to see the reason why an /sbin with the same > > contents as a putative initramfs won't work. > Oh, it will work for booting all right. It's the issues it will cause > after booting when it should no longer be there that is the problem. We're going to be stuck with some issues anyway, no matter how we cope with things. At the moment, I've got my /usr on RAID1, which I think doubles up the speed things load at. (It's on LVM2 too, but that's by the way.) I really don't want a fragile initramfs. Sooner or later, I'd put some slight glitch into it and the result would be a dead PC. Either that or I'll be scared stiff of touching it, which isn't how a Gentoo user is supposed to be. Do I really want to take my /usr off RAID1, just so I can amalgamate it with /? There's no getting round duplicating executables once the single /usr crowd have got their way. The only question is where you put the duplicates, and how you make sure they don't foul things up. > -- > Alan McKinnnon > [email protected] -- Alan Mackenzie (Nuremberg, Germany).
