[GTALUG] Boot setup issues

D. Hugh Redelmeier hugh at mimosa.com
Sat Sep 15 00:10:07 EDT 2018


TL;DR: lots of history, some explanation of why things are done certain 
ways.

| From: o1bigtenor via talk <talk at gtalug.org>

| OK - - - good to know. For many years it was
| /boot,

Covered well by Lennart.

This first came up for me with UNIX System V release 2 on a PC.  The
boot loader only understood a a special simple file system (BFS).
This file system was pretty useless for real work so only a minimal
set of stuff was held there.  I *think* it was mounted as /boot.  It
was a lot like the kernel + initrd.

There's an interesting bootstrap problem that it addresses: how simple
can you make the bootloader and still make it do what you need.

LILO was an elegantly simple solution but it pinched:

- It used BIOS for disk I/O.  Eventually BIOSes could not address the
  whole of a disk and this bizarre limitation bled into the
  bootloader.

- The bootloader did not understand any filesystems so a tool was needed 
  to put absolute disk addresses into the bootloader whenever a kernel or 
  initrd was moved, added, or deleted.  Forget to do this and your system 
  became unbootable.

- Secure Boot?  I don't see how that could fit into the LILO
  framework.

- UEFI?  I think that a new bootloader, as simple as LILO, but a lot
  better, could be written using the API provided by UEFI.

GRUB is quite complex.  Among other things, it needs to understand any
filesystem from which it can boot.  For another, it needs its own disk
device drivers so that it can get around the BIOS limitations
outlined above.

I have a little PC that has a too-small "disk" (eMMC) to hold Windows
and Linux.  I wanted to use an SD card to hold Linux.  The UEFI
firmware doesn't have a driver for the SD card.  So the machine cannot
boot from the SD card.  If GRUB had such a driver, then I could put
/boot on the SD card, but it doesn't.  Still, it would be quite
reasonable for it to have such a driver.

| / (or /root),

Those are quite different.

/	is the root filesystem

/root	is the home directory for user "root".
	It is conveniently on / so the root user can be logged in
	without /home being mounted.

| /usr, /var, /tmp,
| swap, /usr/local and /home. I've had enough issues because / was too small,
| ditto for /usr.

If you use LVM (I don't) you get a level of indirection that lets you
increase partition sizes pretty freely.  So you don't have to get
allocations right at the beginning.

/tmp is quite reasonably on a separate special-purpose filesystem.  On
Fedora 28, the default is to use the filesystem type "tempfs".

In the days of LILO, /boot needed to be addressable by LILO so it was
constrained.  That was one reason to put /boot in a separate
filesystem.

Once upon a time, / was all you needed for single user mode.  You kept
everything else in things like /var and /usr so that there was a great
chance that a broken system could still be booted in single user mode.
/ was almost, but not quite, read-only.  Long gone.

Sometimes fleets of boxes shared, say, /usr, through NFS.  This meant
some kinds of system administration were easier and disk resources
were less wasteful yet each machine was faster than a diskless
workstation.

Now /, /var, /usr/var, /local, /usr/local, /bin, /opt, might as well
be on one filesystem.

I keep /home separate so that my user data is mostly in its own
filesystem.  Then replacing the OS is almost simple.  Too bad the
dotfiles need to adjust for different OSes.

| So on a new system I can drop /boot and only add /efi or ????

/boot/efi, not /efi.  Of course that isn't the name of the filesystem
it is the mount point.

(Some people insist on using BIOS, not UEFI.  In that case, you probably 
want a separate /boot and no /boot/efi.  I think UEFI is a better choice.)


More information about the talk mailing list