Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Boot Loader Showdown

Posted by CmdrTaco on from the why-that-never-became-a-holy-war-i'll-never-know dept.

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.""

7 of 281 comments (clear)

  1. Re:Both! by Hal_Porter · · Score: 4, Informative

    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;
  2. Re:Both! by alexhs · · Score: 4, Informative

    > Install Grub on the Linux partition, and use Lilo to load it.

    Why use LILO at all, then ? You can use mbr (http://packages.debian.org/stable/base/mbr), or even the dos / windows one (fdisk /mbr), which will silently boot the active partition, that you will set to the one containing the secondary boot loader you're using.

    --
    I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
  3. Other lesser known boot loaders... by ylikone · · Score: 5, Informative
    XOSL (graphical)

    GAG (graphical)

    Gujin

    Syslinux

    --
    Meh.
  4. Re:GRUB! by Lussarn · · Score: 5, Informative

    Try enable "USB Legacy support" or similiar in BIOS. Has helped me every time.

  5. How to program a bootstrap loader by uriah923 · · Score: 5, Informative

    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?"
  6. Conclusion? The PC bios is a relic. by master_p · · Score: 4, Informative

    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.

  7. Another approach - how QNX does it by Animats · · Score: 4, Informative
    QNX has a rather different approach, because it runs on non-PC hardware and can't assume there's a BIOS to get things started. QNX uses a program called "mkifs" to build an "OS file system", which is a bootable image. This contains not only the operating system kernel, but any other programs and files you want available during the boot process. Even user programs and shared objects. You can build your own bootable image, with whatever programs you want in it.

    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.