FW Intel 11th Gen :NVMe Drive not detected

Hi all,

I wanted to save some money and bought a factory seconds 11th gen framework 13. I wanted to reuse the RAM and NVMe drive of my old notebook (Toshiba thnsf5512gpuk). The RAM seems to be working as expected. The drive is a PCIe Gen 3.0 drive and as far as I know PCIe 4.0 should be backwards compatible. It has a fedora 40 installation on it that I was using on my old Lenovo T14. Unfortunately, the drive is not detected.

I had a fedora 38 usb live iso, there it was detected at least with lspci, but it was not listed via lsblk.
I thought there was maybe a driver issue and I updated the live iso to Fedora 40, now its not even detect with lspci.
I ran dmesg, but I didn’t find anything that something todo with NVMe.
I’m not sure whether it has GPT or MBR on it, but at least to my understanding I should be able to see it in my live iso.

Tomorrow, I will put it into my old laptop to check whether it still works, but otherwise I’m currently out of ideas. If anybody some further ideas for troubleshooting or to identify whether this drive is simply not compatible, I’d be really happy.

The bios should be version 3.19 and it has Intel® Core™ i7-1185G7.

Thanks in advance for your help.

My guess is that the drive is not formatted in a way that the machine can see it. I agree that popping it back into your old machine and getting the details of the partition type, partition scheme, etc will help. IIRC it needs to be et up for EFI - legacy (MBR) won’t work. Best of luck!

The thing that bothers me is that even if it is legacy MBR the device should be detectable. I don’t necessary need to boot from the installation, but I should be able to find it in the live iso.
If required I would install the OS again, but the installer did not detect it.

Yeah, I don’t understand why you saw it on v38 but not v40, that seems odd, but I certainly am no expert.

So I popped the drive in my old laptop, drive is detected and when I check with parted I see that its a gpt drive:

christoph@fedora:~$ sudo parted -l
[sudo] password for christoph: 
Model: THNSF5512GPUK TOSHIBA (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  630MB   629MB   fat32        EFI System Partition  boot, esp
 2      630MB   1704MB  1074MB  ext4
 3      1704MB  512GB   510GB   btrfs


Model: Unknown (unknown)
Disk /dev/zram0: 8590MB
Sector size (logical/physical): 4096B/4096B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system     Flags
 1      0.00B  8590MB  8590MB  linux-swap(v1)

christoph@fedora:~$ sudo gdisk -l /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB
Model: THNSF5512GPUK TOSHIBA                   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): F01928D7-9101-45FC-94E5-4BE5A6CF38B7
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1230847   600.0 MiB   EF00  EFI System Partition
   2         1230848         3327999   1024.0 MiB  8300  
   3         3328000      1000214527   475.4 GiB   8300

I don’t understand what this protective MBR is.

Protective MBR AFAIK is just a normal part of GPT that is a way to have an MBR while protecting the disk from software “unaware” of GPT that would otherwise treat the drive as if it were pure MBR while it is actually GPT. I have it too on my nvme, 11th gen so I don’t think that is the source of the issue.

I would try the live environment on the T14 and see if the behaviour is the same, if it is detected you might want to wipe/delete all partition then see what happens when you put it back into the Framework and try the live env. there again.

It would be a good idea to inspect the m.2 port for damage or foreign object etc. and assuming nothing looks off try another nvme drive to check for hardware defects with your Framework.

Edit: Also “BIOS” 3.20 is current 11th Gen Intel Core BIOS 3.20 Release and Driver Bundle Update

1 Like

Booted my T14 into the live environment, the SSD is detected as expected

I checked the NVMe slot for damage/debris and I didn’t see anything.



I deleted the partition table using gparted, but still it was not detected by the installer. But it was detected by lspci and I get the doubt that it’s the drives fault. I found the following message in dmesg when starting the live iso

I ordered now a WD Black SN770, which is on the compatible list, to check whether it’s the drive or the mainboard.

I had a SSD from a Dell XPS 15" model that I had upgraded (drive was from around a 2018 model) and nothing I could do would let it be “seen” by the installer but it would show up in an external case. Something unique about older NVMe drives that I am guessing was not standardized later on. I think it was a 256 gb model. So it became a spare backup drive and I spent the $50 and bought a 1TB to replace it.

1 Like

It sounds like it maybe a compatibility issue as pkunk suggested. I’m not sure why else the drive wouldn’t work. I wonder if the firmware on the drive has an update which might help?

So short update, the WD Black SN770 worked out of the box. I put my old SSD into a external M.2 enclosure and it also works. So I guess its simply some incompatibility thing. Thanks all for your input.

2 Likes