Weekly Edition
Return to the Press pageRecent Features
| |||||||||||||
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet)
O'ReillyNet compares
LILO and GRUB. "LILO (Linux Loader) and GRUB (GRand Unified
Bootloader) are both configured as a primary boot loader (installed on the
MBR) or secondary boot loader (installed onto a bootable partition). Both
work with supporting operating systems such as Linux, FreeBSD, Net BSD, and
OpenBSD. They can work with unsupported operating system, such as Microsoft
Windows XP, in the configuration file. Both allow users—root
users—to boot into single-user-mode."
(Log in to post comments)
Embarrassing. Posted Jan 22, 2008 20:41 UTC (Tue) by flewellyn (subscriber, #5047) [Link] This article feels like something you'd read maybe ten years ago. GRUB is pretty much the standard on all new distributions, I believe, and I know that I've had to manually select LILO on every Linux install I've done in the past five years. Also, the article is poorly written and edited. There are a lot of grammatical errors, and it's badly organized. The real "meat" of the article, the actual comparison, is at the very end, and it doesn't really provide much of use there, either. The actual, technical advice is either cribbed from manual pages, incomplete, or flat-out wrong. I wouldn't advise a new user to start with LILO; I'd tell him or her to just use the distro's default, which is usually GRUB, and to use the GUI tools to configure booting other partitions if necessary. Seeing an article like this on O'ReillyNet in 2008 is just embarrassing.
Embarrassing. Posted Jan 22, 2008 22:37 UTC (Tue) by nstraz (guest, #1592) [Link] Yes, a better article would look at GRUB 2 and investigate why it hasn't made it into more distros.
Embarrassing. Posted Jan 22, 2008 22:59 UTC (Tue) by flewellyn (subscriber, #5047) [Link] A better article would also talk about what LILO's actual limitations are. This one, other than mentioning that you have to rerun /sbin/lilo every time you change the config, and the fact that passwords are stored plaintext, doesn't really get into it. I would at least have mentioned that LILO works by remembering which disk block contains the second-stage bootloader, and doesn't have a concept of how to read filesystems, whereas GRUB can read filesystems and thus doesn't have to be told that the config file has changed. Also, it doesn't mention that you have to rerun LILO's loader every time you change the kernel! That's a SERIOUS omission, one that could result in an unbootable system. This is information that any article on the two bootloaders should have. I also forgot to mention, this article is (yet again) depressingly x86 specific. It doesn't mention how you would boot Linux on other architectures, such as PPC, SPARC, or MIPS, and how booting on non-x86 archs dramatically changes the "which is better?" question: if I recall correct, LILO doesn't even work on non-x86, whereas GRUB does. Plus, I know that non-x86 archs have had their own bootloaders for Linux, and this article doesn't mention those.
Embarrassing. Posted Jan 22, 2008 23:53 UTC (Tue) by nix (subscriber, #2304) [Link] LILO does have one substantial ability which GRUB didn't have last time I looked (a couple of years ago): it could install itself on the MBRs of multiple disks at once, such that if you RAID-1ed your /boot partition, you could survive the failure of your boot disk by just swapping in another member of the RAID set. GRUB could do that in theory, but it required a horrific amount of deep magic, while for LILO it's just a matter of saying boot = /dev/md0 raid-extra-boot = mbr-only (or words to that effect) in lilo.conf.
Embarrassing. Posted Jan 22, 2008 23:55 UTC (Tue) by flewellyn (subscriber, #5047) [Link] Interesting. I wasn't aware of this capability. It sounds useful, though. I take it you're talking about software RAID mirroring, though? I would imagine a hardware RAID-1 would already mirror the boot sector anyway.
Embarrassing. Posted Jan 23, 2008 1:06 UTC (Wed) by nix (subscriber, #2304) [Link] Well, yeah: those of us with mis-sized disks, without infinite money, and with a desire to at some point add a few extra disks without replacing the lot tend to prefer md :) (also, md has the best support on Earth. I defy you to find a nicer or more responsive or capable maintainer for *anything* than Neil Brown.)
Software vs. Hardware RAID-1 Posted Feb 2, 2008 21:27 UTC (Sat) by anton (guest, #25547) [Link] Another reason to prefer software RAID-1 is that I don't need to keep a spare instance of the hardware RAID controller around to cater for the case where the controller dies. I can simply put the disks on any controller I happen to have around.Finally, from what I read, Linux software RAID-1 is just as fast as hardware RAID-1, so the only advantage of hardware RAID-1 seems to be that GRUB works better with it.
Software vs. Hardware RAID-1 Posted Feb 3, 2008 20:31 UTC (Sun) by nix (subscriber, #2304) [Link] Hardware RAID uses less bus bandwidth than software RAID does, of course, so if your bus is really busy you might need to go hardware RAID or accept a slowdown.
Embarrassing. Posted Jan 23, 2008 0:16 UTC (Wed) by jwb (guest, #15467) [Link] This is also an annoying flaw in LILO which can render your system unbootable. If you grab a spare disk out of a pile and slap it into a RAID for a rebuild, as I once did, you will find that your system can no longer be booted. Why? Because for some reason LILO will look at the MBRs on various disks and if it finds another one that also looks like another LILO boot sector, it will inspect it. If it differs from the primary MBR LILO will say "timestamp mismatch" and halt. The error message and mode of failure are not documented anywhere.
Embarrassing. Posted Jan 23, 2008 1:10 UTC (Wed) by nix (subscriber, #2304) [Link] That error happens if the map file in use wasn't created at the same time as the bootstrap loader, and seems to me to be an extremely good idea. From my reading of the code, you'll only get that error if you try to boot from a old spare disk in conjunction with a /boot containing a LILO map which is *not* on that disk, in which case, well, every disk with an MBR should have a /boot on it, and then that problem goes away. (Given that the alternative is a rather nasty crash without any sort of message, this might be a good idea: but perhaps booting should continue and this should be demoted to a warning?) (Also, I'd expect to recover by switching one of your other *currently in use* disks over to be the one the MBR is read from. That's the scenario a RAIDed boot block is meant to be useful for, not 'grab random disk off pile'.)
Embarrassing. Posted Jan 23, 2008 0:30 UTC (Wed) by cortana (subscriber, #24596) [Link] I wouldn't really call it a horrific amount of deep magic... something like this does the job: # grub grub> device (hd0) /dev/hdc grub> root (hd0,5) grub> setup (hd0) repeat for each disk that you want to make bootable.
Embarrassing. Posted Jan 23, 2008 1:11 UTC (Wed) by nix (subscriber, #2304) [Link] OK, that's much *much* less than what I read a couple of years back, but the need to repeat it for every disk is still worse than the documented-in-manpage two-liner for LILO.
RAID Posted Jan 24, 2008 6:54 UTC (Thu) by jimparis (subscriber, #38647) [Link] Here's one problem I've often run into with booting off RAID1: What actually happens when a disk fails? Let's say that I have two disks, HDA and HDB, /dev/hda and /dev/hdb in Linux, that map to BIOS disks 0x80 and 0x81. I set it up so that, at boot time, the MBR on HDA knows to load a stage2 or kernel off BIOS disk 0x80. Similarly, HDB knows to load its stage2 off BIOS disk 0x81. But what happens when HDA fails? Well, if it's still around, and just got a corrupted boot sector, then I might end up booting off HDB, and it might properly read itself when it goes looking for 0x81. But if HDA died completely, now HDB might appear as bios disk 0x80, and when it goes to load stage2 -- there's no 0x81 anymore. In short I've never found a way to reliably make sure that I can always boot regardless of how disks break/die/get shuffled around. So I just assume it will never work -- I burn myself a GRUB CD (or netboot it). After I set up a new system, I boot the GRUB CD and do: root (hd0,0) setup (hd0) And I know that the system will be boot off one of the disks, who knows which one. If I get a disk failure that causes me to physically take down the system and have to reboot, I'll pop the CD back in and run the same command to set up whichever disk now appears as the first BIOS disk. I actually do the "setup" on some more disks, in the hopes that maybe certain sorts of failure would still let it boot automatically. For example: root (hd0,0) setup (hd0) root (hd0,0) # if I expect hd0 to fail setup (hd1) # and for hd1 to take its place or root (hd0,0) setup (hd0) root (hd1,0) # if I expect to boot from hd1 setup (hd1) # even though hd0 is still present Which one I usually choose sometimes depends on how the BIOS behaves on that machine. Anyway, x86 booting in general is pretty crappy, and I definitely prefer GRUB because I can actually get in there and fix things at boot time if necessary.
RAID Posted Jan 24, 2008 10:59 UTC (Thu) by nix (subscriber, #2304) [Link] Yeah, that's interesting, isn't it. I think this is why LILO scans all disks that were in the RAID set at map build time (at least I think that's what it does, I may be misreading the code). So if you're booting off 0x80 and a disk fails and you swap another disk in as 0x80, it should still work. I think. (I've never had to use this in a failure case yet and I hope I don't for a good long while...)
RAID Posted Jan 25, 2008 0:25 UTC (Fri) by jengelh (subscriber, #33263) [Link] SPARC benefits in this case. Disk "0x81" is always "0x81" (though, more like /pci@6,4000/scsi@4/sd@0,0); and the MBR code does not even seem to need to deal with numbers at all, but use "current drive" opcodes. Anyway, an MBR written to disk will always read from the same disk. No ill effects if you swap disks or remove one (on x86 they'd "move up" and make the mess you describe).
RAID Posted Jan 25, 2008 0:57 UTC (Fri) by nix (subscriber, #2304) [Link] Oh yes. OpenPROM on PC-class hardware would be great. (Also, I'd like to win the lottery. --- it's traditional to ask for a pony at this point, but in any combat between me and a horse, the horse wins.)
RAID Posted Jan 27, 2008 9:00 UTC (Sun) by ranmachan (subscriber, #21283) [Link] Simple: All stage1 copies load stage2 of disk 0x80. If the broken disk is still seen by the BIOS and disk 0x80, you're screwed anyway, because it will _not_ fall back to booting disk 0x81. And if the disk disappears the next one becomes disk 0x80 and booting works. Over here, I have 'install-mbr'ed all RAID1 disks and made the 'boot' partition active on all 3 (The data partitions are RAID5, but boot is obviously RAID1). The boot RAID-partition begins on the same LBA on all 3 disks and contains the /boot filesystem and is also where grub is installed. Linux RAID is set up so that all 3 disks are active (not hot spare, because a hot spare would not be updated if you change files on /boot). This way, I can boot from any of the three disks.
RAID Posted Jan 27, 2008 15:59 UTC (Sun) by jimparis (subscriber, #38647) [Link] > Simple: All stage1 copies load stage2 of disk 0x80. > If the broken disk is still seen by the BIOS and disk 0x80, you're screwed > anyway, because it will _not_ fall back to booting disk 0x81. > And if the disk disappears the next one becomes disk 0x80 and booting works. In theory, sure. But in practice I've seen all sorts of strange behavior from BIOS (both the motherboard BIOS and whatever's provided by add-on cards, and the interactions between the two) in the case of failing/failed disks, and I've definitely had the case where I ended up booting off 0x81. So I do what you do, but I also have other plans for when that doesn't work.
Embarrassing. Posted Jan 23, 2008 8:03 UTC (Wed) by grmd (subscriber, #4391) [Link] Another ability that LILO used to have and Grub did not was the ability to specify the next image to boot.
Embarrassing. Posted Jan 27, 2008 8:51 UTC (Sun) by ranmachan (subscriber, #21283) [Link] I have to disagree. This is the exact setup I use with grub on my server and it was a simple matter of "grub-install /dev/md0" IIRC. Works like a charm. Well, you should make sure that the partitions that make up /dev/md0 all start on the same LBA, but I'd assume LILO would also require this.
Embarrassing. Posted Jan 27, 2008 13:53 UTC (Sun) by nix (subscriber, #2304) [Link] Ah! The ugly-complexity bug has been fixed completely then: my apologies for spreading rubbish based on years-outdated info. (I'm not sure if LILO requires all the partitions to start in the same place: I suspect so. I just happened to put them all first :) )
Embarrassing. Posted Jan 23, 2008 16:59 UTC (Wed) by proski (subscriber, #104) [Link] GRUB on PowerPC is not ready for prime time yet.
Embarrassing. Posted Jan 24, 2008 3:28 UTC (Thu) by flewellyn (subscriber, #5047) [Link] See, that's useful information that the article should have. I didn't know this.
Embarrassing. Posted Jan 24, 2008 16:51 UTC (Thu) by kenmoffat (subscriber, #4807) [Link] > if I recall correct, LILO doesn't even work on non-x86, whereas GRUB does. Actually, grub needs a 32-bit libc on x86, so it only compiles on 32-bit and multilib, whereas lilo does compile on 64-bit x86.
Limitations and advantages of LILO Posted Feb 2, 2008 21:17 UTC (Sat) by anton (guest, #25547) [Link] More things to add to the actual limitations of LILO (may be fixed in a newer version):
Limitations and advantages of LILO Posted Feb 16, 2008 17:24 UTC (Sat) by cortana (subscriber, #24596) [Link] With LILO I learn before rebooting if I have a typo in the config file. Just fix it in lilo.conf and rerun lilo. With GRUB I have to reboot, then fix it in the boot menu, then fix it in menu.lst, then boot again to check that the fix is correct. Running lilo is a feature of LILO, not a limitation.A nice new feature of grub 2 is the grub-emu command. Running it will let you see if your menu file is correct, among other things. Installing GRUB can be a nightmare. I had a situation when grub-install would accept neither Linux-style device names nor GRUB(Hurd?)-style device names. Ok, the recommended approach is to then boot GRUB from a floppy disk, and use it to manually install GRUB on the hard disk, but I then decided that installing LILO is so much easier.I think the recommended approach in this situation would be to file a bug and solve the problem. :)
Why hasn't Grub 2 made it into distributions? Posted Jan 23, 2008 12:42 UTC (Wed) by vonbrand (subscriber, #4458) [Link] Overengineering?
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 22, 2008 23:55 UTC (Tue) by drag (subscriber, #31333) [Link] Personally I like the syslinux family of boot images. They are uberfull and now I use them for when I need to do highly custom installs. (otherwise I take the default that the installer for a disto gives me) It's easy to use also. Easy to use in that it's simple and will work most situations were lilo or grub will fail. For example it's very good making bootloaders for booting from external drives. Grub or lilo can get confused based on whatever misinformation the BIOS may give them about drive numbering. If you want to have a bootable drive that you want to carry around with you and work on random machines then the combination of using syslinux and refering to drives by volume names or uuids in your /etc/fstab (instead of /dev/sda or whatnot, which can change) and bootloader config can make it happen. syslinux -- for booting from a fat partition. pxelinux -- for use with PXE network booting isolinux -- for use with booting from cdroms extlinux -- for booting from ext2/3 partitions memdisk -- for using pxe booting for legacy OSes or dealing with intensely crappy bioses and getting things like booting from cdroms to work.
GRUB's failed potential Posted Jan 23, 2008 2:49 UTC (Wed) by Junior_Samples (guest, #26737) [Link] Grub has the potential for being a very cool boot loader. However its true ability to boot different operating systems is largely unexploited. Unfortunately the way GRUB usually boots a "foreign" operating system is something of a cheat. What grub usually does is to chain to the "foreign" operating system's own boot loader--an expedient hack but hardly elegant or flexible. It's like using GRUB to start LILO--big whoop!I happen to have a modified version of GRUB which can boot Linux or a MirOS kernel directly. I mostly run Linux, but I can treat the MirOS kernel exactly like a Linux kernel by placing it in any convenient partition. I don't know if my version of GRUB is currently maintained. But using this version of GRUB has been a real eye-opener. I only hope that the GRUB developers will pick up the ball and run with it. I hope they start allowing GRUB to boot "foreign" kernels directly without the need to chain to a "foreign" boot loader.
GRUB's failed potential Posted Jan 23, 2008 3:22 UTC (Wed) by PO8 (guest, #41661) [Link] The reason it's called the "GRand Universal Bootloader" is that it follows the multiboot spec, which means that operating systems that honor that specification should be directly bootable without any GRUB magic. Arguably, if your operating system won't boot directly from GRUB, it's a defect in your OS (or an outright bug in GRUB's multiboot support, I suppose :-).
GRUB's failed potential Posted Jan 23, 2008 3:40 UTC (Wed) by Junior_Samples (guest, #26737) [Link] Thanks for the info. I suppose FreeBSD and NetBSD are defective since they can't be booted directly. Too bad for them. Correcting boot problems are probably a low priority on their "fix-it" list.
GRUB's failed potential Posted Jan 23, 2008 16:21 UTC (Wed) by mheily (guest, #27123) [Link] Multiboot is a GNU invention, not a standard, so one can hardly consider the BSD's to be "defective" in this case. Is the Linux kernel "defective" because it doesn't implement kqueue(4) from FreeBSD, or support ZFS from Sun? Using the 'chainloader' function of GRUB to invoke a BSD bootloader works fine for the vast majority of people. I use this setup on my desktop machine, in fact. It seems to me that Multiboot is a solution in search of a problem.
GRUB's failed potential Posted Jan 23, 2008 10:58 UTC (Wed) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] Multiboot spec is crap in the fact that you could not boot an OS on a PC without a minimum information from the BIOS, and you have none at all with that way to boot. It is not even simple to return to real mode from a multiboot kernel because the loading of the operating system may have overwritten important memory. I myself use Gujin to load kernels for the last few years, but I am biased (http://gujin.org). I still like its behaviour (i.e. autoconfiguration) when using multiple distributions (kernel up/downgrades) and removeable hardware (changing hard disks, USB keys containing complete distributions, boot from DVDs or images of DVD in a partitions, boot from DOS)... The main problem of Grub is which grub.conf will be used if you have 4 distributions, each of them using Grub, and have booted from a USB key. Etienne.
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 23, 2008 3:26 UTC (Wed) by PO8 (guest, #41661) [Link] "For the novice, start with LILO and then migrate to GRUB" is one of the worst pieces of technical advice I've seen in a while. LILO is a special hazard to novices, due to all the ways it can accidentally render your system unbootable, and the difficulty of recovering when it happens. For the novice---what are you doing messing with bootloaders? Let your OS distro install its bootloader of choice, and don't second-guess it. (If your distro is not Windows, in 2008 it will almost surely install GRUB.)
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 23, 2008 16:42 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link] Interestingly, Mandriva still use Lilo by default. I asked about this, and received an interesting answer: Yes, lilo requires you to run /sbin/lilo, but at least you have then verified that everything is OK. (And the distro updater will do this for you). Although grub is great for recovery (error in menu.list -> can't find a kernel? Just use the inbuilt find function), if you had used lilo, you wouldn't have got into this state.
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 24, 2008 2:10 UTC (Thu) by sward (subscriber, #6416) [Link] Err, no. Mandriva 2008.0 (Oct. 2007) used GRUB by default, at least on my installs.
kboot Posted Jan 23, 2008 18:10 UTC (Wed) by larryr (guest, #4030) [Link] Something I would like to see for regular PCs is ubiquitous use of the first cylinder or so, maybe 8MB, before the first partition, used for the bootloader, and a minimal Linux+initrd installed there. I think LILO and GRUB are both hideous and anachronistic. Larry@Riedel.org
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 23, 2008 18:35 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] I've been using lilo for a _long_ time and still install it on my systems for one very simple reason it's simple, and it's easy to identify what's happening with it. I've been bit several times with grub doing what it thought I meant it to do. simple is good (in this case rock-solid reliable, once you learn how to use it)
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 23, 2008 21:15 UTC (Wed) by muwlgr (guest, #35359) [Link] Seconding that. LILO is my long-time favorite and I still don't see reasons to use GRUB instead of it. Although it would be even simpler and easier to allocate a special boot partition and store boot image and initrd there in contiguously allocated blocks. Like you would see in AIX.
LILO and GRUB: Boot Loaders Made Simple (O'ReillyNet) Posted Jan 23, 2008 21:11 UTC (Wed) by muwlgr (guest, #35359) [Link] http://groups.google.com/group/comp.os.plan9/msg/2b2e7752... "> What is it that grub is unifying? Pain. More pain in one place."
|
|||||||||||||