MS-Windows secondary-storage (disk-drive) not showing up from Elementary OS (2 separate drives)

Question

Solved: I received some OS updates and noticed that on boot, grub now shows, which it didn't before (I was using F12 to change boot drives), and now the nvme partitions are showing using the below commands, and also shows in the standard File Manager (picture attached as proof)!

Thanks to all who contributed!

Below is the original post, for posterity.

I'm running dual-boot Linux and Windows on a laptop with 2 internal drives, specifically Elementary OS on a 500GB SSD and Windows 10 on a 1TB NVME SSD.

I want to make an NTFS partition on the 1TB Windows drive and mount it on Elementary so I can share data between OSs, however the 1TB drive doesn't show at all under /dev/sda on Elementary, as shown below:

# cat /proc/partitions

major minor  #blocks  name

   8        0  488386584 sda
   8        1     524288 sda1
   8        2  487860224 sda2

---

# fdisk -l /dev/sda

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7B0055C1-DE1E-4030-BA1A-7F766ED3190C

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1050623   1048576   512M EFI System
/dev/sda2  1050624 976771071 975720448 465.3G Linux filesystem

However the Linux drive does show up from Windows Disk Management (albeit inaccessible due to filesystem), Disk 0 is Elementary, Disk 1 is Windows.

I want to make sure eOS can see the second drive, then I'll make the separate NTFS partition on Disk 1 and mount it. I don't want to go through the hassle of resizing/making partitions before knowing the drive is even accessible.

EDIT: Tried using lspci -nn to find the drives, but I'm not sure how to read it properly. Maybe it's the Serial Bus Controllers but I'm not sure.

00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e10] (rev 07)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:3e9b]
00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model [8086:1911]
00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Lake PCH Thermal Controller [8086:a379] (rev 10)
00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] (rev 10)
00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f] (rev 10)
00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560 [Jefferson Peak] [8086:a370] (rev 10)
00:15.0 Serial bus controller [0c80]: Intel Corporation Device [8086:a368] (rev 10)
00:15.1 Serial bus controller [0c80]: Intel Corporation Device [8086:a369] (rev 10)
00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH HECI Controller [8086:a360] (rev 10)
00:17.0 RAID bus controller [0104]: Intel Corporation 82801 Mobile SATA Controller [RAID mode] [8086:282a] (rev 10)
00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:a335] (rev f0)
00:1e.0 Communication controller [0780]: Intel Corporation Device [8086:a328] (rev 10)
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:a30d] (rev 10)
00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS [8086:a348] (rev 10)
00:1f.4 SMBus [0c05]: Intel Corporation Cannon Lake PCH SMBus Controller [8086:a323] (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller [8086:a324] (rev 10)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c91] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)
06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 25)

EDIT2: rfmodulator suggested ls -1 /dev/nvme* and here are the results:

/dev/nvme0
/dev/nvme0n1
/dev/nvme0n1p1
/dev/nvme0n1p2
/dev/nvme0n1p3
/dev/nvme0n1p4
/dev/nvme0n1p5

The windows drive does have 5 partitions so this could be useful (p1-5)?

Answer 1

While Windows's fast start up is known to put your data in shared NTFS partitions at risk (you really want to turn it off, at least if the shared partition is the Windows system partition), it has definitely nothing to do with eOS not recognizing the NVMe SSD.

I am nearly sure that we can rule out everything which might be already stored on that SSD as reason for the problem. The most probable reason is that eOS simply does not recognize that SSD or the controller it is attached to, which can happen for various reasons.

Some of your options are:

• Surprisingly often, such problems are resolved by BIOS updates (although they seem to be due to an O/S or driver issue). So you could look whether there is a new BIOS for your PC, and then try again.

• If no new BIOS is available, or updating it did not help, you could just wait a few weeks (Linux kernels and drivers develop quite fast if the hardware is not too exotic), or you could try to install a kernel (which normally includes the drivers) which is newer than that of your O/S from a repository outside the official ones (I don't know eOS, so I can't help you with doing that).

• Perhaps there is already a driver for the respective piece of hardware, but it is not yet included in eOS. In this case, you can try to compile it yourself (this may involve compiling a new kernel as well, though).

• To further investigate, you could install a Linux distribution which is closely similar to eOS, but more widely used, on a DVD-ROM or USB key, boot it from there and see whether it recognizes the drive in question. As a starting point, I'd suggest Ubuntu (AFAIK eOS is based on Ubuntu) or perhaps the testing or even non-stable version of Debian (Ubuntu is based on Debian).

  If one of the other Linux distributions recognizes the drive in question, you can safely assume that the respective driver already has made it into recent Linux kernels and that it will soon arrive in eOS, too.

Answer 2

The problem has fixed itself - as part of doing standard OS updates, I noticed that grub now shows on boot and the nvme partitions show in File Manager, more details in OP.

Thanks to all who contributed!