On Mon, Nov 24, 2008 at 05:53:15PM -0500, David A. Bandel wrote: > Let's make this REAL simple. > > You have an OS. You need to boot it. You set up the bootloader in THAT > OS, NOT IN A VACUUM. You don't set up a bootloader on a multiboot > system in every OS, just one. > > Ok, so I have a system in front of me (this is not a make believe > system, but one I actually installed -- poor choice, but it was provided > by a client): > 2 IDE hard drives, 2 SATA drives, on IDE CDROM. I connected the two IDE > drives as masters on the two IDE channels, w/ the CDROM as slave on IDE0. > > Not relevant for GRUB, but make the SATA drives md0 and the IDEs md1. > > OK, which is hd0?
Whatever /boot/grub/device.map says it is. Or otherwise whatever drive 0x80 is from the BIOS point of view. hd1 is 0x81, etc. > Thank you LILO, boot=/dev/md0, root=/dev/md0, raid-extra-boot=mbr-only. > Will ensure the BIOS looks to the SATA for boot (usually a choice of > SATA or IDE boot in the BIOS). Certainly in the past that didn't always work. lilo would assume hda was 0x80 and if you had mixed ide and scsi you had to explitly teach lilo that 0x80 was in fact sda not hda on your system, or it wouldn't work. > Had I not RAIDed them, then boot=/dev/sda, root=/dev/sdaN (whatever). > > Which drive is hd0? There is no such thing. Fortunately with LILO, I > can use drive designations we can agree on. I have NO IDEA where GRUB > will write the MBR (and neither do you, like a broken clock that shows > the right time twice a day, you could be right sometimes, too). And it > may change if the BIOS is upgraded (AAAAAAGGGHHH). > > This is insane, but a reason for not using GRUB, not for excluding LILO > from the exam. And in some cases your drive names change between boots depending on driver load order, how does lilo deal with that? > The issue remains, as long as LILO exists in any distro, as important as > booting is, it needs to be included. If you upgrade any of the 50+ > servers I've installed in the past 2-3 years and forget to run lilo, > have a good time if you don't know how to spell LILO. Perhaps you can > eventually get in and install GRUB. And the first time I run lilo, > you're back to wondering why the new kernel you just installed won't > boot again. Of course since the majority of people never use lilo and have no need for it, how is knowledge of it at all useful for an administrator? > If LPIC removes LILO it won't be taught. If a new generation of admins > is not taught about LILO, the LPIC exam and LPIC cert becomes, to me, > irrelevant. I wouldn't teach people about lilo personally. I think it is an awful bootloader with an awful design (which happens to deal better with a few odd cases, but of well). Nothing that big should be written in assembly. > Well if I can't I've done the impossible (OK, it was OpenBSD I dual > booted, but it was *BSD). The beauty of LILO is, it will boot > _anything_ that runs on x86 (for other architectures we have milo, silo, > etc.). GRUB is limited in that it has to understand the underlying > filesystem. LILO doesn't care about the underlying filesystem, it > points to a place on the disk. Fundamentally different. No fundamental > difference in DNS servers if you expect clients to be able to get an > answer from the server (that's what the RFCs are all about). lilo chainloads. So does grub. Grub happens to natively support BSD and such, rather than having to chainload the other boot loader to do the job. > Lilo is restrictive? I would have said the opposite, but that because > so many newbies can't remember to run lilo, they changed to GRUB > _despite_ its countless limitations. lilo doesn't let you boot anything you didn't tell it about previously. That is quite the limitation (although one common to many boot loaders). lilo's block map loading design happens to also make it deal better with weird filesystems or raid layouts than grub, so I guess there is one benefit to not being flexible. > Not sure where the logic is here -- I'm still missing it. > > I have fought against including software in the exam. This is one I > will continue to fight FOR (probably the only one). For any other > service I can choose to use something else. Well I don't really care if lilo is covered. I don't think it really has any purpose anymore, although there are those few weird setups where it helps. I prefer to avoid making those weird setups in the first place. > No, it won't. It will boot the old kernel _only_ if the admin knows > about LILO (and hits a key to stop the default boot which is usually to > the new kernel). And if he knows nothing about LILO (not on the exam, > then not taught), he'll be a signicant amount of downtime rescuing > something that doesn't need rescuing. Well any decent system already takes care of running lilo when a new kernel is installed, if lilo is what is in use on that system. Otherwise it takes care of updating the grub menu or whatever other bootloader you happen to have. > Wow. I didn't know LILO was extinct (are we living in the same > reality?). Not sure what that LILO upgrade was that just came out last > week. I'll be sure to pass on your comments to the developer, though. > I'm sure he'd like to know LILO is extinct. lilo is not extinct. Just obsolete. That doesn't mean it doesn't do what it always did, just that it is hardly doing what I expect from a boot loader these days. > And if that's true, then we need a new bootloader, cause if the answer > is GRUB ... it was the wrong question. Well some day we may have grub2, although I doubt you would like it either. -- Len Sorensen _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
