Slashdot Mirror
The Boot Loader Showdown
Francesca writes "What utility do practically all Linux users use, regardless of their job or expertise? A boot loader. In this article from IBM, see how a boot loader works, meet two popular loaders -- LILO (LInux LOader) and GNU GRUB (GRand Unified Boot loader) -- and review the pros and cons of each." From the article: "Most simply, a boot loader loads the operating system. When your machine loads its operating system, the BIOS reads the first 512 bytes of your bootable media (which is known as the master boot record, or MBR). You can store the boot record of only one operating system in a single MBR, so a problem becomes apparent when you require multiple operating systems. Hence the need for more flexible boot loaders."
What kind of study would fail to include THE single most popular and widespread bootloader in the world?
That would be...Windows Boot Manager.
*Bangs head on table* Now I wish I had this page when I tried to install Gentoo over the weekend. Call me dumb but I couldn't get it to dual boot with Grub. Worked great with Lilo tho :)
Its just a shame you have to rewrite Lilo stage 1 when you change stuff. Though I've never really got the hang of the Grub command line (why -1 for partitions, eh?!) so I'll stick with Lilo - its easy enough with a boot or livecd to fix anyhow.
Grub's quicker though isn't it?
Dug
There are pros to Lilo?
It's such a heap of crap. The only reason it's still used is because people were brought up on it.
I use AMD64 Gentoo, dual booting with Windows XP Pro. Of course, LILO doesn't work with AMD64, so I have to use Grub. The bad part here is that Grub hangs whenever I try to get it to load Windows. I don't think it likes a 32 bit kernel image. So.... I have to go into the BIOS and change primary boot drives everytime I want to switch. I want a bootloader that can do that for me, or at least a way to make Grub do it. (Of course, I never really boot into Windows...)
I logged in as root and got:
/sbin/lilo -v -v
/sbin/lilo -v -v
;-)
[root@localhost root]#
Then I typed:
#
And nothing happened... The entire line looked like:
root@localhost root]# #
What is wrong here?
LedgerSMB: Open source Accounting/ERP
then microsoft could write a winLoader to load windows if you wanted to dual boot your linux machine :-)
seriosly for anyone who uses linux clusters or is otherwise uninterested in Dual boot, it makes sense to flash you roms and get it over with.
Some drink at the fountain of knowledge. Others just gargle.
We gentoo users look at it every time we upgrade the kernel :)
I used to be a Lilo fan, until I ran into trouble with it on my IBM laptop -- it took WAY longer at the part where it loads the kernel to memory than it had any business to, a stage that goes by so fast it's easy to miss on most computers. Yeah, it's got a P4-based Celery in it, but my laptop's not THAT slow. I've seen Pentium I systems go through that stage faster.
Switched to Grub, problem went away. Whatever. Guess I'll just use it from now on.
I've played around with Ubuntu and now want to get all my disk space back. I'm running Windows XP. How do I uninstall grub safely so that the computer just boots into WinXP?
Sounds like a stupid thing, since no one would ever want to uninstall linux, but why is this information so hard to find?
Personally, this makes it hard for me to tell friends to try out linux. Because trying it out may mean having grub (or lilo) installed forever...
Help! I'm a slashdot refugee.
Given all the concern with rootkits, backdoors, worms, spyware, et al, it would seem that a nonflash-ROM bootloader could provide a secure micro-OS that in turn checks and helps maintain the integrity of the main OS. A boot-time diagnostic and some key read-only API code segments (encompassing access to crucial functions such as encryption, hash calculation, memory access, disk access, UI access, network access, etc.) would help ensure that the main OS was not compromised and was less susceptible to malware.
A small OS, even one with a GUI, can fit in less than a MB. Perhaps a heavily secured, stripped-down copy of some stable version of *nix could provide a high-integrity read-only core underlying a more sophisticated, extensible, and flexible full-featured OS.
Two wrongs don't make a right, but three lefts do.
You mean without WinGrub? I use it with Windows XP/Fedora Core 4 and love it.
As for LILO...never tried it.
You can hold down the "B" button for continuous firing.
LILO's "compact" option would probably have helped you out here.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
- Mac OS X will bring some of the most tech-phobic users to Intel in mid-2006 and much will be talked about setting up one's computer to boot different OS's if there is no "Red Box" included.
- Boot loaders are a big security point of failure and may rise again as a popular exploit if easier targets like Word Macros ever die off. IMHO knowledge is better protection than ignorance though.
- Declining interest in boot loaders could solidify Microsoft's goal of being the only OS people want to use. Open Source boot loaders aim for versatility; Microsoft aims for extreme ease of use and zero versatility. If the first chapter of every linux install book is how to troubleshoot your boot loader; this is great at maintaining Windows monopoly.
Boot loaders aren't really sexy, but they are important. Hence any article that tries to build some interest in them is a good thing (even if this one may have some imperfections in it).You have no choice in the matter. The end.
I Browse at +4 Flamebait
Open Source Sysadmin
Just for reference. fixboot fixes something else (NTLDR? first sector of booting partition? I forget...).
You can hold down the "B" button for continuous firing.
If you log in as root, you might see a prompt that ends in #.
:-)
If you type # in a Bash shell, the rest of the line is handled as a comment.
But it is convention to tell users to type a command and start it with a # to denote root login. If you type the # however, Bash interprets it as a comment and doesn't do anything
LedgerSMB: Open source Accounting/ERP
GRUB rocks. Its just too easy to render a computer unbootable with LILO (not permanently, of course; but it's still annoying). Why should I have to rewrite the boot sector just because I want to change what I call a particular boot option?
Interesting to hear of people's GRUB problems with Windows - I've never had an issue with this. My dual boot machines have been 98SE or XP Pro alongside Red Hat or Fedora. GRUB setup works out of the box. I've got to admit I've only used multiple partitions on one disk though - never done it with different OSes on different disks.
#DeleteChrome
My GOD you are unimaginative. It's so upsettingly obvious for everyone outside the x86 world that the lot of us are just plain laughing when this issue is brought up.
For a weekend project, I was planning on rebuilding the OS on a spare PC I have.
I was just about to install a flexible boot loader. Tell me more about your better BIOS. I'm sure I'll be enjoying it this evening instead of the dumb old boot loader I was about to install.
Oh wait, you weren't solving a problem, you were merely suggesting an entirely new platform. Oh, oh ho ho ha ha, silly me. Yes, honestly, why isn't it that all these stupid people don't develop a completely new architecture to deal with every nuanced problem that arises? Surely, sir, you are a genius.
To load Windows, GRUB just chain-loads the bootloader on the primary Windows partition (what Windows will use as C: drive). That's actually 16 bit code, even on AMD64.
WinXP 64 bit ed may be different, but your post suggests you're using the basic XP.
If I recall correctly a definition like:
root (hd0,0)
chainload +1
should do the trick (adjusting root to match your win32 c: ). I use Fedora, so to be honest it "just works".
*HOWEVER* it sounds like you're trying to boot XP off a secondary disk. If XP thinks that disk is the primary disk (ie you installed XP then rearranged the disks), it'll get really confused when you load its boot sector, and will fail to boot. I don't know if it's an easy thing to fix - I've always just installed windows where I expect it to live (it installs quite happily on a secondary disk).
You might be able to boot the XP cd, run "fixboot" and "fixmbr" from the recovery console, then re-install GRUB from a Linux rescue CD.
Anyone remember XOSL? I thought it was great.
Unfortunately the Open Source model didn't work
out so great for it:
http://xosl.sourceforge.net/manifesto.html
No longer active..
Mirror of the Original Site:
http://www2.arnes.si/~fkomar/xosl.org/
The author says "Unlike the Linux boot loaders, the majority of Windows boot loaders will not allow you to load Linux."
o ft Windows 2000 Professional" /fastdetect
I don't know what he calls a majority, but the NT loader (used by Windows NT, 2K, XP, 2003) can boot Linux. It's just that Microsoft is being a pain about it. You have to first dd the first 512 bytes of your partition, save those to a file, and create an entry in boot.ini which points to that file.
For example:
dd if=/dev/hda1 of=/mnt/cpart/linux.mbr bs=512 count=1
[Boot Loader]
Timeout=5
Default=multi(0)disk(0)rdisk(0)partition(4)\WINNT
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(4)\WINNT="Micros
C:\linux.mbr = "Linux"
It's better to try something like Smart Boot Manager. It brings up a menu allowing you to boot from any of your listed devices.
I have used it several times when installing Linux on older laptops that do not allow CD-booting.
Grub *seems* to be undeveloped but some brave guys are developing grub-2, which looks much nicer...
http://www.gnu.org/software/grub/grub-2.en.html
It does not need to understand the fs of all systems it is to boot.
At minimum it needs to understand the fs that the stage2 files are stored.
You can then use the chainloader to boot the boot loader on an individual partition. eg the windows bootloader on your c: ntfs partition. ie the way you suggested
Of course if grub knows something about your kernel and the fs it is n, then it can do a lot more for you.
For me the main thing about grub is that it does not need to be configured in advanced, so it make a good rescue disk.
I don't have the links, but Google is your friend:
/boot partition if it doesn't natively support your / partition.
XOSL -- Xtended Operating System Loader
Pros:
- an actual GUI in a bootloader
- support for loading keystrokes into the keybuffer, which gives it indirect support for simpler keystroke-based bootloaders like Lilo -- it can "type" in a kernel name for Lilo to load.
- relatively easy to install from Win98 -- I believe it can even use a FAT partition to store its stuff on.
- Password protection, can boot a default entry after a timeout.
- Entirely configurable from inside the bootloader -- and it's user-friendly, due to the built-in windowing system.
Cons:
- Not much direct support for anything. While it can load Linux through Grub or Lilo, and it can boot CDs through SmartBootManager, it's really a very simplistic x86 bootloader with a very advanced GUI.
- Support for booting a default requires a timeout, meaning that 90% of the time, when you're just booting the default OS, you have to wait an extra few seconds or press a keystroke -- and if you don't want to boot the default OS, you have to hit a key at just the right time to select a different one.
- Doesn't seem to be configurable outside the bootloader, meaning if you download a howto on configuring XOSL, you have to print it out and reboot in order to configure.
GRUB: Grand Unified Bootloader
Pros:
- Only bootloader I know of that supports the Multiboot spec, which unfortunately is a "standard" supported by only one bootloader (Grub) and one OS (Hurd) -- but it's still pretty cool that Grub could, in theory, insert kernel modules on boot, eliminating most initrds.
- Contains a built-in commandline and actual FS support, so a mistyped or forgotten menu entry is no problem -- type it in manually to boot, then fix the menu entry from your main OS, not a rescue disk.
- Powerful menu system -- the "configfile" command allows for multiple nested menus. Password protection.
- Config file is readable an Unix-ey, and is a plain Unix text file parsed directly by Grub -- no need to type a command after each kernel update.
- Supports booting from PXE (giving multiple netbooted images as a menu)
- Supports booting from CD, allowing an easy menu to access multiple kernels and tools like memtest86.
Cons:
- Like XOSL, it lacks actual support for booting from CDs or net. You can install it to a CD or Net, in which case you can probably also boot stuff from the hard drive, but if it's run from the hard drive, it can't boot CD or net.
- Lacks XOSL's keybuffer feature (which is probabyl unique), meaning if you want to use SmartBootManager to boot a CD, you will see the Grub menu, and then the SBM menu.
- Since it groks FSes, you may need a separate
- Commandline, while useful, really only protects you from typos in grub.conf. It doesn't protect you from forgetting to install Grub to the MBR in the first place, or reinstalling if the stage 1.5 files got physically moved around.
- Like XOSL, booting a default requires a timeout.
NTLDR -- NT Loader
Pros:
- Already installed on Windows NT based OSes.
- Supports NTFS, and can boot most x86 boot images if they are available on the boot NTFS partition.
- Plain-text config file.
Cons:
- No native support for anything but NT and chainloading (x86 boot images)
- Menu system is bad. It seems locked into a 30 second timeout, and like XOSL and GRUB, you have to have the timeout to have a default.
- No native support for booting other partitions -- this can be accomplished by putting Grub or another bootloader into an image file, but it's not a trivial process, especially considering you have to redo it often.
- Not open source. It has limitations, and you can't do a damn thing about it.
Lilo -- Linux Loader
Pros:
- Dirt simple. No flashy menus or windows or FS support -- it just loads a kernel and goes.
- Plain text config file, with a simple command t
Don't thank God, thank a doctor!
How have things changed over the last year when it comes to booting from usb pendisk or hard disk whatever?
Every time I try it, it's still not quite there. For instance, I can boot knoppix 3.9 from my usb cdrom but once it loads far enough it can't find the usb cdrom and loses track of it's filesystem consequently. That always bugged me considering it can boot from it just fine. I'd love to have a rescue usb pen drive that had both windows and linux bootable rescue installations available. I've never been able to pull it off.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Compatibility reasons. Why do modern x86 processors still have an A20 gate? Or, for that matter, why does Real Mode still exist? There's no real reason for it if you're only running modern OSes, but Intel/AMD/... know that there *will* be flak if they do get rid of these - somewhere, someone's still using DOS or something similar, and wants to be able to continue to do so.
That's it, mostly.
quidquid latine dictum sit altum videtur.
Well, I don't dual boot but i still use LILO/GRUB. Why? Because every time I recompile a new kernel, I add a new entry to the bootloader menu so I can easily access the old kernel in case something went wrong. Or to add a "safe mode" or such that allows me to avoid to type dozens of params. It's pretty useful.
nbody2002:If you can read this you may be addicted to the internet
Having rebuilt a multitude of x86 hardware and fought several times with the oddities of the PC legacy, the choice between LILO and GRUB is a no-brainer to me.
... and you need to get into a running Linux system to fix the boot loader "settings". If the hardware is unsupported by the live CD you have at your fingertips (e.g. MegaRAID) you are royally screwed up.
...), you can just try around like root(hd0,0) ... root(hd1,0) ... etc. until you find your partition.
... functionality with which one can select an image to boot into just once. If this fails and you remotely reset the server, it boots back into a known good state. Very handy to try dangerous changes to a remote server.
Every now and then, after changing/reordering hard drives (from on-board to off-board etc.), changing the controller etc. LILO might stuck somewhere like LI or 0101010101 or
With GRUB, as long as the stage 2 gets loaded, you can always change the settings manually from within a minimalistic command line. If you do not know which drive gets which number from the BIOS (0x80, 0x81,
The only reason I kept LILO on some headless servers co-located at some distant places was the lilo -R
Now that GRUB also provides this option with grub-reboot and GRUB can also be set up with a nice graphical splash screen, there is no reason why I would ever want to install LILO.
Mark
- Install Linux on any free partition on any drive -- during the install process, dont bother installing a boot record or boot sector anywhere.
-
Copy grldr.exe and menu.lst from http://grub4dos.sf.net/ into c:\ .
-
Edit c:\menu.lst to point to the correct partition, directory, and filenames for any/all of the kernel and initrd's you installed on the linux partition:
-
Addto c:\boot.ini .
Done. Notes:The best thing about grub is that as long as it's correctly loaded onto your MBR (not particularly difficult) you don't really need a config file at all. Anything which can go in the config file can be typed at the command-line. That's really useful in a bootloader, which otherwise can be particularly difficult to fix when you make a boneheaded mistake. GRUB has saved me several times with this feature. It's also handy when you want to boot into a different runlevel or whatever, it's easy to edit the kernel parameters before booting.
/sbin/lilo to update the MBR.
The other best thing is that you don't need to do much when you do something like install a new kernel or initrd; just update the config file (and you really don't even need to do that, see above). With Lilo you have to remember to run
The worst thing about GRUB is that it was written for the Hurd, and has a Hurd-centric view of disks which can be difficult to work with in other operating systems.