On Fri, 24 Dec 2021 15:38:05 +0100 cen wrote: I've always noticed that about raid in general. Thousands of internet pages telling you how redundant arrays protect you from disk failures and you ought to use them. Nothing at all saying what you do when one of those disks fail :-). Though I have heard the claim that all you have to do is swap in a new blank disk and power up the system and magic happens.

On 24 Dec 2021 at 12:11, George N. White III wrote: From: "George N. White III" <gnwiii(a)gmail.com&gt; Date sent: Fri, 24 Dec 2021 12:11:03 -0400 Subject: Re: The definitive guide to replacing a disk in raid1? To: Community support for Fedora users <users(a)lists.fedoraproject.org&gt; Send reply to: Community support for Fedora users <users(a)lists.fedoraproject.org&gt; Remember way way back. Had a Novell 4.x server that had a duplex raid (mirror) system with 2 1G System disk and 4 - 9G (At time largest disk). Had two SCSI controllers with one of each drives in mirror to allow for disk or controller failures. Was a cool setup, but in pre-testing found an issue. The Primary System disk had a small DOS boot partition that was not mirrored to the other System disk. So if your primary system disk would fail the computer would continue to run off the secondary, but if you rebooted it would fail. Was an easy process to manually copy the partition to the other disk, and then one could swap positions. Otherwise it was great. Ran 10 computer labs off a Novell 4.x server with 350Mhz AMDK6-2 with 6 SCSI disks with 192M of Ram.. Never had a drive fail over many years. Did have our Admin have a System that was running SCO and it had a failure in a 3 disk system. It kept working fine after failure, but when they replace the bad drive the rebuild that was suppose to be automatic failed. Some how it mixed up which drive to rebuild and corrupted the whole raid. (Could have been operator error, but that is what they said happened?). Fortunately they did have a back right before they did the replacement, so just a couple days of down time. But know many never test that the system works or how to do the restores, and just hope it works. I like to also do bare metal backups just to be sure. Running one right now on my only windows 10 machines to one of my 5 Fedora machines. Best of luck to everyone. Unfortuantely, drives fail, and often don't give warnings. But prices are less expensive. Recall the 9G SCSI drives where like $450 each. My first computer had an option for a 20M Seagate ST-225, but it was a $2,000 option in 1983, so got my Heathkit H-120 Dual CPU system 8088/8080 with dual 320K floppies and 768K of Ram (more ram than IBM PC). Loved that machine 8Mhz CPU. Merry Christmas to those that celebrate it, and Best Wishes to others.

On Fri, Dec 24, 2021, at 6:38 AM, cen wrote: Looking at my notes, I can add some of my notes. These may or may not apply to you... (Should not be needed since you are not changing the UUID of the Raid) Add any missing raid UUIDs to /etc/default/grub, there should be a "rd.md.uuid=UUID" for each one of your RAID (not partition) UUIDs. Rerun grub2-mkconfig to update your grub.cfg. (Should not be needed since you are not changing the UUID of the Raid) Remember to check /etc/mdadm.conf, just in case. The above is mostly a reminder to review all raid related stuff after any such change. If you happen to use a mix of ssd and rotating rust then remember this bit: Enable it if you add an SSD for sda: echo writemostly > /sys/block/md1/md/dev-sdb1/state echo writemostly > /sys/block/md1/md/dev-sdc1/state Make 100% sure that then new disk has at least as many sectors (I think it is the sectors) as the old drive. If not then something needs to be shrunk down a bit to allow that `sfdisk` copy to work properly. That is why it is best to leave some unused space when first building these. Not 100% sure that the "grow" is correct there since you are not changing the size but it will let you know one way or the other. My notes have "mdadm --manage /dev/md127 --add /dev/sdd1"

On 12/24/21 06:38, cen wrote: Assuming the new disk hasn't been used, that step is probably unnecessary. That looks wrong, it should probably be 'grub2-install /dev/sdd'.  Additionally, it should be performed *after* adding the replacement disk to the RAID set, not before. (Note that this step is not required and should not be performed on UEFI systems, only BIOS.)

On 12/24/21 14:29, Cameron Simpson wrote: Right, the boot block *is* in a non-RAID area (the MBR) for the standard config, which is partitions in RAID sets.  But grub2 still has to map the Linux device names to BIOS devices for use during boot, and the way that I remember it (I haven't managed an mdraid system on BIOS in a *long* time), the device needed to be a member when grub2-install was run in order for the resulting grub2 image to have a complete view of the places it might find its configuration files, etc. If I'm wrong, or if things have changed since I last set up a BIOS system with mdraid and GRUB2, I hope someone corrects me.  :) On UEFI systems, the firmware doesn't load a bootloader out of a boot block, it has a path to the boot loader in a FAT filesystem. Rather than putting a bootloader in a static location where the BIOS will look (as grub2-install does on BIOS), UEFI systems are given a location where they should look using efibootmgr. But beyond grub2-install being unnecessary on UEFI, the standard effect of running it on a UEFI system is to rebuild the grub2 EFI image, and that will break Secure Boot systems because your efi image is no longer signed.  Looking at bz#1917213, it seems like grub2-install will (as of some very recent version) refuse to run in order to not break the image.

On 25. 12. 21 01:16, Sam Varshavchik wrote: By geometry you mean block size or something more? Thanks, precisely the thing I was afraid of doing wrong.

On 26. 12. 21 04:20, Sam Varshavchik wrote: I did this from 300GB (single partition) disk to a 1TB disk (same block size) and it created a 300GB partition with start/end blocks and all flags identical. I might need to take a closer look but it seems to be fine.