Re: Grub

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Back in the times when I was introducing myself to the PC technology for the 
first time, I stumbled upon a so called "Hardware Book" (don't have it any 
more, so cannot give a reference, sorry...). Looking at the contents, my 
attention was drawn to the question "what happens when you turn on the 
computer?", and while answering in my head "OS gets loaded, of course" I 
turned the pages to see what the author had to say about it. And to my 
surprise, there the question was repeated, more specific: "what happens 
between the points of pushing the power button and the point when OS starts 
to load?" ;-)

I was amazed !! The sequence of actions was explained in a way that did not 
need any too technical background knowledge, while at the same time it was 
extremely detailed. It started off along the lines of "voltage on the 
circuitry rises, and the oscillator starts ticking. The first few ticks 
activate a circuit that sends a reset signal to the processor...".

The moral of the story: it was way more complicated than I thought, while the 
author was stating that the answer is somewhat oversimplified...

On Saturday 18 August 2007 19:27, Karl Larsen wrote:
>     All computers have a bios that does many things.

True. But beware of what the bios exactly is!! The screen that you get to see 
when pressing the del button is called "bios setup", which is a user 
interface between a human and the bios, not the bios itself. The bios is a 
set of routines (programs) that are stored in ROM (ie. on a chip) somewhere 
on the motherboard. These routines include the information on how to write 
letters to the screen, how to read or write the data on the disk, how to 
communicate with serial controller (for example), how to allocate memory, 
etc. In essence, it is an *operating system*, a rudimentary one, but 
conceptually much like the Linux or Windows kernels. It serves the same 
purpose, if you do not have a better one loaded in RAM memory.

>     The one thing I'm 
> interested in today is it's assignment of hard drives that are ide
> devices. On my bios it reads the hard drive and finds out if it is set
> as a Master or a Slave. It puts them in it's list in that way.

Not quite. The bios does not "read the hard drive". It asks the disk 
controller to provide the data about the disk parameters. That data is stored 
on a chip on disks firmware, and the controller provides it. No data on the 
actual disk gets accessed. Yet.

>     Once it has the hard drives assigned the bios is done.

Wrong. Among other things, the bios decides from what device is the OS to boot 
(that is defined in the bootup sequence of the setup), and then needs to 
*read* the Master Boot Record (the very first 512 bytes of that device), and 
execute the code that should be there. Note that this is the first point 
where bios has to actually access the data on the disk. And that is the very 
beginning of the disk. And only 512 bytes. And that data is the primary 
bootloader. Grub, for example, or Windows bootloader, or whatever...

>     Now in Linux 
> there is the new Grub which is pretty simple. It stores all it's stuff
> at /boot/grub/ and it puts the file grub.conf in /etc/. It needs to put
> some information in the Master Boot Record part of a hard drive so it
> can read that information and boot the proper system.

Just to clarify a couple of points.

First, the "information" found in MBR, as I explained above, is grub itself. 
The executable program. A set of instructions that the processor is to 
execute in order to load the OS. A set of instructions that is AT MOST 512 
bytes long. It is a very *small* program. And being small, it is not very 
bright itself --- it depends on the bios routines. Remember, the bios is the 
only operating system at this point. Grub is a program executed under this 
OS, and depends on it, in the same way firefox or evolution or whatever 
depends on the Linux kernel.

Second, the system is not yet aware that there is a filesystem on the disk. 
The notions of /boot/grub/ and /etc/ are written somewhere on the disk, but 
there is no kernel to provide access to them. The only thing that *can* read 
the disk is the *bios*, and in a very clumsy way --- the program that wants 
the data needs to specify the hardware position where the data is written 
down, and ask the bios to instruct the controller to move the heads to the 
appropriate position and read off the data. When grub wants to read its 
configuration data from /etc/grub.conf, that is precisely what it needs to 
do. ASK THE BIOS TO READ IT. And based on that information, a kernel 
executable should be loaded (and executed). The kernel executable is a file 
called vmlinuz-something, residing in /boot/. So how does grub read the 
kernel file? ASK THE BIOS TO READ IT.

And now we get to the point. Some bioses do not read past the 1024 cylinder. 
If the kernel file is beyond that point, bios fails to read it. So grub fails 
also. And the computer does not boot.

Note that this has nothing to do with the number 160 GB that is displayed in 
the setup menus. That number is just what disk controller reports to the bios 
when asked for the size. It has nothing to do with bios being (un)able to 
read the disk of that size.

So, in order to make sure that the kernel file is below the 1024 cylinder, the 
user (the human user) must put it there. That amounts to setting up a 
separate /boot partition during the installation of Fedora. That partition 
must be on the beginning of the drive, and must be small enough in order to 
fit below the 1024 cylinders. If that is the case, all kernels will 
afterwards be written there, and the bios can access them during bootup.

However, if the human user thinks he is smart enough, and does not create 
the /boot partition, but only one huge / partition, the place where the 
kernel will be subsequently written down is a complete gamble. It *may* be 
below 1024 cylinder, but it also *may not*. When the OS gets updated, newer 
kernel files are written down to disk, *somewhere*, and there is no guarantee 
that this "somewhere" is below the famous cylinder limit. So the next time 
system boots, grub tries to load the newest kernel, bios hits the wall, grub 
fails, and the computer won't boot.

What the user sees, is that after a yum update grub fails on reboot. 
Naturally, the user blames the update and grub, while the actual culprits are 
the hardware limit of an old bios, and pebkac, playing smart with partitions.

Two last notes to clarify --- if the bios succeeds to load the kernel, it gets 
executed. But the kernel is much larger than 512 bytes, and there is space 
for the code of the "driver", a program that can talk directly to the disk 
controller, and read/write files to the disk **without** asking bios to do it 
for him. That's why once the kernel is loaded, it is irrelevant whether or 
not the bios can access beyond 1024 cylinder. The kernel sees the whole 
drive, irrespective of the bios. And the other note --- this whole story is 
(or should be, afaik) completely the same whether one uses grub, lilo, 
ntloader (ie. windows), Fedora, SuSE, *buntu, Windows, *BSD, MS DOS, or 
whatever. The process of booting is the same, for all PC hardware, whatever 
the software is to be booted. While of course it may be different for Mac, 
Commodore, Sparc, Amiga, Atari, and other non-PC architectures.

I hope that it is now a bit more clear as to what is going on between bios, 
grub, kernel and the disk, during the boot process. ;-)

Best regards, :-)
Marko

Marko Vojinovic
Institute of Physics
University of Belgrade
======================
e-mail: vmarko@xxxxxxxxxxxx



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux