[GTALUG] Boot setup issues

o1bigtenor o1bigtenor at gmail.com
Sat Sep 15 07:21:51 EDT 2018


On Fri, Sep 14, 2018 at 11:10 PM, D. Hugh Redelmeier via talk
<talk at gtalug.org> wrote:
> 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.

On my first iteration on linux I do remember lilo, vaguely (grin it is
a while ago!).
>
> - 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.

Thank you very much - - - - had not ever seen an explanation of the whats and
whyfors on this. Kn ow for next time! (Installing that is)
>
> | /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.

I've never used LVM so that might be useful but I've been able to figure things
out so they've worked fairly well so I will look into LVM but I'm not
sure I will
be using it.
>
> /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.

One of my linux mentors, who calls himself a linux dinosaur (started on
a System V on a pc) even advocates for a separate partition for /var/log
to forestall any software issues choking off disk usage.
>
> 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.

I was remembering it being called just EFI on the debian partitioning
setup pages in the install but wasn't sure of its name. Likely another of
those places where we are, as in English, divided by a common language.

>
> (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.)

As I have my main systems with more than 2 TB of hdds bios is no longer
an option.

I find when installing a new system that things go easier when I use my
CDResuceDisc and its copy of gparted to set up the partitions the way I
want and then mounting the install disc to effect the installation.

Thank you for the ideas and tips!! One of my frustrations with linux has
been that it can be very difficult to find clear understandable information
on many parts of the system. Much of the documentation seems to be
written for someone who is well versed in things and is looking for a clue
or a reminder on 'how things work'.
Your note is how I wish man pages were written. If only there were examples
of the command usage, happens rarely but is starting to happen, with what
to do when there are errors or problems would be wonderful but the assumption
always seems to be that the user just knows. My question is 'how does one
learn?' - - - even the Socratic method, which can be quite challenging for a
student works from what the student 'knows' to educating them in what they
'don't' know. I think that these lacunae in documentation are because its far
more fun to build things than it is to describe the hows and the whys and the
whatfors. So your explanations offered are very welcome!!!

Regards

Dee


More information about the talk mailing list