On Tue, Apr 30, 2019 at 01:31:07PM +0200, Julien ROBIN wrote: > The stackexchange statement is "the problem is that you don't know" Yes, because it's not always that straightforward and the array you're trying to re-create might already be many years old. So this is a reminder to double- and triple-check everything (and even then use overlays... they're so useful there should be an easier command to set them up.) > For beginning with investigations, the only thing I did, this time, that was > different from others time, was to use "dd if=/dev/urandom of=/dev/sdc > bs=1024k status=progress" before preparing the disk, just to be sure its > complete surface is working. Do you think this can be the cause of mdadm > error? Should the new disk be always full of zeroes before preparing > partition, then add and grow ? Nah, as long as dd (and everyone else) was done with the drive by the time you passed it to mdadm, it's just fine. Something else must have happened... either a bug (are you using latest mdadm / kernel versions?), or trying to store the backup file on the raid itself, or maybe something blocking mdadm (happened before with selinux/apparmor, I think) or otherwise something interfering with the process. If you can reproduce the issue you could investigate in more detail... Regards Andreas Klauer
