You are not logged in.
I have run into an odd problem with a new secondary NVMe drive I just installed in my desktop system (running kernel 4.19.2). Both drives are recognized during boot:
[ 1.024370] nvme nvme0: pci function 0000:03:00.0
[ 1.024394] nvme nvme1: pci function 0000:04:00.0
[ 1.243817] nvme0n1: p1
[ 1.287545] nvme1n1: p1 p2 p3 p4 p5 p6nvme0n1 is the new drive and nvme1n1 is the original drive. But only the original drive (my boot drive) is accessible:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:2 0 465.8G 0 disk
├─nvme1n1p1 259:3 0 18.6G 0 part /
├─nvme1n1p2 259:4 0 525M 0 part /boot
├─nvme1n1p3 259:5 0 3.7G 0 part [SWAP]
├─nvme1n1p4 259:6 0 93.1G 0 part /home
├─nvme1n1p5 259:7 0 9.3G 0 part /var
└─nvme1n1p6 259:8 0 340.5G 0 part /ssd_dataSome additional information:
I know the new drive works because I was able to access, partition and format it when I started the system from a bootable Arch USB stick (running kernel 4.14). Interestingly, when booting from the USB stick, the new drive appears as nvme1n1 and the original drive appears as nvme0n1. Since the parameter --disk /dev/nvme0n1 is required by efibootmgr in order to boot from the original drive, it seems the device name is changing early in the boot process from nvme0n1 to nvme1n1. I suspect the name change is causing the problem but I am not sure how to fix it and would really appreciate some ideas.
- Jon
Update: After looking through the output from lspci a couple more times I noticed that the kernel driver in use for the new NMVe drive's controller was vfio-pci instead of nvme. It turns out the IOMMU group the controller was attached to was being passed through via OVMF (for use with QEMU) by my vfio-bind service. Since that particular IOMMU group is not critical (was for onboard audio IIRC), I just deleted it from my vfio-bind config, rebooted and magically, the drive appeared as nvme0n1. Sorry for the confusion and I hope this helps someone else troubleshooting block device problems!
Last edited by Da_Coynul (2018-11-17 23:26:08)
Offline
What was the command for the above output, just `lsblk`? What are the actual symptoms of the other drive not being "accessible"? What have you tried, what has failed? Is the device node under /dev/ (`ls /dev/nvme*`)? What is the output of `lsblk -a`? dmesg? journal?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
What was the command for the above output, just `lsblk`? What are the actual symptoms of the other drive not being "accessible"? What have you tried, what has failed? Is the device node under /dev/ (`ls /dev/nvme*`)? What is the output of `lsblk -a`? dmesg? journal?
That was the output from lsblk; I edited out my non-NVMe drives to make it less confusing. The relevant dmesg section was included above the lsblk output. There was nothing helpful in the journal. Basically the drive just does not exist unless I boot from the USB stick!
Last edited by Da_Coynul (2018-11-17 18:01:04)
Offline
I edited out ... The relevant dmesg section ... There was nothing helpful in the journal.
So you are filtering all the relevant diagnostic information based on your assessment of what is relevant, helpful, or important. Do you not see how this prevents any progress as it requires an implicit assumption that you are already fully aware of everything that is relevant, helpful, or useful. If this assumption was true then there couldn't possibly be anyone here that could help you. So why post here asking for help?
Post the requested information, unfiltered.
https://bbs.archlinux.org/viewtopic.php?id=57855
http://catb.org/~esr/faqs/smart-questions.html#symptoms
Last edited by Trilby (2018-11-17 16:46:33)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline