[svlug] Boot systems: was Can't get LFS systemd system to boot

Rick Moen rick at linuxmafia.com
Fri Jan 30 22:05:55 PST 2015


Quoting Steve Litt (slitt at troubleshooters.com):

> Do you use LILO today? 

Next system build I intend to do so (again), after many years of
following the path of least resistance with distro upgrades making the
decision to change bootloader on me along with other changes
(dependencies, etc.) that I've recently become a great deal more wary
about.  

And yes, I think elilo is what I would use if I were to operate an
EFI/GPT-based system -- neither of which I have so far needed to do much
with.

> Do you use ELILO for stuff that must boot from GPTs? 

No experience -- but this page by the illustrious Rod Smith looks
useful:  http://www.rodsbooks.com/gdisk/booting.html

> Can you give me some pointers to the mindset necessary to use LILO
> successfully, and to the *useful* LILO documentation?

'Zen of LILO' on http://linuxmafia.com/kb/Kernel makes no effort to be
anything like primary documentation, but expresses the three things that
IMO people ought to know -- lack of which awareness used to feed the
perception that lilo was 'too difficult' or 'fragile'.  (Hilariously, I 
also used to hear 'too complex', which is a howler in comparison to GRUB
1.9x and GRUB2.)

> I'm particularly interested in how to make your lilo.conf while
> booted some other way, to "think backwards" to envision the system as it
> will boot. 

To be clear:  I haven't used lilo in some years, through inertia.  I
failed to say 'no you don't' at one point during a distro upgrade, and
ended up on GRUB 1.9x, which continues to underwhelm me.  I feel
sheepish about that having happened, but will belatedly correct course.

I relied on a dead-simple lilo.conf with two stanzas, the known-good
stanza that I made a point of leaving alone, and the currently-used one.

In all likelihood, it won't be the least bit difficult to reassemble
when the time comes.  Meanwhile, this is an obvious candidate for you to
experiment with (if you wish) on a VM or spare machine.

> Do you use chroot? Something else?

Nope and nope.  Just caveman-simple lilo configuration.  No dual-boot,
just a pair of maximally simple stanzas for Linux boot.  I tended to
have the production lilo.conf be a variant with zero comment lines.
Distros tend to festoon so many comment likes in bootloader conffiles
that they're very difficult to read -- and I put a premium on being able
to quickly read and understand such files.

 I was never good at the
> "thinking ahead" part of LILO. 

> Does LILO do anything out of the
> ordinary with initramfs, or can you use the same initramfs, with
> different lilo.conf syntax, that Grub2 used?

You specify an initramfs file, a kernel file, (optionally) a System.map
file (IIRC), and a root filesystem device.  All of these things are
specified in native Linux location semantics, e.g., you don't need to
learn a bootloader-specific system for device naming the way you do with
GRUB1.x/GRUB2.

A vital difference:  As mentioned in the Zen of Lilo piece cited above, 
you implement your chosen bootloader configuration by running /sbin/lilo 
(the lilo 'compiler'), which takes /boot/lilo.conf as input
configuration data.  /sbin/lilo determines the disk locations of the
referenced objects (cylinders, head, sectors/track = CHS) and _writes
out_ its bootloader program to the specified location pre-provisioned
with the physical disk locations of the various referenced objects.
E.g., if your lilo.conf says that bootloader information should be
written to /dev/sda, then lilo's first-stage bootloader gets written at
(every) time you run /sbin/lilo to the MBR on /dev/sda.  If your
lilo.conf says that bootloader information should be written to
/dev/sda1, then lilo's first-stage bootloader gets written at (every)
time you run /sbin/lilo to the initial sectors of filesystem /dev/sda1.

I call this 'a vital difference' because, in consequence, the runtime
boatloader program doesn't need to be able to parse filesystems.  It had
the CHS numbers of objects needed at boot time, so it doesn't need to
know anything about filesystem semantics.

In consequence, once you understand this, you also realise that if you
move, say, a kernel binary image to a new physical (CHS) location on the
disk, if only by mv'ing the file somewhere and then mv'ing it back, you
need to re-run /sbin/lilo before next reboot, because the jotted-down
CHS values for that object are out of date.


> Also, anyone here booting their hard disks from SYSLINUX? 

No, but I really ought to try that one again.  I respected it a lot,
when last I used it.

> Am I correct that SYSLINUX can't boot a UEFI/GPT disk? 

Appears to be covered here:
http://www.syslinux.org/wiki/index.php/Doc/gpt




More information about the svlug mailing list