SAMSUNG 970 EVO PLUS 500GB invisible to OMLx 4.0

Tags: #<Tag:0x00007f37323d8cc0>

Note to all users: OpenMandriva ISO’s already have this workaround. Under “Troubleshooting” there is one option for (PCIE ASPM=OFF) which worked for me. There is also right under that one an option for (NVME APST=OFF) which will work for some hardware.

New computer with Ryzen5 3600 CPU and ASRock X570 Phantom Gaming 4 wifi ax motherboard. Also 32GB RAM GSkill Ripjaws V DDR4/3600. And the current problem piece a SAMSUNG 970 EVO PLUS 500GB M.2/2280 nvme SSD which for some reason OMLx 4.0 does not see. The motherboard does show this drive present. The following information is from the OMLx 4.0 x86_64 ISO.

If anything else is needed please inform and I’ll do what I do. Need to get this device working so I can do some installing and testing.

dmesg.txt (79.6 KB)

journalctl-b.txt (29.2 KB)

lspci.txt (4.3 KB)

omv-bug-report.log.xz (63.7 KB)

There is not /dev/nvme or anything close. That is concerning…

Obviously lspci sees this much:

01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981 (rev ff)

And dmesg sees this:

[Wed Sep 25 04:28:12 2019] nvme nvme0: pci function 0000:01:00.0
[Wed Sep 25 04:28:12 2019] ahci 0000:07:00.0: version 3.0
[Wed Sep 25 04:28:12 2019] nvme nvme0: Removing after probe failure status: -19
[Wed Sep 25 04:28:12 2019] ahci 0000:07:00.0: AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x8 impl SATA mode
[Wed Sep 25 04:28:12 2019] ahci 0000:07:00.0: flags: 64bit ncq sntf ilck led clo only pmp fbs pio slum part

I will check tomorrow to see if the SSD has a firmware upgrade. The SSD is brand new but you never know. Example: I had to upgrade the BIOS with an update from 2019-09-17 to get OMLx 4.0 to boot. I’m sort of also rushing to get prepared for an out of town funeral at the same time or firmware would have been checked already.

I have tried these boot parameters:



Both of which gave this in dmesg:

nvme0: Removing after probe failure status: -19

Any ideas or help greatly appreciated.

I don’t know why ‘journalctl -b’ is so skimpy and obviously not much about the boot. Unless I was supposed to run ‘sudo journalctl -b’. There is a journalctl -b in the omv-bug-report.log.xz maybe it is the “real” one.

Since this is a new computer if any of you see anything at all amiss let me know so I can check it out.

Note: Silly me thought I’d avoid this type of problem with a Samsung 970 EVO PLUS but did not work out that way. I mean it’s a Samsung.

what returns

sudo fdisk -l 
sudo lsblk -fs 

Hi Ben,
A few months ago, I experimented the same kind of problem with a new All-in-One…
At first, it was a problem of obsolete kernel (4.x.first generation) which was present on the (dating) distribution I intended to install…
After changing this distribution for a one with more recent kernel, things didn’t go much better, until I found that my BIOS with all the “secure stuff”, “UEFI start” and other barbarian settings imposed by Microsoft was the responsible for my SSD M2 not being seen by the installators…
Did you notice, if your drive appeared in Calamares?
If it didn’t, don’t go farther, try to change some settings with your BIOS until it does. And if there is nothing to do with that, try to format your disk by any other mean, and write something on it …that was the solution for me.

They don’t say anything about the Samsung SSD because they can’t see it. The device is not in /dev so commands like that or parted won’t do anything.

Drive is seen by SystemRescue CD. I can do things with GParted from SystemRescue CD. So problem is getting narrowed down to possible issue with OpenMandriva Lx I would think. One might think this fact eliminates BIOS settings as a cause. Also I checked with Sansung SSD firmware utility and that says firmware for device is up to date. BIOS firmware also up to date.

Workaround: Add to boot parameters:


OMLx 4.0 installing as I write this.

i think its a bug in kernel , we have also this kind of matter in manjaro
nvme can appears but no UUID ,

if you have to force on pcie , ir means bios had to keep a secure boot on pcie for nmve

That is very possible. FWIW there certainly are reports elsewhere of problems with Samsung nvme devices having problems with recognition in Linux. So far I have seen or heard these possible sources of the cause:

  1. Samsung firmware
  2. BIOS firmware (I consider this possible but don’t really know yet)
  3. Linux Kernel
  4. AMD 3000 series CPU’s
  5. Whatever I’m forgetting or haven’t come across yet.

But I don’t know. I hope over time whomever upstream figures this out and problem gets resolved. Meanwhile we have a workaround for me and other users.

:see_no_evil: :speak_no_evil: :hear_no_evil:


                                                      (off topic humor)

Posting these files for @abucodonosor and anyone else that wants to work towards resolution of this problem.

@abucodonosor these files are from yesterday evening while we were talking. The inxi -F file tells my hardware plus what kernel was in use ect. System was installed from the regular X86_64 ISO from SourceForge.

inxi-F.txt (2.2 KB)

dmesg.txt (84.4 KB)

lspci-nnvv.txt (92.5 KB)

sensors-detect.txt (5.0 KB)

sensors.txt (2.2 KB)

By all means let me know if there is more needed or any tests I can do. I did install cooker kernel 5.3.1 in the system and it works but all the files were pulled under kernel 5.1.21. Will be installing znver1 Rock system soon.

Missed a file:

nvme.txt (1.7 KB)

Just to emphasize the use of those Troubleshooting boot options:
Selecting PCIE ASPM=OFF helped making my Corsair Force MP510 m.2 NVMe visible and useable to Calamares. Installation went through smoothly as expected and took only somewhat below 5 minutes!

Edit: Don’t forget to first boot your fresh installed system with pcie_aspm=off and to put this parameter into /etc/default/grub as well!