On 01/08/2011 05:51, Alex wrote:
Hi,
I have an old fedora server with a raid1 and raid5 array comprised of
four disks. One of the disks just died, and in the process of trying
to replace the disk, the server will for some reason no longer boot. I
think it was a problem with my initrd. I've since replaced the
defective disk (sdd) with a new one and created the fd partitions the
same size as they were originally.
The usual way to do this is
sfdisk -d /dev/originaldevice | sfdisk /dev/newdevice
But I usually do it as follows, to copy the rest of the boot sector and
grub stuff:
dd if=/dev/originaldevice of=/dev/newdevice bs=512 count=63
blockdev --rereadpt /dev/newdevice
(If the original partitions started at 1MB instead of the second
cylinder, it would have been count=2048 above.)
In both cases, originaldevice is a still-existing original RAID member disc.
Booting from a current rescue CDROM
and trying to use mdadm to reassmble the raid5 array, and I'm having a
problem:
% mdadm --assemble --auto=yes /dev/md1 /dev/sd[abcd]2
mdadm: no RAID superblock on /dev/sdd2
mdadm: /dev/sdd2 has no superblock - assembly aborted
That's right, you shouldn't have asked it to include sdd2 as it doesn't
yet have a RAID superblock on it.
[...]
I'm really not sure what to do next and obviously would like to do
everything possible to save the array.
How can I either have mdadm rebuild the array using the new disk or
start in degraded mode so I can rescue the data? Perhaps there's
another option?
Assemble it without sdd2 which currently has no superblock, then add the
new drive:
mdadm --stop /dev/md1
mdadm --assemble /dev/md1 --auto=yes /dev/sd[abc]2
mdadm --manage /dev/md1 --add /dev/sdd2
This will start the rebuild process and after a while (with 1TB drives,
maybe a day) and assuming the rebuild goes well, you'll be fully
operational again.
I imagine you will also want to add sdd1 to md0 in a similar manner.
Cheers,
John.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
