> From: Alan Mackenzie [mailto:a...@muc.de]
> Hi, Mike. > > On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote: > > > 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: > > > > 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. > > I'll articulate a few. (i) The initramfs involves having two copies of lots of > software around. (ii) What's more, these two copies are often different, one > being built with static libraries, the other with dynamic ones. (iii) This > situation is not (as far as I know) yet handled by Portage, which means in > building such software statically, you've got to save the dynamic version > somewhere else whilst you're doing it. (iv) The initramfs requires a > potentially long script to make it work. > My idea was for /sbin to vanish from $PATH just as soon as the boot had > been completed; PATH gets set anyway on the initialisation of something or > other, so this would happen automatically, just like the initramfs disappears > when the switch_root is done. The criticisms you made about an initramfs are valid, and your basic point is correct: the ugliness of having a "shadow /sbin" is no worse than the ugliness of an initramfs. I admit that much of my criticism here is not of the idea but of trying to come up with a working implementation. The major benefit of an initramfs solution is that it fits into the existing Linux boot process with minimal impact: all of the ugliness you pointed out vanishes as soon as it has completed its work, and the existing /sbin/init startup code is launched exactly as it would be without an initramfs. Your process would require either changing that existing /sbin/init process, or changing the steps the kernel takes on startup, in ways that I can't articulate because I haven't gone through the exercise of making it work. Taking /sbin out of the path, though works for me. As I understand it, /sbin *used* to be for "static binaries", and only later did it retroactively become "system binaries", which is silly. That's what DAC is for. The only benefit of a separate /bin and /sbin is to have different binaries with the same name in both places, which is just begging for trouble. Your approach actually seems to be bringing /sbin back to its roots. :) I can think of a few useful options, though; perhaps what you're calling /sbin is actually /boot/bin; like now, /boot is rarely mounted once the live system comes up. Perhaps the kernel is configured to look for and run a /boot/bin/init before it tries to mount it's rootfs. You are basically replicating the initramfs solution, just on the boot partition, as this is almost exactly what happens now. Alternatively, perhaps /sbin/init can get smarter; much of this problems with getting /usr mounted at the right time stems from difficulties in expressing the required order and dependency information in the init scripts. If /sbin/init could be explicitly told "this is the 'mount my /usr' script" and knew to run it or not, based on the existence of a /usr mount point, that could happen very early in the boot process. > > [ more criticism, a lot of which I accept. ] > > I think I have the elegant solution: that would be for the kernel to be able to > mount several partitions at system initialisation rather than just the root > partition. With this, all the issues we've been discussing simply wouldn't > arise. That's one possible solution; I think there are several places where the kernel could potentially be made "smarter" about what is going on in the userland environment; for example, if udev always received block device events first, *it* could be tasked with mounting /usr when it saw that /dev/sda3 was available and in /etc/fstab, then it could happily run alsaconf or bluetoothd or whatever else when those devices popped up. I also admit I don't really understand autofs too much, but it seems like automounter support should be able to do something like this as well. Keep in mind, though, that the point of an initramfs is not to get /usr mounted. It's to get / mounted; if your rootfs happens to be on some hardware, network, or logical block device that needs special handling before it can be used, you need *somewhere* to put those utilities that the kernel can find them. The fact that you can also use an initramfs for all of these other pre-init steps is just added benefit. --Mike
