I just think this might work

I am using scsi drives so would I use root (sd0) I tried it but it said error while parsing number

I tried root (hd0) and it said filesystem type unknown, using whole disk

I stopped at that point worried I might mess up the whole thing

I have read other links that talk about doing it this way

$ grub

grub> device (hd0) /dev/hdc grub> root (hd0,0) Filesystem type is ext2fs, partition type 0xfd grub> setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded. succeeded Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded Done.

do I need the device line first?

Thanks

Peter Farrow wrote:

You can replace the boot loader as follows:

1)Boot in REscue mode, and get a command prompt 2)Run grub, if your two disks are for example /dev/hda and /dev/hdb and the boot partition is the first on each: grub> root (hd0) .... grub> setup (hd0,0) ... grub>root (hd1) ... grub>setup (hd1,0) ... grub>exit

This will put a stage1 boot loader on each disk, you should be able to boot the originally non-bootable disk now. Make sure you boot in the bios from the second disk, (which I presume is the one you want to keep), to make sure you could disconnect the original drive first and boot the system to try it.

You might find this article useful.

If the first disk has now been fixed but contains no data, you can export the partition table from the second disk using sfdisk, and re-import it on the first hard disk using sfdisk again, you can then use mdadm to hot add the first (replaced) disk to the second (running and now bootable) disk.

Regards

Pete

Mace Eliason wrote:

...

Trying a different approch.

Senario

Raid 1 setup Bootable raid drive failed Mirror has been working for almost a month and then rebooted Now can't boot mirror drive grub not mirrored from other drive.

I Fixed bootable drive. Question?

Can I hook up both drives and boot fixed drive then rebuilt mirror from nonbootable drive to bootable drive?

Does the raid automatically rebuilt when I boot with both drives? Can I run a command to rebuilt from one drive to the other and visa versa

I want to try it but I am worried that if I hook them up and it boots that because the bootable drive has older info it might over write the other drive. Thanks

Can't seem to figure out how to get the other drive bootable. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Sorry I missed out the link in my original response,

...

you might find this article useful:

http://beau.org/pipermail/whitebox-users/2006-April/007467.html

P.

Mace Eliason wrote:

I just think this might work

I am using scsi drives so would I use root (sd0) I tried it but it said error while parsing number

I tried root (hd0) and it said filesystem type unknown, using whole disk

I stopped at that point worried I might mess up the whole thing

I have read other links that talk about doing it this way

$ grub

grub> device (hd0) /dev/hdc grub> root (hd0,0) Filesystem type is ext2fs, partition type 0xfd grub> setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded. succeeded Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded Done.

do I need the device line first?

Thanks

Peter Farrow wrote:

...

You can replace the boot loader as follows:

1)Boot in REscue mode, and get a command prompt 2)Run grub, if your two disks are for example /dev/hda and /dev/hdb and the boot partition is the first on each: grub> root (hd0) .... grub> setup (hd0,0) ... grub>root (hd1) ... grub>setup (hd1,0) ... grub>exit

This will put a stage1 boot loader on each disk, you should be able to boot the originally non-bootable disk now. Make sure you boot in the bios from the second disk, (which I presume is the one you want to keep), to make sure you could disconnect the original drive first and boot the system to try it.

You might find this article useful.

If the first disk has now been fixed but contains no data, you can export the partition table from the second disk using sfdisk, and re-import it on the first hard disk using sfdisk again, you can then use mdadm to hot add the first (replaced) disk to the second (running and now bootable) disk.

Regards

Pete

Mace Eliason wrote:

...

Trying a different approch.

Senario

Raid 1 setup Bootable raid drive failed Mirror has been working for almost a month and then rebooted Now can't boot mirror drive grub not mirrored from other drive.

I Fixed bootable drive. Question?

Can I hook up both drives and boot fixed drive then rebuilt mirror from nonbootable drive to bootable drive?

Does the raid automatically rebuilt when I boot with both drives? Can I run a command to rebuilt from one drive to the other and visa versa

I want to try it but I am worried that if I hook them up and it boots that because the bootable drive has older info it might over write the other drive. Thanks

Can't seem to figure out how to get the other drive bootable. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Mace Eliason spake the following on 5/1/2006 4:32 PM:

Can anyone answer this question:

What happens if one drive is out of sync with the other. One drive has 1 month newer files on it, but its not the boot drive.

If I let Centos boot from the older version will it automatically rebuilt the raid 1 to the second drive????? (bad for me)

Or do you have to manually do it??

With raid1 arrays, you don't actually boot from a partition, you boot from the raid array such as /dev/md0. The raid code should know if the array is out of sync and will leave the bad drive out of the array. Your array will be in degraded mode, but should boot. Then you can add the other partitions back to the array and they will re-sync. You just have to be careful that you add the proper partitions back to the proper arrays.

ITS ALIVE!!! Almost any way.

I finally booted the drives after backing up the drive with the current info. It has booted into Centos and to my supprize it is using the drive with the most recent info.

But it is not using raid as far as I can tell. If I load logical volume management it shows

Uninitialized Entities /dev/sda partition 1 partition 2 partition 3

/dev/sdb partition 1 partition 2 partition 3

I tried mounting sda3 and check and found it is the older info the (drive to be replaced)

So from what you stated below I would run:

sfdisk -d /dev/sdb | sfdisk /dev/sda

Is this correct because sdb has the most current info and sda is the old info.

Then I would run mdadm

Thanks

Scott Silva wrote:

Hi

Thanks for your help, I am sure your busy doing other things as well.

As I stated in previous postings I have changed the scsi ids and now with the two drives attached it will boot from the old drive (I am assuming it is the old drive because the other drive would'nt boot on its own.

If I do boot to centos now will it rebuild the mirror from the booting drive to the other drive?

I am worried about haveing the current info over written by the old info.

At this point I will settle for just getting the one drive that has the current info booting and working.

Thanks for any help

If the system is running, and you know which drive is which, you can repair very easily now. If everything is running from /dev/sda and the bad drive is /dev/sdb you can do the following (make sure which drive is which before continuing);

sfdisk -d /dev/sda | sfdisk /dev/sdb >-- make sure on the drives .. good drive first, bad drive second. Then you can add the partitions back to their arrys with mdadm.

Personalities : [raid1] md1 : active raid1 sdb2[0] 2048192 blocks [2/1] [U_] md2: active raid1 sdb3[0] 15623104 blocks [2/1] [U_] md0: active raid1 sda1[1] 104320 blocks [2/1] [_U]

Les Mikesell wrote:

On Mon, 2006-05-01 at 22:48, Mace Eliason wrote:

...

ITS ALIVE!!! Almost any way.

I finally booted the drives after backing up the drive with the current info. It has booted into Centos and to my supprize it is using the drive with the most recent info.

But it is not using raid as far as I can tell. If I load logical volume management it shows

RAID and LVM are different things. What do you see if you 'cat /proc/mdstat'?

I think the reason for the partitions not being on the same drive is because the old drive is the bootable drive and I changed the scsi ids of the drives to get it to work. I think it is using sba for the boot but centos is on sbb.

I just need to make sure that the sync happens so that the info on sbb is what is synced. The info on sba is 1 month old this I have confirmed by mounting sba3 and looking at the dates of the last emails received on the server I couldn't mount sdb3 because it is the active partition.

So from what your saying below running mdadm as you have shown will it copy the good info on sdb to sda?

I have to have this server ready for 7am or we will loose this contract. I can't believe I have spend all day on this.

Thanks for the help

If I copy over the wrong info they will lose 1 months worth of emails.

Mace

Les Mikesell wrote:

On Mon, 2006-05-01 at 23:18, Mace Eliason wrote:

...

Personalities : [raid1] md1 : active raid1 sdb2[0] 2048192 blocks [2/1] [U_] md2: active raid1 sdb3[0] 15623104 blocks [2/1] [U_] md0: active raid1 sda1[1] 104320 blocks [2/1] [_U]

That tells you that your raid devices were built with 2 partitions and now only have one active. It shows which member is active - note that they aren't all on the same drive. Assuming you have matching partitions on the other drive (do an 'fdisk -l' to make sure) and are sure the correct version is running now:

mdadm --add /dev/md0 /dev/sdb1 mdadm --add /dev/md1 /dev/sda2 mdadm --add /dev/md2 /dev/sda3

'cat /proc/mdstat' will show the re-sync progress. Don't reboot until the resync is complete and you see [UU] on all devices. When they have all completed, if you reboot cleanly the md devices will come up with both partitions active (but you don't have to reboot unless you want to test it).

Les Mikesell spake the following on 5/1/2006 9:32 PM:

On Tue, 2006-05-02 at 00:13, Mace Eliason wrote:

...

I think the reason for the partitions not being on the same drive is because the old drive is the bootable drive and I changed the scsi ids of the drives to get it to work. I think it is using sba for the boot but centos is on sbb.

It doesn't really boot from raid. It loads the kernel from the underlying partition on the boot drive, then the kernel detects the raid devices and decides how to activate them, then it mounts them according to /etc/fstab. You should be able to review the detection process with 'dmesg |less' if you are interested.

...

I just need to make sure that the sync happens so that the info on sbb is what is synced. The info on sba is 1 month old this I have confirmed by mounting sba3 and looking at the dates of the last emails received on the server I couldn't mount sdb3 because it is the active partition.

Be careful with your spelling... I assume you mean /dev/sda3 is the old one.

...

So from what your saying below running mdadm as you have shown will it copy the good info on sdb to sda?

Again, be careful. It will copy the currently active partition to the one you are adding - so if you see the current version now, that's what will be mirrored. In the case of /dev/sdb3 it will go from sdb to sda. But /dev/sda1 is active now and will be copied to /dev/sdb1.

...

I have to have this server ready for 7am or we will loose this contract. I can't believe I have spend all day on this.

This is the sort of thing you should practice on a test box so you are prepared to handle an actual problem in a reasonable amount of time.

...

If I copy over the wrong info they will lose 1 months worth of emails.

You can only copy from the active one to the one you add. And by the way, having backups can be a good thing too...

You might want to download the free Vmware server software and play with senarios like this. You can create installs with 2 drives in raid 1, and kill a drive and play with rebuilding. All virtual, so no damage to working systems. This is how I learned some of the nuances of linux software raid.

On Wed, 2006-05-03 at 11:13, albi wrote:

...

You might want to download the free Vmware server software and play with senarios like this. You can create installs with 2 drives in raid 1, and kill a drive and play with rebuilding. All virtual, so no damage to working systems. This is how I learned some of the nuances of linux software raid.

very interesting idea,

but.. vmware-server is free-of-charge ?!

qemu is open-source and free-of-charge and suits my emu-needs! :)

Yes, Vmware-server is free of charge. It is currently a beta version but is usable and will remain free after release: http://www.vmware.com/products/server/ There is also a free vmplayer product that is in a released version that you could use to run the machines after creating them with the server version (vmplayer won't create new virtual machines). The player is intended for more workstation-like use where you only run one guest per player instance and it also handles the display. The server version can run multiple guests at once and doesn't require any local display but instead has a separate console that can run remotely and the guest continues whether any consoles are connected or not.

I'd be interested in a comparison by a currently-satisfied qemu user. One advantage of vmware is that you can run the server/player under either either windows or linux and the virtual machines are portable between them. Likewise for the console/server connection - you can run the display console on a windows box connecting to a server host on Linux or the reverse.

VMware is still selling the Workstation and ESX versions of their software which offer some additional bells and whistles (and performance in the ESX case).

On Wed, 2006-05-03 at 12:53, Mace Eliason wrote:

#sfdisk /dev/sda < /raidinfo/partitions.sda (make sure you get the drives right)

This partitions the new drive with the exact same partition table that was there before and makes all the rebuild and raid partitions all in the exact same place so that you don't have to edit any raid configuration files at all. "

I found this info here:

http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/008898.html

That really made creating things easier.

You are really making the partition setup sound harder than it is. It is not difficult to look at an existing disk with 'fdisk -l' and create 3 matching partitions on another disk with the interactive mode of fdisk. All you have to do is specify the start and end cylinders for each partition and set the type to FD. Not that there is anything wrong with using sfdisk but sometimes it is nice to see what you are doing.

On Tue, 2006-05-02 at 00:21, Mace Eliason wrote:

Also I ran fdisk -l and this is what I got

/dev/sda1 /dev/sda2 /dev/sda3

/dev/sdb1 /dev/sdb2 /dev/sdb3

disk /dev/md0: 106meg /dev/md0 doesn't contain a valid partion table

disk /dev/md2: 15.9gig /dev/md2 doesn't contain a valid partion table

disk /dev/md1: 2097meg /dev/md1 doesn't contain a valid partion table

Does that help at all?

I expected it to show the sizes of the sda/sdb partitions but that was just a sanity check to make sure that the corresponding partitions match. It's a fairly safe assumption that they do.

On Tue, 2006-05-02 at 00:49, Mace Eliason wrote:

I have a replacement drive that I want to sync after this is finished to remove the drive that had the problem to begin with. In this case sda

I would assume that I would create the raid partitions on the new drive and then sync again something similar to what I have just done.

Yes, just create partitions with matching sizes and type FD. However you'll still have to deal with making it boot from your 2nd drive which I don't think you quite managed before. My best guess is that the bios on your scsi card is only configured to boot the device with drive select 0.

Another approach is to clone the whole sda drive: Remove sdb and replace with the drive that will become sda. Set drive select appropriately if the drives have jumpers (this is easier with hot-swap SCA types where the drive position takes care of the select automatically). Boot in rescue mode, skipping network and mounting the old system. From the command prompt: dd if=/dev/sda of=/dev/sdb bs=1M Go do something else for an hour or more... This will do a complete copy of the whole disk including the boot loader and partition layout. When it is finished swap the 2nd drive into the first position and reinstall your original 2nd drive. Everything should be the same software-wise.