Hi team, I want to report a problem.
I will describe this problem as this: mdadm --add fails with "Invalid argument" when trying to add a new, healthy disk to an existing, healthy RAID5 array. This happens both via CLI and via the native GUI ("Extend" button in Storage settings), producing the same underlying mdadm error.
And I can reproduce the problem like this:
Have an existing healthy RAID5 array (/dev/md0, 4/4 disks active, [UUUU])
Insert a new, healthy disk into a free bay (confirmed via smartctl -a: SMART PASSED, 0 reallocated sectors, 0 pending sectors)
Clean the disk (wipefs -a, mdadm --zero-superblock, or low-level dd of first/last 10MB — tested all three)
Attempt to add it to the array:
sudo mdadm --manage /dev/md0 --add /dev/sde
Result:
mdadm: add new device failed for /dev/sde as 5: Invalid argument
Kernel log shows:
md: sde does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
Additional testing done:
Tested with both a raw disk and a GPT-partitioned disk (single partition) — same error
Disabled the array's internal bitmap (mdadm --grow --bitmap=none) — no effect
Full NAS reboot — no effect
mdadm --create on a standalone test array (/dev/md99) using the same disk succeeds without error — this rules out a disk/hardware problem
Kernel log also shows: md: async del_gendisk mode will be removed in future, please upgrade to mdadm-4.5+, suggesting a possible incompatibility between the current kernel and the bundled mdadm version specifically on --add/--replace operations for an existing RAID5
And here are the specs of my machine:
Model: ZimaCube (IceWhale)
ZimaOS version: v1.6.2 (build 2026/07/09)
mdadm version: v4.3 (2024-02-15)
Kernel: 6.18.9
Affected array: RAID5, 4 disks, ~3TB usable, internal bitmap, metadata 1.2
Hi team, I want to report a problem.
I will describe this problem as this: mdadm --add fails with "Invalid argument" when trying to add a new, healthy disk to an existing, healthy RAID5 array. This happens both via CLI and via the native GUI ("Extend" button in Storage settings), producing the same underlying mdadm error.
And I can reproduce the problem like this:
Have an existing healthy RAID5 array (/dev/md0, 4/4 disks active, [UUUU])
Insert a new, healthy disk into a free bay (confirmed via smartctl -a: SMART PASSED, 0 reallocated sectors, 0 pending sectors)
Clean the disk (wipefs -a, mdadm --zero-superblock, or low-level dd of first/last 10MB — tested all three)
Attempt to add it to the array:
sudo mdadm --manage /dev/md0 --add /dev/sde
Result:
mdadm: add new device failed for /dev/sde as 5: Invalid argument
Kernel log shows:
md: sde does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
Additional testing done:
Tested with both a raw disk and a GPT-partitioned disk (single partition) — same error
Disabled the array's internal bitmap (mdadm --grow --bitmap=none) — no effect
Full NAS reboot — no effect
mdadm --create on a standalone test array (/dev/md99) using the same disk succeeds without error — this rules out a disk/hardware problem
Kernel log also shows: md: async del_gendisk mode will be removed in future, please upgrade to mdadm-4.5+, suggesting a possible incompatibility between the current kernel and the bundled mdadm version specifically on --add/--replace operations for an existing RAID5
And here are the specs of my machine:
Model: ZimaCube (IceWhale)
ZimaOS version: v1.6.2 (build 2026/07/09)
mdadm version: v4.3 (2024-02-15)
Kernel: 6.18.9
Affected array: RAID5, 4 disks, ~3TB usable, internal bitmap, metadata 1.2