[TUHS] /usr separation

Theodore Ts'o tytso at mit.edu
Thu Feb 25 00:14:11 AEST 2021


On Tue, Feb 23, 2021 at 01:29:11PM -0700, Grant Taylor via TUHS wrote:
> On 2/23/21 11:57 AM, Theodore Ts'o wrote:
> > There are two reasons why you might want to have an initramfs.
>
> Rather than getting into a tit for tat debate, I'll agree that we have both
> proposed reasons why you /might/ want to use an initramfs.  The operative
> words are "you" and "might".  Each person probably wants slightly different
> things.  It's far from one size fits all.

Sure, I was trying to enumerate the reasons why initramfs, for some
combinations of hardware / configurations, might be necessary.

> > /boot needs to exist due to limitations to the firmware and/or boot
> > loader being used.
> 
> Not necessarily.  E.g. one single partition containing /boot and / (root).

Sorry, I should have written, "/boot MAY need to exist".

> > Other than that, there is no reason why /boot needs to be its own file
> > system, except that most installers will create one just because it's
> > simpler to use the same approach for all cases, even if it's not needed
> > for a particular use case.
> 
> As Steve Gibson is famous for saying; The tyranny of the default.

I wouldn't say that; I'd rather say that if you have a huge
combination of configurations that you have to test, those
configurations which aren't regularly tested will tend to bitrot, or
have odd failures in various error cases.  The more corners that you
have, the more corner cases.

And this is where it's all about *who* gets to pay, either via money,
or via their labor, to support these various cases.  Weren't people
just complaining, in other TUHS threads, of "bloat" in Linux?

Well, this is how you get bloat.  It's just that if it's a feature
*you* want, then it's not bloat, but an essential feature, and if it's
not provided, you whine mightily.  And when you have a large number of
enterprise customers paying $$$ to enterprise distribution vendors,
each with their own set of essential features, and where *binary*
backwards compatibility is considered an essential feature, then
that's how you get what others will called "bloat".  I would call this
the "Tyrany of Gold", as in the reformulated Golden Rule, "The ones
with the Gold, makes the Rules".

> > P.S.  Oh, and if you are using UEFI, you might need to have yet another
> > file system which is a Microsoft FAT file system, typically mounted as
> > /boot/efi, to keep the UEFI firmware happy....
> 
> Yes, the file system needs to exist.  But that's part of the firmware, not
> the operating system.  I also question if that FAT file system needs to be
> mounted or not.  --  I don't know how GRUB et al. deal with a non-mounted
> UEFI file system.

GRUB doesn't care.  But various system administration utilities that
want to manage to UEFI boot menu (as distinct from the GRUB boot
menu), they need to modify the files that are read by the UEFI
firmware.  So it's convenient if it's mounted *somewhere*.  Also, even
if it's not mounted, it's still a partition that has to be around, and
one reason to keep it mounted is to avoid a system administrator from
saying, "hmmm, what's this unused /dev/sda1 partition?  I guess I can
use it as an extra swap partition!"  And then the system won't boot,
and then they call the enterprise distro's help desk, and unnecessary
calls into the help desk costs $$$, and distro's tend to optimize for
unnecessary cost.  (Plus lots of unhappy customers who are down, even
if it is there own d*mned fault, is not good for business.)

> But even if it does need to be mounted, you can still get away with two
> partitions; / (root) and /boot/efi.  I suspect UEFI does away with the LBA
> issue you mentioned.

Yes, in another 5 or 10 years, we can probably completely deprecate
the MBR-based boot sequence.  At which point there will be another
series of whiners on TUHS ala the complaint that distributions are
dropping support for i386....

But since most TUHS posters aren't paying $$$ to enterprise
distributions, most enterpise distro engineers are going to give
precisely zero f*cks.  But hey, if you want to volunteer to provide
the hard work for supporting these configurations to the community
distribution, like Debian, those distros will be happy to accept the
volunteer help.  :-)

						- Ted


More information about the TUHS mailing list