Mailinglist Archive: opensuse (2700 mails)

< Previous Next >
Re: [SLE] Moving Grub from MBR
  • From: Darryl Gregorash <raven@xxxxxxxxxxxxx>
  • Date: Fri, 01 Jul 2005 17:53:05 -0600
  • Message-id: <42C5D761.8020307@xxxxxxxxxxxxx>


James Wright wrote:

I am installing FREE CompuSec (Posted in Suse Security: New Security Offering for Linux). It has a log-on with password before the loading of any OS. Unfortunately it has a known limitation when the boot loader (Grub), is stored in the MBR. This is because CompuSec places it's password program there. Apparently my machine will fail to boot if I finish the installation, unless I move Grub to the boot sector. Here is what the usage document says:

If a boot manager is installed in the MBR, please take care of the
following: The CompuSec loader is using some sectors behind the MBR of
the hard disk. These are the sectors up to number 7. If a boot manager
inside MBR also is using one of these sectors behind the first sector
(e.g. GRUB with Stage 1.5), then the boot process will fail after
installation of the CompuSec loader.
In that cases it's recommended to install the boot manager in the
boot sector of a partition instead of the MBR.


As an **absolute** minimum, do be sure to back up the MBR and the boot sector of the boot partition, before you try anything. You can use the dd command to do this, use a blocksize of 512, and I would suggest backing up the entire boot tracks (63 sectors) just in case:

dd if=/dev/hda of=<path>/MBR bs=512 count=63
and
dd if=/dev/hda1 of=<path>/boottrack bs=512 count=63

BTW, the following commands are equivalent to these:

dd if=/dev/hda of=<path>/MBR bs=63b
and
dd if=/dev/hda1 of=<path>/boottrack bs=63b

For added security, you probably want to put the files onto a floppy. Preferably, you should just back up everything on all your hard drives (including all boot sectors and partition information), but this may not be practical -- even if you have a DVD/R9 (dual layer writer, that is) , a 100 GB drive is still going to need a lot of DVDs!

Now you have to get grub into the hda1 boot sector. YAST can do this for you, I think -- just specify /dev/hda1 as the boot loader location. Without YAST to help, you'd have to use the grub mini-command line but I won't confuse you with the details, unless YAST balks at moving grub (it better not, or else your actual installation won't match the sysconfig file record).

Now you have to make sure there is something in the MBR (presumably that CompuSec loader can do this) that will chainload the hda1 bootsector.

As for XP, I do not know if grub will be able to pass control to its loader from that location, I would think that it should, particularly if your grub menu.lst does NOT use the "map" command. XP can boot from a second physical hard drive (Win 9X won't, of course), so drive remapping should not be an issue.

The only time I can think of that you would need to use the "map" command in menu.lst is if you installed XP onto the master drive, then made that drive the slave and installed SuSE onto the (new) master. If this is the case, then all bets are off -- maybe it will work, maybe not. If it does not, then you must be able to include XP's bootloader location in the CompuSec loader also, AND you must be able to specify that the drive ordering must be inverted in the BIOS: hd0 (the master drive) must be referred to as hd1, and vice versa, or whatever syntax CompuSec uses. I hope this point doesn't confuse you, check menu.lst and if you don't see the word "map" anywhere in it, this particular paragraph does not apply.

Again, remember to back up those boot records before you do anything, and DO make sure you have the rescue system beside you before you start, just in case. If it gets all fouled up and you have to restore the boot records, fire up the rescue system, mount wherever you stored the two records, then basically just invert the previous commands:

dd if=<path>/MBR of=/dev/hda bs=63b
and
dd if=<path>/boottrack of=/dev/hda1 bs=63b.


If it is a painful move, I will try it at home sometime first.


I definitely do think that would be a good idea, so you can see for yourself exactly what is going on -- then you'd be able to try everything, including recovery.


< Previous Next >
References