HP SSD EX900 M.2 250GB shown as 1GB only

[sam]

Hi,
a few days ago I got my first Rock Pi 4 Model A 2GB V1.4, together with a heat sink block and the M.2 Extend board v1.4.
All works fine with booting the system from a 8GB µSD card, so I can use it.

Today I got a HP SSD EX900 M.2 250GB, which is being recognized by the system as 1 GB only:

# lsblk -o NAME,MODEL,SIZE,FSTYPE | grep nvme
nvme0n1     SM2263 1024M

Also parted and fdisk show 1GB only for that device.

# parted /dev/nvme0n1 print
Error: /dev/nvme0n1: unrecognised disk label
Model: SM2263 (nvme)                                                      
Disk /dev/nvme0n1: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

# fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 1023.102 MiB, 1073741312 bytes, 2097151 sectors
Disk model: SM2263  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Here’s the kernel version I’m using:

# uname -r
5.4.6+

What’s wrong?

[fivcle]

Hi,
I had the similar problem with my M.2 SSD put on extend board. But after a few days of using this setup.
So I have partition created and in usage.

ls /dev/ grep | nv

was showing only the

nvme0
nvme0n1

instead of

nvme0
nvme0n1
nvme0n1p1

fdisk was showing some small capacity of disk and wasn’t able to create any partition on it.

Problem was in connection between ROCK Pi 4 board and the small board which is put into Rock Pi’s m.2 connector. After disconnecting all connection between ROCK Pi and M.2 disk I used compressed air to clean them up, connect everything back. It helped. Please check if it will be helpful for you.
If not, I suggest to connect M.2 disk directly to M.2 connector on ROCK Pi and check if disk is visible correctly then.

[pbies]

I suspect that you have partition data beginning at disk’s 0 sector (where should be MBR), so you may want to make MBR with fdisk and then create 1st partition.
Before:
nvme0n1 - that’s the whole disk beginning at sector 0

After:
nvme0n1 - as above
nvme0n1p1 - first partition beginning usually at 1 MB from beginning of the disk

After partition creation you should restart the device to reread the partition table (yes, there are other ways). Check then if the disk is visible properly.

[sam]

Hi,
thanks for your answers.
Now I plugged the SSD module directly to the RockPi (without Extender board) but the system still fails recognizing more than 1GB and neither parted nor fdisk are able to create/write the MBR. No matter if I reboot the system or not.

Here’s a screenshot of the behavior when trying to create the MBR on the NVMe device (/dev/nvme0n1) compared with the same procedure on an USB flash device (/dev/sda):

[fivcle]

Hi @sam,
It is rather some comment, instead of advice or solution.

My SSD is same as yours: HP SSD EX900 M.2 250GB
I quite often transport my ROCK Pi 4 + m.2 extension set in carton box in my backpack. The flat wire which connects both PCB isn’t secured by anything and is quite fragile for such handling.
So the connection between both parts sometimes is broken. That is the way I reproduced my failure with not correctly connected m.2 disk.
While my SSD isn’t connected correctly then result looks as yours:

# fdisk /dev/nvme0n1 
[...]
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xbcd4dcb7.

Command (m for help): F
Unpartitioned space /dev/nvme0n1: 1023 MiB, 1072692736 bytes, 2095103 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Start     End Sectors  Size
 2048 2097150 2095103 1023M

Command (m for help): p
Disk /dev/nvme0n1: 1024 MiB, 1073741312 bytes, 2097151 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbcd4dcb7

If the disk is conneted correctly then:

# fdisk /dev/nvme0n1
[...]
Command (m for help): F
Unpartitioned space /dev/nvme0n1: 132.9 GiB, 142684119040 bytes, 278679920 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

    Start       End   Sectors   Size
209717248 488397167 278679920 132.9G

Command (m for help): p
Disk /dev/nvme0n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe76b2d27

Device         Boot Start       End   Sectors  Size Id Type
/dev/nvme0n1p1       2048 209717247 209715200  100G 83 Linux

So maybe somehow your SSD doesn’t connect electrically correctly to ROCK Pi 4 ?
(I noticed you already tried to connect it directly…)

Did you have opportunity to check your disk with other m.2 host to check if it is working properly? (PC maybe?)

[sam]

Hi @fivcle,
thank you so much for investigating this issue and for confirming that the same SSD works for you.

Sadly I don’t have any other device with an M.2 interface, but I ordered an M.2 to PCIe adapter, so hopefully I can check it soon on my PC.

[sam]

Now I could check the SSD on my PC and it’s working. So it looks like the M.2 interface on the RockPi is bricked.

[Dante4]

Before go to hardware fault - test different OS. Try Armbian, both 4.4 and 5.X from armbian forum. Debian and Ubuntu from Radxa wiki. And Libreelec from libreelec

[sam]

Now I got another rockpi device and get the same error, no matter if I connect the SSD directly or with m.2 extender. Both devices are “Rock Pi 4A v1.4”, one with 2G and the other with 4G RAM.
My linux distribution is SLARM64, which is an (unofficial) aarch64 port of Slackware-current, using kernel 5.5.8.
I also tested Armbian with kernel 5.4.32 and got the same error.

[sam]

Debian 9 (kernel 4.4) recognizes the SSD without any error, so it’s no hardware issue.

First I thought it could be a kernel based issue, but using kernel 4.4 instead of kernel 5.5 in Slarm64 shows no improvement, so it seem not to be dependent on the kernel version.

Any idea what makes the difference?

[aaditya]

I think the bootloader (u-boot) could make a difference.

The Debian 9 you speak of, is it from Armbian or Radxa?

Might want to report this issue to Slarm64 or Armbian, maybe they can help.

[sam]

I used the Debian 9 image from Radxa.
Btw, I also tested Manjaro and it also fails detecting the SSD correctly.
So I’ll report it to Slarm64, Armbian and Manjaro.
Thanks.