[conspire] Church of Get It Done Now ... linuxmafia.com --> virtual? :-)

[Rick Moen]

Inevitably because of rushing, and of lingering jetlag.  There were
composition errors in that.  Addressing the worst I see quickly:

> Kernel will start with a tactically selected Debian source _package_.
> No, I'm not mad enough to go totally upstream vanilla kernel.org git
> checkout without necessity, thanks for asking.  Some time is worth
> spending checking Debianised patchsets for security tightening, whatever
> is most satisfactory now that Grsecurity/PaX went off in a snit.  Then,
> the real work of making a truly suitable .config, exactly appropriate to
> the software,
      ^^^^^^^^  'hardware'.


Once upon a time, e.g., around 1993 when I was running Slackware, 
you started with your choice of several alternate installion floppy
images that had initial kernels containing enough of the hardware
drivers essential for _your_ hardware to get your system minimally
functional.  E.g., there was a 'scsi' flavour floppy ISO, without which
Slackware wouldn't know what to make of my Adaptec SCSI HBA.

But it was understood that one of your first administrative tasks would
be to get a kernel source tree, and then spend a few hours in 'make
menuconfig' to craft a .config file specifying the full set of drivers
you need.  You then do make clean; make oldconfig, make zimage' or some
routine like that (but not exactly, so please don't trot out
corrections) , and watch gcc grind for twenty minutes building your
shiny new kernel and System.map.  (We didn't have initrd then, and I
intend to happily do without it on the host OS at least.)  Tweak
lilo.conf and make double-damned-sure you retain a stanza pointing to
the old, known-usable kernel as a fallback, then 'lilo -v' to re-run the
map installer and rewrite your MBR data, then 'sync; sync; sync;
shutdown -r now' and smoke-test it.

I'm basically going back to that.  Whoo-hoo!  1993 is back, baby!



I mentioned that I'm _so_ done with GRUB.    It's the very model of
what's wrong with distro package selection.  Every goddamned distro ends
up defaulting to either GRUB Legacy (0.9x, isn't it?) or GRUB2, and, if
you question that, a distro bureaucrat points out some bizarre edgecase
that any alterative you propose cannot handle.  Because it is
unthinkable that even a single whack-assed usecase isn't automagically
handled out of the box, everyone gets GRUB, the world's most
overfeatured bootloader.

And, as mentioned, the one place I am going to not permit an
overfeatured _anything_ is in the host OS.

I'm actually conflicted about what to use if not GRUB.  I'm almost
ornery enough to use LILO again, even though its abaility to handle
/boot on md-drifver RAID1 is a little tricky, and it's a cinch that
nobody's maintained the code in at least two decades.  Which is not
necessarily a problem.  Sometimes 'unmaintained' is just a wrongheaded
word for 'finished'.  Example:  procmail.  Does it actually matter that
there hasn't been an upstream for procmail in ages?  No, because it
doesn't need one.  It's exactly what it needs to be.  (Two CVEs cited
are not credible threats and aren't actually bugs in procmail.)

Anyway, bootloader choice.  I'm also tempted, for the lulz, to go with
the Linux kernel's ability to be booted directly from UEFI without any
bootloader at all.  Isn't that a kick?   I'd have to ponder the
ramifications.

I should stress that the CompuLab _doesn't_ mandate UEFI.  My use-case
and size of storage doesn't make GPT necessary and useful either.  So, 
the natural choice would be old-school BIOS booting with good ol' interrupt 
13h, and a Neanderthal-like MS/IBM "master boot record' and primitive
partition table.  There's no advantage to _not_ going old-style, since I
can do so and am not deploying multi-terabyte anything.  So, why not?  
I can manage MBR/BIOS systems in my sleep, and, sure it was always a
rickety design, but UEFI and GPT are a Second System Effect horror that
I'd rather avoid.

So, that brings me back to:  Need a bootloader.  Could be LILO.  Could
be syslinux/extlinux.  Rod Smith of Rod's Books is IMO an excellent
source of information on these matters (although his wise writings are
mostly about UEFI & GPT):

https://www.rodsbooks.com/efi-bootloaders/syslinux.html
https://www.rodsbooks.com/
(etc.)

On reflection, I'm not certain offhand that Rod's site has even a single
word about pre-UEFI booting.  Which, OTOH, is because MBR/BIOS systems 
are a walk in the park.  So, there's that.

If I _do_ eschew UEFI and GPT (and therefore don't need Rod's good
advice), I should probably spare a few minutes to find something less
extremely ancient than LILO that can boot simply and reliably from md
RAID1.  Might be syslinux/extlinux.  Could be something else.