On 05/12/2018 05:37, Nicolas Kovacs wrote: > Le 04/12/2018 à 23:50, Stephen John Smoogen a écrit : >> In the rescue mode, recreate the partition table which was on the sdb >> by copying over what is on sda >> >> >> sfdisk –d /dev/sda | sfdisk /dev/sdb >> >> This will give the kernel enough to know it has things to do on >> rebuilding parts. > > Once I made sure I retrieved all my data, I followed your suggestion, > and it looks like I'm making big progress. The system booted again, > though it feels a bit sluggish. Here's the current state of things. > > [root at alphamule:~] # cat /proc/mdstat > Personalities : [raid1] > md125 : active raid1 sdb2[1] sda2[0] > 512960 blocks super 1.0 [2/2] [UU] > bitmap: 0/1 pages [0KB], 65536KB chunk > > md126 : inactive sda1[0](S) > 16777216 blocks super 1.2 > > md127 : active raid1 sda3[0] > 959323136 blocks super 1.2 [2/1] [U_] > bitmap: 8/8 pages [32KB], 65536KB chunk > > unused devices: <none> > > Now how can I make my RAID array whole again? For the record, /dev/sda > is intact, and /dev/sdb is the faulty disk. How can I force > synchronization with /dev/sda? > > Cheers, > > Niki > If you are confident in the state of sda, I would remove sdb from the array, copy the partition table from sda to sdb as Stephen suggested earlier, then add sdb back to the array and allow the data to be synced: For example: mdadm --fail /dev/md125 /dev/sdb2 mdadm --remove /dev/md125 /dev/sdb2 mdadm --fail /dev/md126 /dev/sdb1 mdadm --remove /dev/md126 /dev/sdb1 mdadm --fail /dev/md127 /dev/sdb3 mdadm --remove /dev/md127 /dev/sdb3 sfdisk –d /dev/sda | sfdisk /dev/sdb then add them back and watch then rebuild: mdadm --add /dev/md125 /dev/sdb2 mdadm --add /dev/md126 /dev/sdb1 mdadm --add /dev/md127 /dev/sdb3 After they have all resynced, I would flush the device buffers for good measure. For example: blockdev --flushbufs /dev/sdb1 ... Lastly, don't forget to reinstall grub to sdb: grub2-install --recheck /dev/sdb