I am dual-booting openSUSE 11.1 with Windows XP Professional, using 2 HD’s - one for each OS, as below.
HD 1 - Windows XP (IDE HD)
HD 2 - openSUSE 11.1 (SATA HD)
GRUB is used as the bootloader and is located on MBR (HD 1). I can properly boot into oS 11.1 and Windows XP.
Now, I would like to make a backup of the MBR (& GRUB, if necessary), so that I can restore it if there is a problem.
How do I make an MBR Backup and also, how does one restore it, if there is a problem later ?
Since I don’t know what you do/do not know about this, I’ll throw in the kitchen sink here . . .
If YaST Boot Loader replaces the MBR code with grub, it creates a backup copy of the entire MBR. There is a recovery option under the Other button in the module. Bear in mind that this is the entire MBR, which includes the partition table - if the entire MBR is restored and since it was backed up there have been changes to the table, some if not all of the partitions may be lost.
Personally, I keep a copy separate - the absolute safest is to put the copy on another hard disk or on removable media. Keeping the copy on the MBR’s own disk or in a partition on that disk assumes you can get at it when you need to, and in some situations that will not be possible.
Also, understand that the MBR consists of 3 primary parts: The bootstrap code in bytes 1-440, the disk signature in 441-446, and the partition table in 447-512. The disk signature can be significant to Vista, so it should never be disturbed on a Vista machine; it is also used by XP although IME XP’s use of it is not critical. I always advise backing up the entire MBR; what is critical is to understand what/how to restore which part depending on the situation.
Finally, remember that every hard disk has an MBR. In multi-boot setups where the bios config or a bios boot menu is used to switch between boot disks, all MBR’s are relevant. It is also possible for recovered MBR boot code to fail if the location of the boot loader program it points to, has changed.
To create a backup of the MBR on disk sda, in a terminal as root do:
dd if=/dev/sda of=mbrsda bs=512 count=1
You now have a file named mbrsda which is a copy of the MBR sector. To recover the entire MBR do:
dd if=mbrsda of=/dev/sda bs=512 count=1
To recover just the boot code part of the MBR, do:
dd if=mbrsda of=/dev/sda bs=440 count=1
Of course, if it is grub that you are trying to recover, it can be reinstalled from nearly any Linux liveCD. And in some cases, that is preferable or even necessary rather than using recovery.
Mingus, thanks for the detailed reply. I read on another forum, that one can view the contents of the backup using the ‘file’ command, is there any benefit in doing so? Also, is it necessary to save the MBR as an ‘.img’ file ?
Of course, if it is grub that you are trying to recover, it can be reinstalled from nearly any Linux liveCD. And in some cases, that is preferable or even necessary rather than using recovery.
How can this be done from a Live CD (I generally use the PartedMagic Live CD)? If I opt for reinstalling with a Live CD, will it preserve the grub configuration/menu (oS 11.1 and Win XP from their respective partitions) or will I need to manually edit menu.lst & grub.conf files ?
I’m not aware of a method of examining the contents with the file command. I use xxd (e.g., “xxd mbrsda” after dd has copied the sector). Viewing the contents in raw hex is of limited use. The boot code itself is of course a binary; which loader code it is (grub, Windows version) is identifiable but embedded values such as grub’s embedded pointer to find its stage2 is difficult to extract (and probably pointless, unless you’re debugging grub, and that is really pointless). Reading the disk signature is useless; MS uses it for proprietary purposes and AFAIK that is not documented. The partition table can be read, but some of the fields are packed and you have to know how LBA works to translate the data; it’s much easier (and wiser) to use a disk editor. And needless to say, one must understand the mechanics of operation of the loader code and the data, within the system. For example, some loaders put supplementary code in the free sectors following the MBR; grub puts a file system driver (the stage1.5 file) there so it can read file systems without help from an OS (which is why in some cases restoring the MBR is not sufficient; a reinstall is required). All of this is only for the technically experienced.
An .img file is simply an image, in this case, the image is of the sector. Since Windows apps typically use file extensions, a particular extension may be required to perform a function. IIRC e.g., Nero wants an .img or .bin file, along with the explicit offset to use, to burn a boot sector to a CD/DVD. Linux on the other hand doesn’t care about file extensions. The “dd” command simply copies bytes; you tell it how many and the from/to location.
Reinstalling grub from any LiveCD (of course, grub has to be on the CD) is simple most of the time, as long as you understand the basics of operation. The grub shell can see block devices (/dev/sda, dev/sdb3, etc.) and it can read all file systems except NTFS. So there is no need to mount a root file system - but, and this is critical - if the shell is run from within an OS, it will use its device.map file for determining the boot disk configuration; it assumes the user has set up device.map correctly in alignment with the bios config. But if the grub shell is run independently of that OS - such as within a linux ramdisk, which is what a liveCD is - it will query the bios for the disks and use an educated guess for the boot disk sequence because it does not have device.map to rely upon (the bios does not pass this data). To mitigate the guess work, there is the “device” command where the user interactively gives the shell what is otherwise in device.map, and the “find” command which can locate in grub disk/partition notation where the loader and kernel are resident on the disk. Once this is known, all that is required is to tell grub where to put stage1 (the bootstrap) and where to find its stage2 (the loader). Example: You have 2 disks (sda and sdb), you are booting from the second disk, and stage2 in on sdb6. So in a LiveCD you would run grub in a terminal as root and do:
find /boot/grub/stage2
Grub should return (hd0,5), but it may not have successfully guessed that the second disk is the boot disk rather than the first, so it may return (hd1,5) instead. So you do:
device (hd0) /dev/sdb
Which tells grub that sdb is the first boot disk. Now your find command will return (hd0,5). You want to install grub to the MBR, with its pointer looking at sdb6. So:
root (hd0,5)
setup (hd0) (hd0,5)
quit
Will do that. The device.map and menu.lst files remain untouched, and only need to be changed if for some reason the disk layout or boot config has been changed. Such changes can be done in the LiveCD with a text editor as root after mounting the boot partition. Or the user at reboot can simply escape out of the grub menu and edit the lines interactively there, boot the system, and make the necessary corrections after back in the OS. In fact, once the menu is loaded the grub shell is accessible, allowing the user to completely bypass menu.lst, interactively entering all the necessary commands to boot the system (including Windows).
The above is a simple common example, and so doesn’t touch on the different config scenarios possible, nor grub’s extensive capabilities. For sure, how booting works is certainly one of the most misunderstood, and most commonly misinformed and miscommunicated, of all functions.
You’ll see the tin cup on your way out the door. 
mingus725, Thank you, Great explanation ! (Should be bookmarked)
Hi, not a direct answer to your question - no need now mingus725 has provided a very detailed answer, but I use SuperGrubDisk to fix things when they are broken, an example would be a re-installed Windows XP overwrote my MBR (Microsoft doesn´t want us to dual boot), booting from SuperGrubDisk got me back into OpenSuse and fixed my MBR.
Here´s the link if you are interested.
Cheers
Hi, not a direct answer to your question - no need now mingus725 has provided a very detailed answer, but I use SuperGrubDisk to fix things when they are broken, an example would be a re-installed Windows XP overwrote my MBR (Microsoft doesn´t want us to dual boot), booting from SuperGrubDisk got me back into OpenSuse and fixed my MBR.
Here´s the link if you are interested.
Cheers
Came across a good article on Linux booting and GRUB- How to fix Linux boot problems | TuxRadar