[conspire] Soundconfig:

[Rick Moen]

Just a couple of afterthoughts (corrections and comments):

> Once again, here's my laptop's lilo.conf file:
> 
>   lba32
>   boot=/dev/hda
>   root=/dev/hda3
>   install=menu
>   map=/boot/map
>   delay=20
>   vga=normal
>   default=linux
> 
>   image=/boot/vmlinuz
>           label=linux
>           initrd=/boot/initrd.img-2.4.18-686
>           read-only
> 
>   image=/boot/vmlinuz.old
>           label=linuxold
>           read-only

The attentive reader will have noticed that I screwed up, big time:
Although the "label=linux" has the necessary initrd reference, the
"label=linuxold" one, my _safety fallback_ stanza, lacks it.

This is an artifact of my having thrown out my old 2.2 kernel only a few
days ago, and having done a half-assed job of cleaning up.  That stanza 
worked beautifully with the 2.2 kernel, which did _not_ depend on an
initial RAMdisk.  I left that stanza alone while checking the 2.4
kernel, to ensure that the latter booted correctly and supported all
hardware.  Then, I blew away the 2.2 kernel, repointed the "vmlinuz.old"
symlink to the 2.4 kernel image, re-ran "/sbin/lilo -v" to make sure
there were no errors, and quit.

In fact, the above lilo.conf file would eventually have bit me in the
ass, if I'd not noticed my error in time:  If I'd tried a new kernel
using the "label=linux" stanza and it turned out not to work, I would
have found out that my "safety fallback" was not safe, and failed to
fall back.  (Fortunately, it's not difficult to recover with a
maintenance floppy or LNX-BBC disk or such, even if you screw up lilo.)

I really should have made sure that _both_ stanzas actually booted,
before quitting my reconfiguration of lilo.
(I've fixed it, for now, by moving the "initrd" line into the globals
section above the boot stanzas, where it will apply to both stanzas.
And then, of course, I re-ran /sbin/lilo.)


The attentive reader who also read my earlier post from the other day
will have noticed that I pulled a fast one in the above /etc/lilo.conf 
contents:  The version above says "default=linux", while the one I
posted yesterday said "default=Linux".  Note the difference in
capitalisation.

lilo.conf's "default" line specifies which stanza to use as the default
boot.  You can have "default=foo", where foo is one of the "label="
items.  If there is no "default=" line, then the first stanza will be
the default.

Debian's default lilo.conf gets initially constructed with _one_ stanza, 
whose label is "Linux" (capital-L "Linux").  Rather absurdly since
there's only one stanza, they also put "default=Linux" in there.  I
decided that it's rather silly to have to use a shift key to type in a
label name at LILO boot prompts, so I changed the stanza's label to
"linux" (lowercase-L linux).  However, I forgot to update the
"default=Linux" line.  Fortunately, /sbin/lilo seems to ignore such
a line if it doesn't match any of the included stanzas' labels.

I suddenly noticed the error this morning, while answering Bill's
post, and fixed it on the fly.  I'm mentioning it now in case anyone was
confused by the earlier lilo.conf post, or by the silent fix since then.

> Now, you can fool around with lilo.conf to your heart's content, knowing
> that you can always restore the original contents, if need be.
> 
> The iron rule of lilo is:  _Always_ verify that /sbin/lilo runs without
> error, before rebooting or shutting down.

I do _not_ mean by the above that you must do so before _any_ shutdown
or reboot -- just that you should do that if you've made any changes to
lilo.conf or the files it points to.

The whole purpose of /sbin/lilo is to look up the _physical_ disk
locations (cylinders, heads, sectors per track) of all the objects
mentioned in lilo.conf, and write bootable information to a special
hard disk location read during the boot process, such that the needed 
kernel image, map, initial RAMdisk, and so on can be found from their 
_physical_ locations alone, by a kernel that doesn't yet know how to 
read filesystems or read directory trees.  The booting kernel thereby
gains access to sets of drivers that furnish those missing abilities, 
allowing it to then mount the root filesystem, start the init process,
and so on.

If you move any of the objects that must be found at boot time, then the
physical-location information previously written to the special
boot-time hard disk location by /sbin/lilo will be obsolete and in need
of updating.  Thus the need to re-run /sbin/lilo.  Ditto if you make
revisions/additions to the lilo.conf file:  Those simply won't be
implemented until you re-run /sbin/lilo.


I hope the above makes matters a little clearer.

-- 
Cheers,             The shortest distance between two puns is a straightline.
Rick Moen
rick at linuxmafia.com