Answering this a bit late as Comcast redirected my email to their circular file for 2 days (though they deny changing it, it was done too precisely to have been random) and had not been changed almost 2 years...Grrr... Carlos E. R. wrote:
Yes, lilo is easier to understand and control, I agree. Some people here use it. But it has a severe disadvantage: that after a kernel update or some changes, if you forget to run "lilo", the system will be unbootable. With grub you never face this particular problem, grub has code to actually read the filesystem and find things.
---- Which caused alot of people grief when the grub routines for xfs got out of sync with the code in the kernel. Suddenly xfs was no longer "ok" for a boot disk. Those that had one could find not only a non-bootable system, but that grub had corrupted data because it's file-system routines weren't the ones in the kernel. lilo uses the kernel I/O routines to support the lowest common denominator. I don't ever play around in grub. When I make a new kernel, if it doesn't work, I book from the previous. No editing in a special limited console prompt. I find typing in a restricted environment frustrating. If I make a mistake, reboot using the previous kernel. Also, some said you have to "rerun lilo after running make kernel and make modules and make install. Um... I combine the install steps into 1 script so I never have to run lilo -- it's always run when I install the modules for the current kernel. lilo has fewer moving parts to break. Given that xfs still isn't recommended for a boot disk *because* of the damage grub did 6-8 years ago, you'd think people would learn that editing w/o an OS is an inexact science. I don't know if ELILO or UFI boots will prove as solid as lilo has been for the bios, but it is telling which boot loader is the default provided by the kernel devs...
Lilo worked by hardcoding in the boot code the exact location of all the sectors that had to be loaded into memory in order to boot the system. Lilo boot code could not read files by name or path on its own: instead the "lilo" command, when run from inside the operating system, wrote the actual addresses of the sectors it needed to read.
Thus a simple change, like copying a needed file again, would make lilo fail to boot.
--- Which is exactly what happened with grub and xfs... grub tried to copy files but did it on a live file system and not through the OS-file routines. Junk got written to disk and grub couldn't boot. It took almost a year before grub was updated enough to work with xfs and other journaled file systems. Vs. -- recording block ID's still worked as that's how the BIOS has booted for 30+ years... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org