RAID disk failure

[Sam Varshavchik]

Jeffrey Ross writes:

>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1   *          63      787184      393561   fd  Linux raid autodetect
> /dev/sdb2          787185    16418429     7815622+  fd  Linux raid autodetect
> /dev/sdb3        16418430    24418799     4000185   fd  Linux raid autodetect
> /dev/sdb4        24418800  1953520064   964550632+   5  Extended
> /dev/sdb5        24418863    40050044     7815591   fd  Linux raid autodetect
> /dev/sdb6        40050108    55665224     7807558+  fd  Linux raid autodetect
> /dev/sdb7        55665288  1953520064   948927388+  fd  Linux raid autodetect
>
> Bingo, mine start at 63, probably a hold over from previous installs.
>
> ok, sdb1 is /boot, and I'm currently using 81 meg out of 372 meg and if I'm  
> doing my math right I should be able to easily shrink /boot by another 1985  
> blocks (roughly 1MB) or so.
>
> Based upon what you've given me, I suspect I can simply fail /dev/md1 (sda1  
> sdb1) resize it on the sda1 disk, copy everything across via cpio, install  
> the new bootloader on /dev/sda, once it comes up I can then resize /dev/sdb1  
> re-add the partition to RAID and run the grub2-install command.

The problem here is that the kernel will NOT reread an updated partition  
table, if anything is still using any partition. This includes your active  
md arrays that are already on sda.

You will have to fail and remove all your arrays from sda, before you can  
screw around with its partition table. fdisk will let you do it, and write  
the updated partition table, but the kernel will refuse to reread the  
partition table, and use it, if any partition is active on that disk.

Furthermore, I would not chance a reboot with different versions of /boot on  
two disks.

If I'm on a UPS and don't have to worry about power, I would do the  
following (since I've already done this two times already, for similar  
reasons):

Make a back up of /boot, in case something happens.

Unmount /boot, fsck it, and use resize2fs to shrink it down to about 30%  
less than its projected smaller size (so as to not to waste any time on all  
the mega/mibi drivel). Then, use mdadm --grow to reduce the size of the  
/boot md unit to about 15% less than the projected smaller size of the new  
/boot. This needs to be done now, while the md array is still synced. mdadm  
--grow won't work if the array is degraded.

Double check that md says that everything is still fully synced, maybe mount  
/boot and verify that it still looks kosher.

Fail all partitions on sda, to release all the kernel locks on the partition  
table. Delete and recreate a smaller sda1.

Run mdadm --zero-superblock on all sda partitions, then add them back to  
their original arrays, and let the kernel fully resync everything. --zero- 
superblock will ensure that everything is fully sync. mdadm will accept the  
smaller sda1 back into its original array, because it's still larger than  
the reduced logical size of the array.

At this point, when I went through this, I repeated the the whole thing,  
this time failing everything on sdb, because I wanted to have sdb's  
partition table match sda's. But that's not strictly necessary. But it's a  
good idea, since you will also be able to install grub on sdb, if needed,  
and swap it in for sda, and boot off it.

Finally, unmount /boot, if it's still mounted, run mdadm --grow to let mdadm  
grow the logical array back up to the maximum size of the smallest partition  
in the array, then use resize2fs to bring the size of the /boot filesystem  
back up to the size of the logical array it lives on.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20111218/f8c612a0/attachment-0001.sig>