On Tue, 27 Mar 2012 22:01:28 +0000 Alan Mackenzie <a...@muc.de> 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. Do we really have to spell out to you why this is a bad idea? > > 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. 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. This is not a small trivial issue, it is huge, and a magnificent bug-injection system. > 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. -- Alan McKinnnon alan.mckin...@gmail.com
