> From: c...@chrekh.se [mailto:c...@chrekh.se] > > Neil Bothwick <n...@digimed.co.uk> writes: > > > On Tue, 27 Mar 2012 14:26:46 +0000, Alan Mackenzie wrote: > > > >> > 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? > > > > No, because an initramfs only needs enough to mount / and /usr, then > > everything else comes from the usual source. If you're not using and > > fancy block devices, the initramfs only needs busybox and an init script. > > Even adding LVM, RAID and encryption only requires three more binaries > > - and those are all disposed of once switch_root is run and the tmpfs > > released. > > The question remains. If it's possible to do that from an initramfs, then > shouldn't it be possible to put the same tools and binarias on /, and mount > /usr early? >
Yes , of course it's /possible/, it's just not /practical/. Changing the contents of your initramfs is a decision you, as an admin, make that affects your system(s). Changing the installed location of, say, udevd and bluetoothd and whatever other tools need to get pulled out of /usr is a decision that affects everyone who is using those packages. Changing the order of init scripts is an even bigger mess, but mostly because of the software requirements to make it function. Most Linux users, by a vast but very silent majority, are plenty happy to put / and /usr on one partition, wipe their hands on their pants, and move on with life. Thus, the people developing and packaging those required boot packages can leave them right where they are, and everything works. Some Linux users have reasons (largely legitimate ones) why this is not a valid option. Those users have three choices * Move the required packages away from their default installation locations on their machines, as you're suggestion, and fix the order of your boot scripts to mount /usr earlier than anything that needs it. * Install (or develop) alternative versions of the tools that do not have the same boot-time requirements, thus allowing you to ignore the whole mess. This is what Walt and his mdev team are making happen. * Use an initramfs to do whatever specific thing your machine(s) need to do to make the rest of the software work out-of-the-box. So, it's not a matter of one choice working and one not. It's a matter of one choice being much lower maintenance for the people donating their time to produce the software in the first place. If someone (maybe you) were to figure out the actual steps needed to mount /usr early in the boot, without and initramfs, without swapping out udev for busybox or whatever, I'm sure a lot of people would be interested in seeing how that's done. There's a possibility that it turns out to be way easier than anyone thought, and that supporting a split /usr becomes "no big deal". In practice, I'm going to guess that it turns out to be a way bigger maintenance nightmare (and probably more fragile) than: root # emerge dracut root # dracut -H And probably won't be something that the developers or package maintainers are going to commit to supporting. --Mike
