> From: Alan Mackenzie [mailto:a...@muc.de] > Sent: Tuesday, March 27, 2012 10:27 AM > > On Tue, Mar 27, 2012 at 10:02:02AM -0400, Mike Edenfield wrote: > > > From: Alan Mackenzie [mailto:a...@muc.de] > > > Sent: Tuesday, March 27, 2012 9:37 AM > > > > My question: what, technically, prevents me from copying the booting > > > software instead to /sbin and booting the system that way? > > > Nothing; in fact, this was the general solution to the problem of > > "something else in /usr/{sbin,bin,lib} is needed at boot" for a long > > time. More and more software was getting moved into /{s,}bin, and in > > particular into /lib, to make it available in the early boot stages. > > > There's nothing wrong with that, as long as you can ensure that any > > hard-coded paths to those binaries are updated properly. > > Surely this is the same, whether one copies the booting software to initramfs > or /sbin, isn't it?
No, because very little of my booting software is on my initramfs; it contains the kernel modules for my SATA drive and a script to mount /usr before launching /sbin/init. You *could* build an initramfs that included all of those other items, including udev and fsck tools if you wanted to, but you don't have to. (You might want to, for example, to have a more fully-features rescue shell, but I have a LiveCD for that.) The difference is what part of the booting process you need the software for. Without an initramfs, your boot loader loads your kernel, your kernel launches /sbin/init, and /sbin/init starts running your startup scripts. Everything that needs to happen must happen in those startup scripts. The problems occur when script #1 (say, start udev) sometimes needs script #2 (mount /usr) to have run, but script #2 sometimes needs script #1 to have run. You can solve this in a number of ways: * Fix script #1 to never need script #2 (move everything you need off /usr) * Fix script #2 to never need script #1 (put /usr on the same partition as /sbin/init) * Adjust the order of the scripts on a case-by-case bases (move script #2 to an initrd when needed) Option one has traditionally been the way to solve these kinds of problems, but with dynamic linking and external hooks the reach of the boot-time software is getting overly broad. Option #2 is the simplest and lowest-risk option, but not everyone has a hardware configuration that makes that a viable choice. So option #3 is basically "you do whatever you have to do to get a /usr before /sbin/init runs." > > As you move more and more software off of /usr into / you start to > > realize that the idea of "tiny partition that contains just what I > > need to boot and mount /usr" is becoming "not so tiny" anymore. The > > distinction between what is "boot" software versus "user" software gets > less clear. > > Again, isn't this the same for an initramfs? This part is, true, but the point of an initramfs is that, once you switch over to init, the initramfs is out of the picture. With a traditional boot, the stuff you move into your rootfs to make booting work is there forever. With an initramfs, you don't need (for example) all of the udev rules and libraries and such; you just need enough statically linked binaries to mount /usr; when the init switch happens, your real, production binaries show up and the trimmed-down copies from your initramfs go away. > > Then it's just question of how far you take this process before you > > reach your personal threshold of questioning why you have two > > partitions at all. Whether you reach that point or not depends on how > > complex your boot process is, what you actually need running to boot, > > and how personally invested in a split /usr you happen to be :) > > I've decided that, if push comes to shove, I'm going to go for /usr on / rather > than a fragile initramfs system. I've got everything bar / on RAID 1/LVM at > the moment, but I don't really use LVM, so I could dismantle that too, losing > all the baggage that brings with it. I'm using both on most of my systems now, though admittedly on my laptop it's just to get the boot animation from plymouth :) > Having said that, my system (including Gnome) is working perfectly well with > mdev, and see no reason why that shouldn't continue. And that's a perfectly legitimate option; you're continuing to use a process that has worked for decades. The problem with that option is not that it doesn't work for plenty of people, it's that it doesn't *scale* very well. If you're writing the software that needs to work out-of-the-box for every Fedora/Debian/Gentoo/etc system installed from this point forward, you need to worry about scale. If you're setting up a few hundred nearly identical servers with much more limited hardware that is under your direct control, you can focus your solution to a much narrow scope.
