I have one built-in hard disk /dev/sda which looks like this:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00042134

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   293048319   146523136   83  Linux
/dev/sda2       293050366   312580095     9764865    5  Extended
/dev/sda5       293050368   312580095     9764864   82  Linux swap / Solaris

Now I can easily find the MBR with xxd /dev/sda | less, it's located in the first sector. According to Wikipedia the VBR must be in the first sector within the first bootable partition, in my case /dev/sda1. But in the first sector of /dev/sda1 I only see zeroes when I do a xxd /dev/sda1 | less.

I actually thought to find binary code of GRUB in there, where could it be then?


It is usually not installed there. Most of the time, GRUB (stage 1) is installed in the MBR only, on Linux.

Although GRUB version 1 will always overflow a little in the 30 kB following the MBR (stage 1.5, i.e. filesystem drivers), with GRUB version 2, the code installed within the MBR can load some other and bigger code (stage 1.5) by raw reading any sectors from the disk (but will usually stick to GRUB 1 behavior -- that is, loading code from the 30 kB after MBR).

Those 30 kB are usually available non-partitionned "free" disk space, because for historical reasons it is pretty rare for the first partition of a disk to start before sector 63, which leaves at least 512*62 = 31 kiB after MBR.

Then, it loads some files, usually from /boot, like the menu (menu.lst or grub.cfg), more filesystem drivers, etc. This is stage 2.

After that, is has enough to launch an OS.

As for the VBR now, it is not commonly used on Linux partitions because it is not reliable enough, but MS Windows usually installs one at the beginning of system (C:\) partitions. GRUB will just execute it if you want to start Windows. This process is called chainloading: a bootloader which launches another one. This also means that the filesystem used there must leave untouched the beginning of its partition, because it could overwrite the VBR otherwise! The amount of "untouched" space available depends on the filesystem, so there is no good guarantee: it could well be very small...

About loading stage 1.5 from an "unusual" place, as I said, GRUB 2 can load its stage 1.5 from any sector on the disk. It may be from a file, but this can be dangerous because the filesystem can decide to move that file to other sectors on the disk anytime (or even worse, fragment it!), and GRUB would need to update the new sector number in the MBR each time...

An interesting case is GUID Partition Tables (GPT). They are too big to ensure that enough space (30 kB) will always be available for stage 1.5. The recommended solution in that case is to use a dedicated "boot loader partition" (not a problem since GPT can support 128 partitions) that will not host a filesystem but GRUB's stage 1.5 data. This way, it shall not move anywere, and you can give it plenty of space.

You should really read wikipedia's GRUB article where I got most of this information.

  • I just found out that apparently on sector 1 of /dev/sda - directly after the MBR - there is a copy of /boot/grub/core.img or /boot/grub/diskboot.img. – JohnnyFromBF Mar 22 '13 at 13:47
  • But how does GRUB have access to the filesystem in this stage? – JohnnyFromBF Mar 22 '13 at 14:11
  • @Ian I think you answered your own question. – a CVn Mar 22 '13 at 14:14
  • @Ian The GRUB code within the MBR (stage 1) is very small (limited by the MBR size), but big enough to load some other code from the disk (stage 1.5 and/or 2), wich can then load modules, and the OS. It is explained in wikipedia. – Totor Mar 22 '13 at 16:15
  • @Ian updated answer. – Totor Mar 25 '13 at 22:02

Actually GRUB2 is not normally installed to a VBR. It recommends against this practice.

It's something like there not being enough space there to bundle a filesystem module for /boot. Historically, MBR disks give you 62 "reserved" sectors for such boot code. (Because the first partition starts on a cylinder boundary. Nowadays we ignore cylinders, but it's aligned to a whole megabyte instead, to support 4K sector drives, help with SSDs / RAID, etc.). You don't get such good guarantees from the VBR.

The message GRUB2 gives you explains that VBR (partition) installs have to rely on saving the block numbers of modules such as a filesystem driver. This is less reliable; it means grub has to be reinstalled when those module files are updated.

  • 1
    You don't "get a whole megabyte" because the first partition starts on a cylinder boundary, but because starting partitions on sector 2048 (1 MB), or a multiple of 2048, permits to avoid all sort of partition/filesystem/raid alignment issues, so it has become best practice. Most of the time, a cylinder is considered to be approx. 8 MB (but cylinder doesn't really mean something anymore nowadays, because we use LBA, not CHS). – Totor Mar 23 '13 at 0:15
  • 1
    Also, there is no such thing as "standard MBR disk". It is a de facto thing, because old MS-DOS used to require that partitions start on "cylinder" boundaries. Linux doesn't care and you can create your partition wherever you want (even before sector 62). However, this de facto practice has become a default setting in Linux fdisk for a while, to ensure old DOS compatibility. – Totor Mar 23 '13 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.