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.
Attachment:
pgpznk1eEZBFy.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
