Slashdot Mirror
The Boot Loader Showdown
An anonymous reader 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.""
For anyone getting ready to load a Linux instance on a VMWare virtual machine, save yourself some time and use LILO. GRUB does not work as best I can tell. Boots to a fun error message after initial install. LILO works like a charm.
You can specify a boot sector in boot.ini. It needs this so it can boot Win98, Dos and so on. You can use it to load pretty much any OS though.
http://www.highlandsun.com/hyc/linuxboot.html
Or you could turn off boot sector checks in the virus protection.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
> Install Grub on the Linux partition, and use Lilo to load it.
/mbr), which will silently boot the active partition, that you will set to the one containing the secondary boot loader you're using.
Why use LILO at all, then ? You can use mbr (http://packages.debian.org/stable/base/mbr), or even the dos / windows one (fdisk
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
If you don't want grub, you need to *REPLACE* the MBR with something else, like LILO or plain old DOS FDISK /MBR.
You are being MICROattacked, from various angles, in a SOFT manner.
No 'showdown' is needed. Aren't there enough flamewars around the Web as it is? Technically, both bootloaders are good. Use the one that works best for you.
Politically, if you must use only GPL software, then go with GRUB. LILO has a _very_ open license, but it does not meet RMS's strict and unyeilding requirements.
GRUB SUCKS!
Until they support USB keyboards that is. Maybe the bleeding edge versions do now but everything shipped with a distro lately does not. in LILO I can use a usb keyboard, GRUB for some reason decided to do things differently and ignores USB keyboard input.. which sucks big time on a new machine that has nothing but USB.
Do not look at laser with remaining good eye.
You beat me to it. I was using LILO on my last system, and installing my most recent one, GRUB was the default boot loader. Only problem being that / and /boot are both software RAID1, which once I found the magical incantation worked flawlessly under LILO. Apparently GRUB and my BIOS disagree as to what disk is actually the first though, so after a bit of frantic googling from a system that worked, I discovered I needed to tell the BIOS to boot disk 3. Joy. I also can't believe that GRUB's made it this far without native support for booting from any raid disk in the array...
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
GAG (graphical)
Gujin
Syslinux
Meh.
.. because, an OS has one of two choices. Either it uses it's own boot loader, or it requires a third party one.
I don't know anything about ReactOS, but Windows ships with it's own, and always has since 95. If you installed "real" Windows on this computer, it would overwrite the MBR and get rid of Grub. But if installing RactOS does *not* do this, then it likely does not ship with it's own boot loader, so you would *have* to use Grub or some other tool to load it.
Unless it uses the old DOS boot loader but does not ship with it, which would be very weird.
In any case, you can download DOS boot disk images from bootdisk.com and fdisk /mbr, no problem. (if you don't have a flyppy drive, just use the image to make a bootable CD.)
Try enable "USB Legacy support" or similiar in BIOS. Has helped me every time.
I'm a diehard LILO user, it works for chuff's sake so don't muck with it, but the issue you are seeing is not the fault of the bootstrap loader.
Any bootstrap loader, be it GRUB, LILO or NTLDR.EXE, must necessarily use the BIOS to interact with the hardware, because no drivers are loaded yet.
Your BIOS setup should have an option something like "legacy USB keyboard" which takes the keystrokes from the USB keyboard and makes them appear to have come from the "old style" keyboard instead. Enable this and GRUB should work.
Je fume. Tu fumes. Nous fûmes!
This article explains how to write your own boot sector. The tutorial includes assembly language code to demonstrate loading and executing a binary image from a FAT filesystem. It's also an interesting read if you want to understand the fundamentals of the X86 boot process.
-Brandon "How much you wanna make a bet I can throw a football over them mountains?"
What do you use that to do? Grub booted my raid1 flawlessly, just map (hd0) and (hd0,0) to the /dev nodes and install normally.
I am trolling
LILO is still actively developed and handles things like RAID disks and special hardware much better than GRUB (which is why it still ships with all the various distributions).
Oh, I see. Claim Linux can't do something, then wait for everyone to fall over themselves to prove Linux is teh r0x0rs!!! This almost seems a troll since SuSe, Mandriva, and Fedora have been doing exactly what you're asking about for quite some time.
Anyway, check out Bootsplash, it does what you're looking for.
If thou see a fair woman pay court to her, for thus thou wilt obtain love
Amen to that! The current workaround is a script known as grub-reboot. Unfortunately it doesn't seem to come by default in Fedora, but you can download it off the net if you google it. Here's the man page
If thou see a fair woman pay court to her, for thus thou wilt obtain love
Slackware continues to ship with LILO as the default boot loader. The other option is loadlin. Grub is not even included. Slackware's motto is Keep It Simple [Stupid], and while Grub does have features that LILO lacks, it is more complicated, and so is not shipped with Slackware.
peace
True enough... unless some new kinds of boot devices (such as SATA) come out, which might necessitate additional development...
there isn't much to add to it as it is,
There's one feature that's been sorely missing: the equivalent of lilo's -R option (boot another OS once).
With their proclaimed feature-freeze, there's not much point waiting for this...
The main thing Grub has against it is that it's relatively ugly.
And ugly it is... I especially hate the "nice" curses interface of the grub installer which does a very good job of hiding critical error messages and making sure that no missing rescue-CD goes unpunished ;-) Even export TERM=dumb is not enough to take care of the issue. Do I really have to use a hex-editor to see the error-output of a program?
The fact that the 1.x branch isn't actively developed is quite irrelevant.
Well, except that it isn't even 1.x yet, it's still 0.9x. So, basically, it has been declared obsolete before it even reached maturity. Way to go!
Should it suddenly stop working, well, there are lots of other similar programs available.
Such as Lilo ;-)
BIOS by default booted disk 1,2,3,4. Grub wouldn't boot unless 3 was first. Which has some interesting implications for reliably booting a sw raid setup with grub, unless you go through a wholly manual process of telling grub to explicitly put the MBR on each disk, and then either edit the boot config in grub when needed, or have duplicate entries for each disk changing the root line each time.
And why in the world would BIOS *ever* handle a linux software raid setup itself?
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
It's all about what you're familiar with. I used to be a LILO affectionado and moaned when Redhat moved to GRUB. But once I learned GRUB, I found it to be much more powerful and easier to use than LILO. That's just me though. I'm the same guy who tells everyone I know, "If there's a hard way to do something, I'm there before anyone else". ;P
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Why isn't the PC bios responsible for loading O/Ses? because the PC bios is a relic, a leftover from the days of 8086. Why aren't bioses 32-bit? why PCs still have to boot in real mode?
Bootloaders are very clever pieces of coding, but their presence makes it difficult for PC bioses to be replaced.
Grub can do it too.
e
Check this out: http://gentoo-wiki.com/HOWTO_Remote_Kernel_Upgrad
isomerica.net | Foonetic IRC
How about this?
grub> savedefault --default=1 --once
Use it in a script, type it by hand, put it in grub.conf, etc. Works for me.
With this approach, there's no need to put drivers needed at boot time in the kernel. (Drivers are user programs under QNX.) The kernel doesn't need to know about disks. If you want a GUI during boot, you can have it. For embedded systems, the entire "OS file system" can be put in ROM, eliminating any need for a disk. For desktop x86 systems, there's a standard bootable "OS file system" which has all the usual disk and display drivers, the bus enumerators and plug-and-play handler, and the rest of the stuff needed to start an x86 PC. But all that startup stuff isn't in the kernel.
This is especially useful when your target is something that doesn't have a keyboard and screen. That's why QNX does this. Doing it this way cleans much startup-only junk out of the kernel.
The Minix 3 people, unfortunately, didn't get this, so their "microkernel" has more stuff in it than it really needs.
A few weeks back, I checked out GRUB2 from CVS and built it on a PowerPC system. It installed and ran just fine, but the kernel hung during booting. It doesn't yet have all the features of GRUB1, but it's certainly showing a lot of promise. As soon as it boots a kernel, I'll be dumping yaboot for it.
GRUB1 works just fine on i386, so just go with that for the time being, and you can upgrade to GRUB2 when it becomes stable.
"Why isn't the PC bios responsible for loading O/Ses?"
1. a BIOS cannot know all possible file systems (FAT-16? FAT-32? NTFS v 1,2,3..? Ext 2? 3? RiserFS 1,2,3,4... xfs?
what if it is on a RAID (ie, multiple devices)?
2. a BIOS cannot know how to handle parameters to all
possible OS versions
"Why aren't bioses 32-bit?"
Some are. It depends entirely on the type of CPU and the memory handling capabilities of that CPU.
"Why PCs still have to boot in real mode?"
1. Because that is the only way to have access to the complete hardware.
2. You have to have physical addresses to know how to map the virtual addresses to physical addresses. And SOMETHING has to setup that virtual to physical mapping.
"Bootloaders are very clever pieces of coding, but their presence makes it difficult for PC bioses to be replaced."
Nonsence. The bootloader is nessesary only because the BIOS doesn't know how to load an OS. If the BIOS could load a single OS, then there would only be one OS, and only one filesystem, which could never be updated.
The PC BIOS is responsible to initialize the entire hardware to a known state (as in, memory works, the PCI bus is functional, the hardware plugged into the PCI is also in a known state). This alone is sufficiently complicated. Then it boots a loader...
Now why can't the BIOS read that loader from ANY device attached?
1. It can only load from devices it is programmed to load from. Such as a single IDE disk, or CDROM. Some can actually configure the USB and load from that. This is three different types of device. Four if you still include the floppy disk.
2. It must know how to tell each device how (and where) to transfer the data into memory. Each device is different, and has a different handling.
Some fancy controllers will include an extension to the BIOS that allows the BIOS to use these controllers for disk access. This has added one or two MORE configuration items to the "BIOS". (Think SCSI). Now what if there are TWO SCSI controllers... which disk? there could be up to 30 different drives across those two controllers. What about tape boots (as in catastrophic recovery)? SCSI CD boots?
And the OS still isn't loaded. Only the information on where to load 512 bytes from.
Actually, this is possible. More cumbersome than with LILO, but it is possible. I've written about the method here. (Scroll down for the GRUB goods.)
You missed the point of the original post.
>for the next boot only.
Note the "only". If the new kernel hangs at boot, or spontano-reboots, the next reboot after that will be with the old and safe kernel. Great for remote or headless/keyboardless machines. Grub has no equivalent to this, and its a reason I sometimes still use lilo.
>There's one feature that's been sorely missing: the equivalent of lilo's -R option (boot another OS once).
You can probably do what you need using Grub's 'savedefault' command, eg
grub> help savedefault
savedefault: savedefault [--stage2=STAGE2_FILE] [--default=DEFAULT] [--once]
Save DEFAULT as the default boot entry in STAGE2_FILE. If
'--once' is specified, the default is reset after the next reboot.
grub> savedefault --default=1 --once
iirc some distro's come with a 'grub-default' (or similar) command for performing this direct from a shell prompt.