# Intel imsm fakeraid unsupported attributes [SOLVED]

## motig

I have purchased an HP EliteBook 840 G2 laptop which comes with Intel fake raid controller, used primarily for "accelerating" the HDD by caching data on a smaller SSD. There is a 1 TB HDD and a 30 GB SSD drive. From what I have read on various forums, this SSD caching is not directly supported in Linux. However, I decided to try a hybrid solution. I disabled the caching feature completely in Windows, then created new partitions for Gentoo, installed a base system and GRUB. Afterwards, I re-enabled the caching but I allocated only 20 GB of the 30 GB SSD drive to caching. The other 10 GB volume is marked as "normal" and I was indeed able to create a partition on it in Windows. Intel fake raid software claims it is a RAID-0 volume with 1 disk, which struck me as weird.

Rebooting to Gentoo, it indeed does not work.

lsblk

```

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

sda      8:0    0 931,5G  0 disk 

├─sda1   8:1    0   500M  0 part 

├─sda2   8:2    0   499M  0 part 

├─sda3   8:3    0     1K  0 part 

├─sda5   8:5    0 347,5G  0 part 

├─sda6   8:6    0   512M  0 part [SWAP]

├─sda7   8:7    0    24G  0 part /

├─sda8   8:8    0    64G  0 part 

└─sda9   8:9    0 494,5G  0 part 

sdb      8:16   0  29,8G  0 disk

```

blkid

```

blkid

/dev/sdb: TYPE="isw_raid_member"

/dev/sda1: UUID="0684EC3684EC29BF" TYPE="ntfs" PARTUUID="fa4ecbf7-01"

/dev/sda2: UUID="72A0F302A0F2CB9B" TYPE="ntfs" PARTUUID="fa4ecbf7-02"

/dev/sda5: UUID="8EF87385F8736A7B" TYPE="ntfs" PARTUUID="fa4ecbf7-05"

/dev/sda6: UUID="bd4cc8e8-2945-4c9e-9d41-c32533a790ec" TYPE="swap" PARTUUID="fa4ecbf7-06"

/dev/sda7: LABEL="ROOT" UUID="ce90e576-de8d-4134-a28e-b1de489a4b61" TYPE="ext4" PARTUUID="fa4ecbf7-07"

/dev/sda8: PARTUUID="fa4ecbf7-08"

/dev/sda9: PARTUUID="fa4ecbf7-09"

```

Partitions 8 and 9 are not used yet but will be used later for ext4 filesystems.

mdadm --detail-platform

```

       Platform : Intel(R) Matrix Storage Manager

        Version : 13.2.0.2134

    RAID Levels :

    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)

```

So far everything looks OK but the problems start here. Volume_0000 is the volume I want to use in Gentoo, since it is not used for anything else.

mdadm --examine /dev/sdb

```

/dev/sdb:

          Magic : Intel Raid ISM Cfg Sig.

        Version : 1.3.00

    Orig Family : bf4e6014

         Family : bf4e6014

     Generation : 00000010

mdmon: (IMSM): Unsupported attributes : 2000000

     Attributes : not supported

           UUID : 58fce6aa:ef57c65b:8b670c55:ca35f915

       Checksum : ee240255 correct

    MPB Sectors : 2

          Disks : 1

   RAID Devices : 2

  Disk00 Serial : 002523129737

          State : active

             Id : 00000003

    Usable Size : 62528008 (29.82 GiB 32.01 GB)

[Volume_0000]:

           UUID : 2f1f8af3:ed3ec2d5:378b6d8f:0e2cd2b7

     RAID Level : 0

        Members : 1

          Slots : [U]

    Failed disk : none

      This Slot : 0

     Array Size : 20588544 (9.82 GiB 10.54 GB)

   Per Dev Size : 20588808 (9.82 GiB 10.54 GB)

  Sector Offset : 0

    Num Stripes : 80424

     Chunk Size : 128 KiB

       Reserved : 0

  Migrate State : idle

      Map State : normal

    Dirty State : clean

[Volume_0001]:

           UUID : 504e8d5f:8d0d16bb:b04aaa7c:b31303b4

     RAID Level : 0

        Members : 1

          Slots : [U]

    Failed disk : none

      This Slot : 0

     Array Size : 41934848 (20.00 GiB 21.47 GB)

   Per Dev Size : 41935112 (20.00 GiB 21.47 GB)

  Sector Offset : 20592896

    Num Stripes : 163808

     Chunk Size : 128 KiB

       Reserved : 0

  Migrate State : idle

      Map State : normal

    Dirty State : clean

```

mdadm --assemble --scan

```

mdmon: (IMSM): Unsupported attributes : 2000000

mdmon: Unsupported attributes in IMSM metadata.Arrays activation is blocked.

mdmon: : platform does not support raid0 with 1 disk

mdmon: IMSM RAID geometry validation failed.  Array Volume_0000 activation is blocked.

mdmon: : platform does not support raid0 with 1 disk

mdmon: IMSM RAID geometry validation failed.  Array Volume_0001 activation is blocked.

mdadm: Cannot activate member /md127/1 in /dev/md/imsm0.

mdadm: Cannot activate member /md127/0 in /dev/md/imsm0.

mdadm: No arrays found in config file or automatically

```

cat /proc/mdstat

```

Personalities : [linear] 

md127 : inactive sdb[0](S)

      2644 blocks super external:imsm

       

unused devices: <none>

```

Is there any workaround I could try to access "Volume_0000"? I would like to use it for caching using bcache. Maybe some different way of mapping the range occupied by Volume_0000 and accessing it directly? I guess device mapper might be capable of this but I do not have much experience with it.Last edited by motig on Tue Oct 11, 2016 6:42 pm; edited 2 times in total

----------

## s4e8

remove mdadm completely or add "AUTO -imsm +all" to /etc/mdadm.conf to prevent mdadm detecting imsm disks.

Due to Volume_0000 started at sector 0, it's fine to access sdb directly if all partitions don't exceed size of Volume_0000.Last edited by s4e8 on Tue Oct 11, 2016 4:52 pm; edited 1 time in total

----------

## motig

 *s4e8 wrote:*   

> remove mdadm completely or add "AUTO -imsm +all" to /etc/mdadm.conf to prevent mdadm detecting imsm disks.

 

I am only using mdadm because I thought I would be able to use the fake raid Volume_0000. I am only interested in access to the raw blocks occupied by it though. If there is any method of mapping these blocks from /dev/sdb to a new block device so I can use them, I do not need to use mdadm.

----------

## motig

I created a ntfs file system on the Volume_0000 so I could find the start of the volume using the first seven bytes of a NTFS file system (i.e. eb52904e544653).

It turned out to be 1048576 bytes (2048 sectors). According to mdadm the volume has a size of 20588544 sectors. Thus I was able to map the sector range into a new device:

```

dmsetup create ssd --table '0 20588544 linear /dev/sdb 2048'

```

Mounting the existing ntfs works so I'm marking this as solved.

----------

## s4e8

Volume_0000 always started at sector 0, you can access /dev/sdb1 directly, if don't change partition layout or exceed size of Volume_0000. In your case, you create the Volume_0000p1 not Volume_0000, with size of Volume_0000. If you rewrite end of created device, you will destory imsm acceleration.

 *motig wrote:*   

> I created a ntfs file system on the Volume_0000 so I could find the start of the volume using the first seven bytes of a NTFS file system (i.e. eb52904e544653).
> 
> It turned out to be 1048576 bytes (2048 sectors). According to mdadm the volume has a size of 20588544 sectors. Thus I was able to map the sector range into a new device:
> 
> ```
> ...

 

----------

## motig

Yes, if I disable acceleration in Intel software, then I can see /dev/sdb1 and it behaves like a regular disk - though it does not begin at sector 0 but at sector 2048. With acceleration enabled I can only see /dev/sdb with no partitions - I am guessing the Intel software writes some metadata there instead of a partition table.

I took the size for device mapper from what mdadm reported for Volume_0000. In the end made it a little smaller to be sure nothing overwrites the imsm acceleration data.

----------

## s4e8

imsm put metadata and acceleration volume at end of disk. When you activate mdadm, kernel will take over /dev/sdb, make the partitions in-accessible. The Volume_0000 IS started at sector zero, and it's a partitionable disk device, the NTFS is first partition of Volume_0000, aligned at 1M (2048 sector), the max size of this NTFS partition is size_Volume_0000 - 2048.

 *motig wrote:*   

> Yes, if I disable acceleration in Intel software, then I can see /dev/sdb1 and it behaves like a regular disk - though it does not begin at sector 0 but at sector 2048. With acceleration enabled I can only see /dev/sdb with no partitions - I am guessing the Intel software writes some metadata there instead of a partition table.
> 
> I took the size for device mapper from what mdadm reported for Volume_0000. In the end made it a little smaller to be sure nothing overwrites the imsm acceleration data.

 

----------

