> From: che@... [mailto:che@...]
> Neil Bothwick <neil@...> 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
> > 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
> /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
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.