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 <zlinux...@wowway.com> : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/927172691.1040071270406940997.javamail.r...@md01.wow.synacor.com
