RAID issues: two discs using the same serial

Insight & Feedback
1

Hi there,

I need some help with a very specific issue.

I have two Seagate HDDs (same model and size) that unfortunately report the same serial number:

udevadm info --query=all --name=/dev/sdb | grep ID_SERIAL
E: ID_SERIAL=ST2000DM008-2EP102_ZK208F9A
E: ID_SERIAL_SHORT=ZK208F9A

udevadm info --query=all --name=/dev/sda | grep ID_SERIAL
E: ID_SERIAL=ST2000DM008-2EP102_ZK208F9A
E: ID_SERIAL_SHORT=ZK208F9A

After inspecting local-storage.json and local-storage.db, it seems that ZimaOS uses the disk serial as the primary identifier to map devices and assemble RAID arrays.

Because both disks share the same serial, zimaos-local-storage ends up treating them as a single device. Sometimes it detects /dev/sda, sometimes /dev/sdb, but never both consistently.

I can manually re-add the missing disk using:

mdadm --add /dev/md0 /dev/sdX

However, this change does not persist — it is lost after reboot (or possibly after a storage rescan).

As a result, I cannot reliably keep both disks in the RAID array.

I also tried creating and mounting the array manually (bypassing ZimaOS), and that works fine, but then I lose integration with the UI.

My question is:

Is there any way to configure ZimaOS (or zimaos-local-storage) to use a different identifier, such as WWN, instead of the disk serial?

Any guidance would be greatly appreciated.

1 Like
2

Thanks for your feedback, can you check the blkid command, maybe we can make a bottom decision through this sub uuid

image
image1671Ă—619 25.3 KB

3

Here it comes:

/dev/sda: UUID=“e4fe9ad1-3aa6-bf5a-7121-a2a35a38ff6f” UUID_SUB=“aacf0536-4d02-6e36-f368-ac24829e05b9” LABEL=“zimaos:340ef535df13657f” TYPE=“linux_raid_member”
/dev/sdb: UUID=“e4fe9ad1-3aa6-bf5a-7121-a2a35a38ff6f” UUID_SUB=“22bd29d7-65d4-37cc-0e6c-f10fb20e8c70” LABEL=“zimaos:340ef535df13657f” TYPE=“linux_raid_member”
/dev/nvme0n1: UUID=“28450707-7c54-47d3-8902-81275e11fd98” UUID_SUB=“408e06ec-213f-493b-ae89-f7ade3e26d77” BLOCK_SIZE=“4096” TYPE=“btrfs”
/dev/mmcblk0p7: LABEL=“casaos-overlay” UUID=“db5b5e2c-f788-4ea3-9e87-e38a675eada1” BLOCK_SIZE=“1024” TYPE=“ext4” PARTLABEL=“casaos-overlay” PARTUUID=“f1326040-5236-40eb-b683-aaa100a9afcf”
/dev/mmcblk0p5: BLOCK_SIZE=“131072” TYPE=“squashfs” PARTLABEL=“casaos-system1” PARTUUID=“a3ec664e-32ce-4665-95ea-7ae90ce9aa20”
/dev/mmcblk0p3: BLOCK_SIZE=“131072” TYPE=“squashfs” PARTLABEL=“casaos-system0” PARTUUID=“8d3d53e3-6d49-4c38-8349-aff6859e82fd”
/dev/mmcblk0p1: SEC_TYPE=“msdos” LABEL_FATBOOT=“casaos-boot” LABEL=“casaos-boot” UUID=“D449-1F65” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“casaos-boot” PARTUUID=“b3dd0952-733c-4c88-8cba-cab9b8b4377f”
/dev/mmcblk0p8: LABEL=“casaos-data” UUID=“6a69ff54-c162-470b-819c-ed826f1eefd7” BLOCK_SIZE=“4096” TYPE=“ext4” PARTLABEL=“casaos-data” PARTUUID=“a52a4597-fa3a-4851-aefd-2fbe9f849079”
/dev/mmcblk0p4: BLOCK_SIZE=“131072” TYPE=“squashfs” PARTLABEL=“casaos-kernel1” PARTUUID=“fc02a4f0-5350-406f-93a2-56cbed636b5f”
/dev/mmcblk0p2: BLOCK_SIZE=“131072” TYPE=“squashfs” PARTLABEL=“casaos-kernel0” PARTUUID=“26700fc6-b0bc-4ccf-9837-ea1a4cba3e65”
/dev/loop6: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/loop4: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/md0: UUID=“e4fe9ad1-3aa6-bf5a-7121-a2a35a38ff6f” UUID_SUB=“ec9b6c71-a865-4758-b4ac-22796240a6e8” BLOCK_SIZE=“4096” TYPE=“btrfs”
/dev/loop7: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/zram0: UUID=“c3ba033a-f86b-4832-9b7f-5757e29e7166” TYPE=“swap”
/dev/loop5: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/loop1: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/mmcblk0p6: PARTLABEL=“casaos-bootstate” PARTUUID=“33236519-7f32-4dff-8002-3390b62c309d”
/dev/loop2: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/loop0: BLOCK_SIZE=“131072” TYPE=“squashfs”
/dev/loop3: BLOCK_SIZE=“131072” TYPE=“squashfs”

4

Okay, we can see that the sub uuid is indeed different, and we will add a bottom logic in the next fix version, when encountering two disks with the same SN, we can use the sub uuid to judge

5

Nice, much appreciated!

Can’t wait for the fix!

1 Like