> From: Alan Mackenzie [mailto:a...@muc.de] > > Hi, Alan. > > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: > > On Tue, 27 Mar 2012 21:24:22 +0000 > > Alan Mackenzie <a...@muc.de> 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. > > > Two words: > > > shared libraries > > > Copying binaries is not enough. You have to find and copy every shared > > library those binaries use. Plus all the data and other files they > > might need. > > > This is non-trivial. > > <silently screams>. It's equally non-trivial for initramfs, yet nobody > seems to be raising this objection for that. > > Why is nobody else on this thread willing to take up its main point, the > exact equivalence between the known, ugly, initramfs solution and the as > yet half-baked idea of putting the same binaries into /sbin?
Well, for one, the initramfs solution is not generally considered "ugly" except by a select vocal few who object to it on vague, unarticulated grounds. That notwithstanding: The binaries on the initramfs are not always the same as the ones installed in the system; frequently they are statically linked versions, or stripped-down versions, or otherwise unsuitable for being used after the full system is booted. (Dracut, for example, forces you to add USE=static-libs to a lot of the packages it wants to put into your initramfs image.) Putting those binaries into the execution path of the system is a bad idea because you don't always them to run once the system has booted -- I want the full set of udev rules, not the bare handful that my initramfs has on it. You could fix this by arranging for them to be put somewhere outside the normal path, where they can be found by the init system at boot-time but then ignored once /usr was up. This would also mean managing two copies of these packages on your system, which means the package manager would need to ensure that both static and dynamic versions, or full and minimal version, or whatever else, were built and installed in the correct locations. And this is ignoring the possible side-effects of reordering the boot scripts to unilaterally try to mount /usr very early; I don't know what, if any, those would be but someone would need to figure those out. The initramfs solution doesn't change the order of boot scripts, so people who are not using one see no change. Again, this is all *possible*. It is one option for solving the missing-/usr-at-boot problem, it is just not the option that has taken hold in the community. The people who are writing the software consider an initramfs a more elegant, cleaner, *less* ugly solution that what you are proposing, in the context of a general-purpose solution suitable for the most number of users. As they are the ones doing all the work, they get to make that call. The fact that most of us seem to agree with, or at least not actively disagree with, that opinion is just an added bonus. Your solution would be equally as successful at solving the problem, once someone put in the effort to actually make it work, make it repeatable, make it stable, and document/automate it for others to use. All of those steps have /already happened/ for an initramfs, so until someone comes up with a concrete reason why initramfs will not work, there is absolutely no motivation to waste time on anything else. --Mike
