Re: Customizing the kernel installation process
On Sat, 3 Apr 2010 20:34:13 -0400 (EDT), Paul E Condon wrote:
> One of the reasons for boot
> problems in general is the lack of stablity in the names assigned
> by the kernel to SCSI devices. Lilo seems to require that you know
> at lilo-update time what the kernel will think the name of a
> device will be at boot time. Grub was supposed to offer a solution.
>
> Or am I just totally misunderstanding ... ?
Lilo has two distict phases: (1) The process of writing out a new
boot block, which occurs as the result of issuing the "lilo" command
at a shell prompt, and (2) The process of booting the kernel, which
is done by the code written to the boot block during phase 1.
The examination of /etc/lilo.conf and the interpretation of Linux
device names specified in /etc/lilo.conf, such as /dev/hda1,
occur only during phase 1, the process of writing out a new boot block.
During phase 1, the Linux device names are converted into the equivalent
parameters needed to do I/O to the device via the BIOS. For example,
/dev/hda1 would be converted into something like "primary IDE controller,
master device, partition number 1". The files themselves (the kernel
image file and the initial RAM disk image file) are converted into
a sequential list of LBA addresses to read. Thus, during phase 2,
lilo doesn't need to know anything about the file system (except for
file system control structures which may exist inside the data blocks
themselves) in order to read the file.
If something causes the device names to change, such as a change to
udev, that will not cause a boot failure, since the phase 2 boot
code doesn't use the device names at all. It does all its I/O via
the BIOS and uses parameters that the BIOS understands. However,
/etc/lilo.conf will need to be edited to specify the new device names
before the lilo command is issued again to write out a new boot block.
The method used by grub does bypass the Linux device name issue.
However, grub version 1 and grub version 2 use incompatible methods
for specifying the partition numbers. Grub version 1 numbers partitions
starting with 0: grub version 2 numbers partitions starting with 1.
Furthermore, the boot loader configuration files are not the only
things that may need to be changed if Linux device names change.
In particular /etc/fstab comes to mind, not to mention various
home-grown scripts that administrators may have created.
I hope that answers your question.
>From my perspective, the primary advantage of grub over lilo is that
grub does not read the kernel image file and the intial RAM disk
image file via a list of LBA addresses created during the writing
of the boot block: it understands the file system and can dynamically
determine at boot time which blocks it needs to read to load the
kernel and the initial RAM filesystem into memory. This means
that the boot block needs to be re-written less often. With lilo,
simply copying the kernel image file somewhere else, erasing the
original, then copying it back will require that the boot block
be re-written.
Why? Because even though the kernel image file exists
in the /boot directory, just like it did before, chances are that
it no longer occupies the exact same list of blocks in the exact same
order that it did before. Therefore, the lilo command must be re-run
to generate a fresh (and correct) list of LBA addresses to read in
order to read the kernel image. Similarly, anything that causes or
may cause the list of LBA addresses which comprise the initial RAM
filesytem file to change will also necessitate that lilo be re-run.
This includes, but is not limited to, regenerating the initial RAM
file system by running "update-initramfs -u". Since grub understands
the file sytem, it can determine which blocks need to be read
dynamically.
That, in my humble opionion, is the primary advantage of grub.
With grub version 1, running update-grub does not re-write the
boot block. It only regenerates /boot/grub/menu.lst based on
which kernels are installed. With grub version 2, this list is
effectively generated on the fly, and even this requirement is
eliminated.
These advantages come at a price, however. The extra code
needed to understand the many file systems makes grub bigger (and
more vulnerable to bugs). And that is the primary reason I use
lilo. lilo occupies only the master boot record (cylinder 0,
head 0, record 1). grub (both versions) occupies additional blocks
(record 2, record 3, etc.). These blocks are outside of a partition
and are not backed up by the backup software that we use. The backup
software knows to back up the master boot record, and it also backs up
all the partitions and their boot blocks, but the extra blocks
occupied by grub are not backed up. Thus, if we have a hard drive
failure, we replace the hard drive; we run a restore; and we're good
to go, as long as the machine runs lilo. But if the machine runs
grub, and we do a restore, we have an unbootable machine. There are
some ways around this with our backup software, but they are not
entirely satisfactory, for various reasons that I won't go into.
Besides, special backup requirements gives the enemies of Linux at
our shop an excuse to oppose further deployments of Linux, which is
something that I wish to avoid at all costs. The backup software
was purchased back when all our servers ran Windows. The backup
algorithm that it uses works just fine with Windows, and with Linux
too, as long as the boot loader only occupies the master boot record.
But grub violates this assumption and therefore causes problems.
As an additional bonus, lilo supports the vga option, something that
I use quite a lot, and grub version 2 (at the time at least) did not
really have anything equivalent to it.
Having made the decision to go with lilo rather than grub for what
I believe to be sound technical and business reasons, at least in
my environment, I must confess to having a sense of relief and gratitude
each time I see I post that says, in effect, "I updated grub and now
my system won't boot!" I think to myself, "Boy, I sure am glad that
I use lilo." On the other hand, having publicly recommended to others
who are having grub problems to switch to lilo, I also felt a sense
of responsibility to document, to the limited extent of my abilities,
the proper way to fully integrate lilo into the Debian environment,
so that they will experience a minimum of problems with it.
Most of the "old timers" already know; since they've used lilo in the
past. But many of the newer users have never used lilo before, and
it is primarily for their sakes that I revised my web page.
And I hope that explains why I choose to use lilo. But again, as I've
said before, "To each his own." If you're happy with grub, and it's
working well for you, and it meets your needs, I'm not advocating
that you switch to lilo.
--
.''`. Stephen Powell <zlinuxman@wowway.com>
: :' :
`. `'`
`-
Reply to: