Cannot assemble Intel IMSM RAID1 anymore starting with mdadm 4.5

[JosuaRieder]

I'm on Arch with kernel x86_64 Linux 7.0.5-arch1-1, booted in UEFI. I've been using Intel IMSM RAID1 for close to a decade now without any issues but after an update approximately two months ago the disks showed up separately. Downgrading to 4.4.2 has fixed the issue again.

Below is some 4.6 output:

~$ sudo mdadm --examine /dev/sde /dev/sde1 /dev/sde2 /dev/sdg /dev/sdg1 /dev/sdg2
/dev/sde:
          Magic : Intel Raid ISM Cfg Sig.
        Version : 1.3.00
    Orig Family : 32ea66cc
         Family : 32ea66cc
     Generation : 0000000d
  Creation Time : Unknown
     Attributes : a4000002 (supported)
           UUID : 88bbfdfc:e15f634a:aaea4d4f:23268101
       Checksum : 6e629ee5 correct
    MPB Sectors : 1
          Disks : 2
   RAID Devices : 1

  Disk00 Serial : WD-WCC7K6DLTJ9H
          State : active
             Id : 00000003
    Usable Size : 7814031360 (3.64 TiB 4.00 TB)

[RAID]:
       Subarray : 0
           UUID : c8a70ac5:f1cddbfd:f0243eb0:5a417233
     RAID Level : 1
        Members : 2
          Slots : [UU]
    Failed disk : none
      This Slot : 0
    Sector Size : 512
     Array Size : 7814031360 (3.64 TiB 4.00 TB)
   Per Dev Size : 7814031624 (3.64 TiB 4.00 TB)
  Sector Offset : 0
    Num Stripes : 30523560
     Chunk Size : 64 KiB
       Reserved : 0
  Migrate State : idle
      Map State : normal
    Dirty State : clean
     RWH Policy : off
      Volume ID : 1

  Disk01 Serial : WD-WX42D61ANNAJ
          State : active
             Id : 00000005
    Usable Size : 7814031360 (3.64 TiB 4.00 TB)
mdadm: No md superblock detected on /dev/sde1.
/dev/sde2:
   MBR Magic : aa55
Partition[0] :   1836018464 sectors at   1380404564 (type 0a)
Partition[1] :   1953723749 sectors at   1309281536 (type 69)
Partition[2] :   1953251627 sectors at   1735554131 (type 6d)
Partition[3] :        55233 sectors at   2978742282 (type 66)
/dev/sdg:
          Magic : Intel Raid ISM Cfg Sig.
        Version : 1.3.00
    Orig Family : 32ea66cc
         Family : 32ea66cc
     Generation : 0000000d
  Creation Time : Unknown
     Attributes : a4000002 (supported)
           UUID : 88bbfdfc:e15f634a:aaea4d4f:23268101
       Checksum : 6e629ee5 correct
    MPB Sectors : 1
          Disks : 2
   RAID Devices : 1

  Disk01 Serial : WD-WX42D61ANNAJ
          State : active
             Id : 00000005
    Usable Size : 7814031360 (3.64 TiB 4.00 TB)

[RAID]:
       Subarray : 0
           UUID : c8a70ac5:f1cddbfd:f0243eb0:5a417233
     RAID Level : 1
        Members : 2
          Slots : [UU]
    Failed disk : none
      This Slot : 1
    Sector Size : 512
     Array Size : 7814031360 (3.64 TiB 4.00 TB)
   Per Dev Size : 7814031624 (3.64 TiB 4.00 TB)
  Sector Offset : 0
    Num Stripes : 30523560
     Chunk Size : 64 KiB
       Reserved : 0
  Migrate State : idle
      Map State : normal
    Dirty State : clean
     RWH Policy : off
      Volume ID : 1

  Disk00 Serial : WD-WCC7K6DLTJ9H
          State : active
             Id : 00000003
    Usable Size : 7814031360 (3.64 TiB 4.00 TB)
mdadm: No md superblock detected on /dev/sdg1.
/dev/sdg2:
   MBR Magic : aa55
Partition[0] :   1836018464 sectors at   1380404564 (type 0a)
Partition[1] :   1953723749 sectors at   1309281536 (type 69)
Partition[2] :   1953251627 sectors at   1735554131 (type 6d)
Partition[3] :        55233 sectors at   2978742282 (type 66)

~$ sudo mdadm --assemble --scan
mdadm: No arrays found in config file or automatically

~$ sudo mdadm --incremental /dev/sde
mdadm: No OROM/EFI properties for /dev/sde
mdadm: no RAID superblock on /dev/sde.
~$ sudo mdadm --incremental /dev/sdg
mdadm: No OROM/EFI properties for /dev/sdg
mdadm: no RAID superblock on /dev/sdg.

~$ sudo mdadm --assemble /dev/md/imsm0 /dev/sde /dev/sdg
mdadm: No OROM/EFI properties for /dev/sde
mdadm: no RAID superblock on /dev/sde
mdadm: /dev/sde has no superblock - assembly aborted

Copilot says the regression comes from this commit: 1fc0f29

[mtkaczyk]

Hello,
That makes sense:

for close to a decade now without any issues but after an update approximately two months ago the disks showed up separately

and the commit title:

Disable legacy option ROM scan on UEFI machines

Did you checked this:
if (stat("/sys/firmware/efi", &st) == 0 && S_ISDIR(st.st_mode))

ie. do you have /sys/firmware/efi directory? could you please search for there:

#define SCU_PROP "RstScuV"
#define AHCI_PROP "RstSataV"
#define AHCI_SSATA_PROP "RstsSatV"
#define AHCI_TSATA_PROP "RsttSatV"
#define VROC_VMD_PROP "RstUefiV"
#define RST_VMD_PROP "RstVmdV"

Probably we should reinvent the logic -> check efi -> check acpi -> check orom or make orom verifcation configurable via config option.

@bkucman what do you think?

[bkucman]

Hi,
Could you provide more details, such as mdadm --detail-platform from 4.4.2 and using a latest version(You don't have to install mdadm, it's enough to compile it and run ./.. ), what models of disks you used.

Base EFI OROM dectection flow expects to find one of files mentiond by mtkaczyk in

/sys/firmware/efi/vars/
/sys/firmware/efi/efivars/

[JosuaRieder]

@mtkaczyk

~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 May 29 20:58 /sys/firmware/efi
~$ ls -l /sys/firmware/efi
total 0
-r--r--r--  1 root root 4096 May 29 21:01 config_table
drwxr-xr-x  2 root root    0 May 29 20:58 efivars
drwxr-xr-x  3 root root    0 May 29 21:01 esrt
-r--r--r--  1 root root 4096 May 29 21:01 fw_platform_size
-r--r--r--  1 root root 4096 May 29 21:01 fw_vendor
-r--r--r--  1 root root 4096 May 29 21:01 runtime
drwxr-xr-x 11 root root    0 May 29 21:01 runtime-map
-r--------  1 root root 4096 May 29 21:01 systab

@bkucman

~$ mdadm --version
mdadm - v4.4 - 2024-12-13
~$ sudo mdadm --detail-platform
mdadm: imsm capabilities not found for controller: /sys/devices/pci0000:00/0000:00:11.4 (type SATA)
       Platform : Intel(R) Rapid Storage Technology
        Version : 14.8.0.2377
    RAID Levels : raid0 raid1 raid5 raid10 
    Chunk Sizes : 4k 8k 16k 32k 64k 128k 
    2TB volumes : supported
      2TB disks : supported
      Max Disks : 6
    Max Volumes : 2 per array, 4 per controller
 I/O Controller : /sys/devices/pci0000:00/0000:00:1f.2 (SATA)
          Port5 : /dev/sdg (WD-WX42D61ANNAJ)
                    Encryption(Ability|Status): Other|Unencrypted
          Port1 : /dev/sdd (<removed>)
<removed>
          Port3 : /dev/sde (WD-WCC7K6DLTJ9H)
                    Encryption(Ability|Status): Other|Unencrypted
          Port4 : /dev/sdf (<removed>)
<removed>
          Port0 : /dev/sdc (<removed>)
<removed>
          Port2 : - non-disk device (<removed>) -

and

/tmp/tmp.nnSTnxpvUm/mdadm$ ./mdadm --version
mdadm - v4.6-2-g2accfdfc - 2026-05-05
/tmp/tmp.nnSTnxpvUm/mdadm$ sudo ./mdadm --detail-platform
mdadm: imsm capabilities not found for controller: /sys/devices/pci0000:00/0000:00:1f.2 (type SATA)
mdadm: imsm capabilities not found for controller: /sys/devices/pci0000:00/0000:00:11.4 (type SATA)

I only have the efivars one and it doesn't contain any Rst files:

/tmp/tmp.nnSTnxpvUm/mdadm$ find /sys/firmware/efi/efivars/ | wc -l
91
/tmp/tmp.nnSTnxpvUm/mdadm$ find /sys/firmware/efi/efivars/ -iname Rst* | wc -l
0

[mtkaczyk]

Thank you so we see an issue. You have efi system lacking of IMSM efivars. Probably very legacy setup.

Definitely the logic proposed in 1fc0f29 caused a regression.

We and @bkucman will meet to propose solution. Please be patient!