How to install bootloader on both disks with software RAID 1

[alankeng]

Hi,

When I used AutoYast with Software RAID 1 partition, I installed the GRUB bootloader on MBR.

Apparently, the bootloader was only installed on one of the physical hard disk. How can I set it up to install the bootloader on both of the disks, so whenever one of the disk's gone bad and doesn't matter which on it is, I am still able to boot the system.

Thanks

[Tilman Schmidt]

alankeng schrieb:
> When I used AutoYast with Software RAID 1 partition, I installed the
> GRUB bootloader on MBR.
>
> Apparently, the bootloader was only installed on one of the physical
> hard disk. How can I set it up to install the bootloader on both of the
> disks, so whenever one of the disk's gone bad and doesn't matter which
> on it is, I am still able to boot the system.

The way I did it was to physically copy the boot sector from the
first disk to the second one after the installation was done,
like so:

# dd if=/dev/sda of=/dev/sdb bs=512 count=1

(Given sda and sdb are the two physical disk drives.)
There may be a more elegant way to make GRUB do it for me,
but I was too lazy to look it up. :-)

HTH
T.

--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[carboncore]

Hi,

Alternatively, as root, get a grub command prompt and then do:

1) Find the the stage 1 file:

grub> find /boot/grub/stage1
(hd0,0)
(hd1,0)
grub>

The output could be different, depending on the partition where /boot is located.

2) Asumming your disks are /dev/sda (hd0) and /dev/sdb (hd1) and you have grub installed in the MBR of /dev/sda, do the following to install grub into /dev/sdb MBR:

> device (hd0) /dev/sdb
> root (hd0,0)
> setup (hd0)

That is telling grub to assume the drive is hd0 (the first disk in the system).
Thus, if the first fails, the second will play the role of the first one, and so the MBR will be correct.

If you think twice, the end result is the same as the one obtained adopting the way explained by Tilman Schmidt in the previous post.

Regards.

[bjbrock57]

Are we talking boot sector or MBR. One post mentions MBR the other the boot sector.

SuSE recommends not using the MBR. but the boot sector

[mingus725]

Are we talking boot sector or MBR. One post mentions MBR the other the boot sector.

SuSE recommends not using the MBR. but the boot sector

In @Tilman's post ref'g the boot sector, the dd code actually copies the MBR. In @carboncore's post, the grub setup command is installing to the MBR of sda, not sdb.

If grub and the kernel (that is, /boot) reside in a linux software RAID 1 array, grub can be installed to the MBR of either or both drives. If /boot is on a primary partition, it can be installed to the boot sector of one or both drives; in this case generic (or Windows) bootstrap code should be in the MBR rather than grub and the partition must be made active by setting the bootable flag.

Grub must be installed individually to MBR or boot sector. Neither are inside the file system, and are not a part of the array.

[ebrius313]

I've tried the following setup (because using a /boot partition didn't work for me)

I've created the following partitioning scheme on two SATA disks:

Device Size Type Mount
/dev/sda 232.8 GB SEAGATE-...
/dev/sda1 1.0 GB LINUX RAID
/dev/sda2 231.8 GB Linux RAID
/dev/sdb 232.8 GB SEAGATE...
/dev/sdb1 1.0 GB Linux RAID
/dev/sdb2 231.8 GB Linux RAID
/dev/md0 1.0 GB MD Raid swap
/dev/md1 231.8 GB MD Raid /

About similar to the OP I guess.
Furthermore, I've installed GRUB on the bootloader during install (because otherwise my system wouldn't boot).

I've tried DD'ing the bootloader from the mbr from sda to sdb as suggested with

dd if=/dev/sda of=/dev/sdb bs=512 count=1. But, when I remove the first disk and try to boot I get the message GRUB and nothing happens. Even when I place the seccond disk in the first slot (so it becomes sda instead of sdb) nothing happens, while the disks should be identical.

But the seccond method yields succes:

grub
grub > find /boot/grub/stage1
(hd0,1)
(hd1,1)
grub > device (hd0) /dev/sdb
grub > root (hd0,1) (notice I've changed the input to my situation)
Filesystem type is ext2fs, partition type 0xfd
grub > setup (hd0)

And now it works

I have to test integrity of the raid yet, but at least it boots. However, I believe it's imperative to also copy the MBR- or am I mistaken? And the dd command also overrides the partition table, which is a bit sloppy. Or doesn't that matter?

[mingus725]

Apparently in your first attempt grub was not correctly installed to the sda MBR, or possibly it was installed to the sdb MBR mistakenly. You don't indicate how you initially installed grub, and therefore whether /boot/grub/device.map determined the grub disk notation (as it does when running the shell under the root OS) as opposed to running it independently (such as from a LiveCD, where the shell must guess what (hd0) is from a bios query).

In any event, in your second attempt you used the device command to align grub's (hd0) to sdb and installed grub stage1 to its MBR.
To double-check grub is in the sdb MBR (although you won't be able to decipher its embedded pointer to the sector address of stage2), you can do:

dd if=/dev/sdb of=mbrsdb bs=512 count=1
xxd mbrsdb

That will give you a hex dump of the sdb MBR. Since you don't have a separate /boot partition and you are using a single partition RAID1 array, you should be able to copy the MBR from one disk to the other, although it is just as easy to do it with the grub shell installing to both. All stage1 in each MBR cares about is being able to find its stage2. Keep in mind that grub has to be set up as booting from a single disk (although on the kernel line in menu.lst the root= statement needs to use the array device name, i.e., /dev/md1).

Your caution re copying the MBR is well-advised, although in your simple setup with just 2 partitions on identical disks both in arrays there shouldn't be a problem because the table will be identical. For booting purposes, the loader can be copied without the table by just using the first 440 bytes instead of all 512.

As an aside, I only saw this post because I get email notifications on threads I've posted to. This thread is really old. Ordinarily you'll get much faster and better response starting your own new thread.

[mnt_schred]

Apparently in your first attempt grub was not correctly installed to the sda MBR, or possibly it was installed to the sdb MBR mistakenly. You don't indicate how you initially installed grub, and therefore whether /boot/grub/device.map determined the grub disk notation (as it does when running the shell under the root OS) as opposed to running it independently (such as from a LiveCD, where the shell must guess what (hd0) is from a bios query).

Well, I've installed GRUB on the MBR of the first disk

In any event, in your second attempt you used the device command to align grub's (hd0) to sdb and installed grub stage1 to its MBR.
To double-check grub is in the sdb MBR (although you won't be able to decipher its embedded pointer to the sector address of stage2), you can do:

Code:

dd if=/dev/sdb of=mbrsdb bs=512 count=1
xxd mbrsdb

That will give you a hex dump of the sdb MBR. Since you don't have a separate /boot partition and you are using a single partition RAID1 array, you should be able to copy the MBR from one disk to the other, although it is just as easy to do it with the grub shell installing to both. All stage1 in each MBR cares about is being able to find its stage2. Keep in mind that grub has to be set up as booting from a single disk (although on the kernel line in menu.lst the root= statement needs to use the array device name, i.e., /dev/md1).

Your caution re copying the MBR is well-advised, although in your simple setup with just 2 partitions on identical disks both in arrays there shouldn't be a problem because the table will be identical. For booting purposes, the loader can be copied without the table by just using the first 440 bytes instead of all 512.

I've tried copy�ng to a file as well; by doing this:

dd if=/dev/sda of=/home/mbr bs=512 count=1
dd of=/home/mbr of=/dev/sdb bs=443 count=1

I found this advise elsewhere, but they advised another number..

As an aside, I only saw this post because I get email notifications on threads I've posted to. This thread is really old. Ordinarily you'll get much faster and better response starting your own new thread.

Isn't bumping a thread just as effective?

[mingus725]

@ebrius313 and @mnt_schred - same user?

Well, I've installed GRUB on the MBR of the first disk

I don't get your point (no matter). My point was that, depending on where the shell is being run from, grub may see the disk alignment differently. When I need to be absolutely sure, I create a unique file on one of the partitions and then do a grub find on that rather than a file that exists on both disks.

I've tried copy�ng to a file as well

Copying to a file and then from the file to the sector is fine, it just adds an unnecessary second step.

I found this advise elsewhere, but they advised another number..

A block size of 443 is wrong. The first 440 bytes are reserved for boot code. Bytes 447-512 are the table. Bytes 441-446 are the "disk signature". Linux doesn't use this, but some versions of Windows do, and differently so. XP uses it; although AFAIK if it is missing that will not be fatal. Vista/W7 use it for disk encryption (and possibly other uses I don't know of); break it and you'll lose the OS.

Isn't bumping a thread just as effective?

Not really. Those who work these forums regularly (and are many times the best sources of assistance) need to move quickly. I often will recognize a thread I've scanned already, and so will pass it by. It can be very time consuming to read through an entire thread to get to the new problem, which often is (of course, unintentionally) not really the same as the problem for which the thread was started. And, often the reader has to reconcile the add-on post because it back-references what was posted earlier. In other words, it slows down those assisting or it may be skipped altogether. As a general rule, a fresh thread works best for both the person with the problem and those who are willing to help. The exception is when the problem is being experienced by a number of users at abt the same time and so a number of people are working the issue together.