Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After the BIOS, or something similar that serves as a firmware, is started, the control is passed to the bootloader, as far as I know.

Why can't the BIOS load the OS kernel directly?

Also, the GRUB manual says: briefly, a boot loader is the first software program that runs when a computer starts. Isn't the BIOS the first program that runs?

share|improve this question

A BIOS would need to know how to load a kernel, and this would make the BIOS overly complicated: imagine a BIOS that needs to know how to load the many different operating systems available, how to pass kernel parameters to them etc...

Thus, it only initializes the hardware and jumps to a known place where the bootloader is stored; then, the control is passed to it.

From The Unix and Internet Fundamentals HOWTO:

You may wonder why the BIOS doesn't load the kernel directly — why the two-step process with the boot loader? Well, the BIOS isn't very smart. In fact it's very stupid, and Linux doesn't use it at all after boot time. It was originally written for primitive 8-bit PCs with tiny disks, and literally can't access enough of the disk to load the kernel directly. The boot loader step also lets you start one of several operating systems off different places on your disk, in the unlikely event that Unix isn't good enough for you.

As for the BIOS being the first program that runs: (from Wikipedia)

The BIOS software is built into the PC, and is the first code run by a PC when powered on ('boot firmware').

But a firmware is software. So I would assume the GRUB manual is at least confusing on that part; the bootloader can be seen as the first user-defined piece of software that runs on the computer.

share|improve this answer

The reason is flexibility. You might have several different OSes on one hard disk (Windows, Linux, etc.), or you might have several different versions of the same OS. Therefore, it is better to have a OS-independed piece of code that knows where each OS installed on the hard disk resides, how to load each of them, which one to load, whether to present a menu or not, etc. This is a bootloader.

BIOS loads and executes code located in a pre-defined location on a hard disk (first sector). We call this code a bootloader, but technically if you installed Windows on a blank hard disk, this code is installed by Windows too, so you can call it part of Windows, especially since Windows bootloader cannot load any other OS besides Windows.

Regarding first software program that runs when a computer starts: the firmware/software distinction is pretty thin, and modern computer's startup process is very complicated. BIOS in itself is also not a monolithic program, but several distinct stages chained together. However, bootloader is the first user-changable code that runs. This is the first piece of code that the user can damage, erase, infect with a virus, etc. So I suppose while technically BIOS is the first software that runs, bootloader is first in a sense that if computer doesn't boot user needs to check whether it is ok.

share|improve this answer
From experience, a user can certainly break the BIOS. – OrangeDog May 28 '12 at 8:59

Why can't the BIOS load the OS kernel directly?

Three reasons:

  • The BIOS on the original PC platform when it was introduced in 1981 was meant to function in the same role as that in the CP/M operating system - namely, a thin abstraction layer for a couple of devices and a simple disk bootloader. CP/M had another layer called the "BDOS" which handled the filesystem. DOS was similar to CP/M in many respects as it was the operating system in vogue at the time, and was structured similarly. BIOS was intended to handle hardware-specific aspects of the platform, a role that drivers in OSes fulfill now.

  • The notion of a file system as separate from the OS didn't really take hold yet.

  • At this time, RAM and ROM were expensive and scarce resources. The original IBM 5150 PC could be obtained with as little as 16K of RAM (reference). The ROM size of this system was 48K and that included a BASIC interpreter. There wasn't such a thing as a standard file system at that time either.

Since DOS grew to become the most popular OS for this platform, and Windows thereafter, which worked with this setup, no one thought to extend the BIOS in this fashion to include real bootloading capability.

I'm not sure of UEFI's capabilities - it may have real bootloading capability that isn't used by Windows for one reason or another (Windows insists on using it's own boot manager when you install it). Other non-BIOS firmwares like U-Boot and those in many phones and routers do load and run kernels directly. There hasn't been a technical reason for it since when BIOSes started to have room in ROM to do more things.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .