My understanding:
In the beginning there is MBR. MBR looks for the active partition and tranfers control to the VBR of the active partition. MBR is where grub may be installed. which allows the user to choose an OS(a VBR) I am not sure what the program in the VBR does,but it manages to loads the OS.

What am I trying to do:
Backup. I ma tired of losign my partitions my bootloaders. I want to backup them all! partitions/MBR /VBR everything short of creating an disk image.


My questions:
1. say the ubuntu partition is formatted , will grub still load? if not is there a bootloader that would?am I making sense? i hope so...
2. what exactly does the VBR contain ?
2.How do I go about backing up? The mbr and the partiton table are backed up with a simple dd command. Then what else needs to be backed ? VBR's of every partition?

Hi there,

Boot process works as follows:

1. Your BIOS will look for MBR on your disk (usually on the first two disk attached to your first controller)
2. After finding boot record it will transfer the control over to boot loader.
3. Boot loader will display you the available OS that you can boot in.
4. If you have selected Linux (I am taking Window/Linux dual boot example) then linux kernel will call the first process init.
5. Init will then look in inittab as to which run-level to go in.
6. On the basis of run level it will execute the start and kill scripts.

1. When you say ubuntu partition is formatted are you trying to say you are formatting /boot if yes then grub is gone and you have to re-configure it. If you are formatting any other partition it doesn't matter your boot-loader will be there.

2. Not sure about VBR what it does :-(

3. To backup your boot-loader you can have a look at the following links:
http://www.cyberciti.biz/tips/linux-...table-mbr.html
http://www.cyberciti.biz/faq/howto-copy-mbr/

Any boot loader has to be installed somewhere, and the 446 bytes available in the MBR isn't enough to do very much. Your "understanding" of the boot process is getting off on the wrong foot right from the start, at least for the "GRUB installed in the MBR" default for most Linux distributions, so I'll begin by describing how GRUB works during booting (for GRUB version 1 -- this part of GRUB version 2 is pretty similar).

First, the BIOS loads the first sector (MBR) of the first hard disk to a fixed location in memory, checks for the "55 AA" signature in the last two bytes, and transfers control to the code at the start of the sector. If you've installed GRUB there, this will be the tiny GRUB Stage 1.

Stage 1 can't do much, so the goal is now to load GRUB Stage 2, which understands all the file systems that GRUB supports and can locate configuration files, kernels, etc., by name. One way to do this is for the GRUB installer to include in Stage 1 a list of the absolute disk block numbers where Stage 2 resides. The problem with this is that anything that physically moves the files in /boot/grub (the usual location of Stage 2) will break your boot loader. So, whenever possible a Stage 1.5 gets installed in the free space that typically follows the MBR, and Stage 1 is set up to load Stage 1.5.

There is a different Stage 1.5 for each file system (you can see them all in /boot/grub), and the GRUB installer picks the one that is appropriate for the file system that holds Stage 2. The code in Stage 1.5 finds Stage 2 by name in the file system and loads it into memory.

It's the code in Stage 2 that performs most of the functions you're familiar with -- reading and interpreting the menu file, accepting commands from the keyboard, etc.

Notice that at no time did GRUB look for the "active" flag for any partition. GRUB doesn't care about that. Now, if you've installed GRUB somewhere other than the MBR, then whatever boot code does reside in the MBR probably does try to locate the active partition.

So, your GRUB installation will be broken if you've wiped out the partition that holds the files commonly in /boot/grub, or if the MBR itself and/or the Stage 1.5 that may follow it gets overwritten. If you're in the habit of overwriting stuff on your hard disk, I suggest setting up an emergency GRUB installation on some external media, either a floppy disk or a USB flash drive. Of course that doesn't address the issue of a lost partition table.

3 members found this post helpful.

That just about covers things.
Boot-loader discussions are invariably muddied by pre-conceived notions - or web articles that purport to be general but aren't. The need for a "boot" flag is mentioned continually. This is a Windows (Microsoft and other vendors who followed it) limitation. Neither grub not lilo require or use it. Some other bootloaders used in *nix environments do - *bad* design IMHO.

There is no benefit in backing up the MBR - especially as the stage1/1.5 code now almost always extends beyond one sector. This is the case for grub1 and grub2 as well as lilo. On Ubuntu it is continually updated - making any thought of a backup pointless. Then there are gpt disks - forget it altogether.
For non-gpt, the partition table is best backed up with sfdisk IMHO - but also suffers the same problems if you happen to change partitions after backup.

2 members found this post helpful.

Hi,

This is a great read-up, it could add to what is already on the table here...

Thir

"Syslinux Boot Process

At boot, the computer loads the MBR (/usr/lib/syslinux/mbr.bin). Then the MBR looks for the partition that is marked as active (boot flag). Once found, the volume boot record (VBR) will be executed. In the case of ext2/3/4 and fat12/16/32, the starting sector of ldlinux.sys is hard-coded into the VBR. The VBR will execute (ldlinux.sys). Therefore, if the location of ldlinux.sys changes, syslinux will no longer boot. In the case of btrfs, the above method will not work since files move around resulting in the sector location of ldlinux.sys changing. Therefore, the entire Syslinux code needs to be stored outside the filesystem. The code is stored in the sectors following the VBR. Once Syslinux is fully loaded, it looks for a configuration file, either extlinux.conf or syslinux.cfg. If one is found, the configuration file is loaded. If no configuration file is found you will be given a syslinux prompt. "


https://wiki.archlinux.org/index.php/Syslinux

I just thought it interesting.