Grub-probe can’t see my NVME drive

Support
1

grub-probe can’t see my NVME drive- and now I can’t boot into my Manjaro Testing install from that drive. I can still get into my Manjaro testing install from Grub on my Manjaro stable install, which isn’t having this issue.

If I try sudo update-grub here is my output:

Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.13-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.13-x86_64.img
Found initrd fallback image: /boot/initramfs-5.13-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme2n1.
done
1 Like
2

I have exactly the same problem and I’m looking for a solution too. Have you found it yet?

3

Can you post
fdisk - l
blkid

4

If you refer to this error, it is normal and probably not related with your problem.

update-grub writes its log to the system journals. You can review them to find whats the problem. It’s not the easiest thing to understand those logs, but maybe you can get some clue about what’s happening. Search for the device that holds your testing installation. So, run update-grub and then:

journalctl -b
5

This warning is really an ancient ‘issue’ and could be ignored or solved by

sudo rm /etc/grub.d/60_memtest86+

If an installation is not found on another drive most likely they are not installed in the same mode, grub only finds them if both are installed in either UEFI or in BIOS mode.

2 Likes
6

fdisk -

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

fdisk: cannot open -: No such file or directory

blkid returns nothing

7

I believe that these are the relevant lines from the log, but I really don’t know.

Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/05efi on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: 05efi: debug: /dev/nvme2n1p1 is a FAT32 partition
Aug 22 21:20:18 douglas-homepc root[2955]: 05efi: debug: /dev/nvme2n1p1 partition scheme is gpt
Aug 22 21:20:18 douglas-homepc root[2955]: 05efi: debug: /dev/nvme2n1p1 partition type is ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Aug 22 21:20:18 douglas-homepc root[2955]: 05efi: debug: /dev/nvme2n1p1 is not a ESP partition: exiting
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/10freedos on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: 10freedos: debug: /dev/nvme2n1p1 is a FAT32 partition
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/10qnx on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: 10qnx: debug: /dev/nvme2n1p1 is not a QNX4 partition: exiting
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/20macosx on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc macosx-prober[3372]: debug: /dev/nvme2n1p1 is not an HFS+ partition: exiting
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/20microsoft on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: 20microsoft: debug: Skipping legacy bootloaders on UEFI system
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/30utility on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: 30utility: debug: /dev/nvme2n1p1 is a FAT32 partition
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/40lsb on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/70hurd on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/80minix on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/83haiku on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: 83haiku: debug: /dev/nvme2n1p1 is not a BeFS partition: exiting
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/90linux-distro on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/90linux-distro.orig on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/mounted/90solaris on mounted /dev/nvme2n1p1
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: btrfs volume uuid=741e97c8-76a9-4e2e-a28d-b4885ec85444 partition=/dev/nvme2n1p2
Aug 22 21:20:18 douglas-homepc root[2955]: os-prober: debug: running /usr/lib/os-probes/50mounted-tests on btrfs /dev/nvme2n1p2
Aug 22 21:20:18 douglas-homepc root[2955]: 50mounted-tests: debug: begin btrfs processing for 741e97c8-76a9-4e2e-a28d-b4885ec85444
Aug 22 21:20:18 douglas-homepc root[2955]: 50mounted-tests: debug: btrfs volume 741e97c8-76a9-4e2e-a28d-b4885ec85444 mounted
8

This isn’t another drive. It’s the GRUB on the drive that holds Manjaro Testing install that can’t find the drive that Manjaro Testing is installed on.

9

You need to run fdisk and blkid as “root”.

fdisk -l
blkid

10

Oops, sorry! Here it is

fdisk -l

Disk /dev/nvme1n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: KXG60ZNV256G NVMe KIOXIA 256GB          
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: gpt
Disk identifier: 359D088C-BFFD-8541-8F72-3755BF4FEB79

Device          Start       End   Sectors   Size Type
/dev/nvme1n1p1   4096    618495    614400   300M EFI System
/dev/nvme1n1p2 618496 500103449 499484954 238.2G Linux filesystem


Disk /dev/nvme2n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 970 EVO Plus 500GB          
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: gpt
Disk identifier: F65282AF-37A2-4741-927A-941B4F7C6C72

Device           Start       End   Sectors   Size Type
/dev/nvme2n1p1    2048   1050623   1048576   512M Microsoft basic data
/dev/nvme2n1p2 1050624 976768031 975717408 465.3G Linux filesystem


Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 970 EVO Plus 500GB          
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: gpt
Disk identifier: E5B7A632-9B1A-C845-82F8-2E9DEEBEAAC9

Device          Start       End   Sectors   Size Type
/dev/nvme0n1p1   4096    618495    614400   300M EFI System
/dev/nvme0n1p2 618496 976768064 976149569 465.5G Linux filesystem

lsblk

/dev/nvme0n1p1: LABEL_FATBOOT="NO_LABEL" LABEL="NO_LABEL" UUID="A2BF-202B" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b8c30919-1e6b-834c-adab-fd2bfe44173c"
/dev/nvme0n1p2: UUID="38ca9ab0-bc46-49f7-aead-09593c757f6b" TYPE="crypto_LUKS" PARTLABEL="root" PARTUUID="df39d908-2aae-744a-8135-52eaff5b4ba4"
/dev/nvme2n1p2: UUID="741e97c8-76a9-4e2e-a28d-b4885ec85444" UUID_SUB="b0d62c1e-4e25-4d2f-a06b-7df1bd8c8635" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="cfc6a912-c7f6-224e-b222-6ca9716efbe1"
/dev/nvme2n1p1: LABEL_FATBOOT="NO_LABEL" LABEL="NO_LABEL" UUID="ABB6-DC24" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="acfebff9-36c8-7e4b-9277-4ea2972f33bb"
/dev/nvme1n1p2: UUID="88ab06f2-1880-4c05-a100-931f8f393c0c" TYPE="crypto_LUKS" PARTUUID="0826db42-e4b4-014b-ac29-8ee9e2973457"
/dev/nvme1n1p1: UUID="3703-DA8A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="62ff0235-310e-3b4d-afa9-bd5272e0114e"
11

Can you post
/etc/fstab ?

12

Update: Like I said above, I had exactly the same problem and got the solution.

First, the problem was caused because I formatted clean the 250mb fat32 /efi partition that came preinstalled when I was installing Manjaro. I believe the problem would not happen if didn’t format this little partition when installing the os.

Solution: Boot a Windows 10 installation disk, and hit SHIFT + F10. This will bring the windows command prompt. There, you just have to type: bcdboot X:\Windows where X represents the disk drive. and it normally is C. You can check this using fdisk.

The command above will rewrite the windows boot loader files where they are necessary. After that, on linux eu just need to use the command grub-mkconfig -o /boot/grub/grub.cfg as root and everything will be back to normal.

I did these steps following this article: How to restore an accidentally deleted Windows Boot Manager with a Windows / Arch Linux dual-boot installation | meroupatate

13

On drive

the ESP is missing.

14

At least this partition doesn’t seem to be right. You have to change the type of the partition. You can use gparted or gdisk, for example. Execute sudo gdisk /dev/nvme2n1, give the command t for type change, select partition 1 and set the type to EF00. Write and exit with command w.

After that, run again sudo update-grub to see if there is any change.

You have 3 disks with 3 different linux systems. Can you identify all three? Which one is which one?

17

I did try to install Windows 10 recently, but it wouldn’t let me, something about missing drivers. I tried a number of things, but don’t think I did anything that should have changed anything on nvme2. Of course, “should have” and “did” are two separate things.

I didn’t try the rest of this fix, as it doesn’t seem applicable without an actual Windows install.

18

I tried this, and it changed nvme2n1p1 from “Microsoft basic data” to “EFI System”. I updated grub, but when I try to boot from this drive it still skips it and goes to a different boot drive. I have three Linux OS’s installed, all Manjaro.

nvme2- Manjaro testing. This is my main “home use” install.
nvme1- Manjaro stable. This is my main “work use” install- but I am migrating to the last one:
nvme0- Manjaro stable. This is going to be my main “work use” install once I get the time to set everything up.

19 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=ABB6-DC24                            /boot/efi      vfat    umask=0077 0 2
UUID=741e97c8-76a9-4e2e-a28d-b4885ec85444 /              btrfs   subvol=/@,defaults,noatime,space_cache 0 1
UUID=741e97c8-76a9-4e2e-a28d-b4885ec85444 /home          btrfs   subvol=/@home,defaults,noatime,space_cache 0 2
UUID=741e97c8-76a9-4e2e-a28d-b4885ec85444 /var/cache     btrfs   subvol=/@cache,defaults,noatime,space_cache 0 2
UUID=741e97c8-76a9-4e2e-a28d-b4885ec85444 /var/log       btrfs   subvol=/@log,defaults,noatime,space_cache 0 2
UUID=741e97c8-76a9-4e2e-a28d-b4885ec85444 /swap          btrfs   subvol=/@swap,defaults,noatime,space_cache 0 2
/swap/swapfile                            swap           swap    defaults,noatime 0 0
20

Let’s see what are your UEFI entries. Please, show the output of:

sudo efibootmgr -v

Just to be sure, the fstab you posted is from your testing partition, isn’t it?

When you run update-grub, you do it from your stable installation, isn’t it?

Can you show the content of the /dev/nvme2n1p1 partition? There should be an EFI folder there. What’s inside that folder?

21

efibootmgr -v:

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0007,000A,0002,0003
Boot0000* Windows Boot Manager  HD(1,GPT,77ee9e91-39df-4409-8479-1a4019c12eb5,0x800,0x4b000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D
.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* Manjaro       HD(1,GPT,b8c30919-1e6b-834c-adab-fd2bfe44173c,0x1000,0x96000)/File(\EFI\Manjaro\grubx64.efi)
Boot0002* Onboard NIC(IPV4)     PciRoot(0x0)/Pci(0x1f,0x6)/MAC(3448ed430ac9,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* Onboard NIC(IPV6)     PciRoot(0x0)/Pci(0x1f,0x6)/MAC(3448ed430ac9,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0004* opensuse-secureboot   HD(1,GPT,ab568e8e-110e-475d-a4ab-1292b45f2f3b,0x800,0x100000)/File(\EFI\opensuse\shim.efi)
Boot0005* Linux Firmware Updater        HD(1,GPT,ab568e8e-110e-475d-a4ab-1292b45f2f3b,0x800,0x100000)/File(\EFI\opensuse\fwupdx64.efi)
Boot0006* neon  HD(1,GPT,7c436f48-2125-ed44-9ca1-80dd9ee0caa5,0x1000,0x96000)/File(\EFI\neon\shimx64.efi)
Boot0007* UEFI: KXG60ZNV256G NVMe KIOXIA 256GB, Partition 1     HD(1,GPT,62ff0235-310e-3b4d-afa9-bd5272e0114e,0x1000,0x96000)/File(\EFI\Boot\BootX64.efi)..B
O
Boot000A* UEFI: Samsung SSD 970 EVO Plus 500GB, Partition 1     HD(1,GPT,acfebff9-36c8-7e4b-9277-4ea2972f33bb,0x800,0x100000)/File(\EFI\Boot\BootX64.efi)..B
O

The fstab was from my testing partition. I ran update-grub from the testing installation. I do have a grub on each of my disks. I select which drive I want to boot from in BIOS (default is the Manjaro testing), and then the grub on that disk shows up.

[douglas-homepc EFI]# ls
boot Manjaro

Which leads to:

[douglas-homepc boot]# ls
bootx64.efi

[douglas-homepc Manjaro]# ls
grubx64.efi

22

So let’s review the hole picture…

  • You boot from the Samsung SSD 970 EVO Plus 500GB disk in UEFI that according to efibootmgr points the partition with UUID acfebff9-36c8-7e4b-9277-4ea2972f33bb, and according to lsblk, that corresponds to the /dev/nvme2n1p1 partition. And that partition is the EFI partition (ESP) of your testing disk. (So far so good)
  • As you are booting through the disk entry, that should use the /boot/bootx64.efi that lies in the partition. The file exists, but I can’t confirm that it’s the same file that /manjaro/grubx64.efi (You should check that).
  • If that file (bootx64.efi) is from your testing grub, it should read the content of the grub.cfg file that resides in your testing root partition in /boot/grub/grub.cfg. According to the output of your update-grub, the file is correctly being generated. That at least should enable you to see grub menu (if menu is not hidden). no other systems are been detected by update-grub, so it is possible that, by default, that menu is actually hidden. You can force the menu to be shown pressing esc -key during boot (after UEFI, but before kernel is booted).
  • If everything has gone fine until now, your kernel (I guess that 5.13) should boot.
  • From fstab we also see that the correct EFI partition should be mounted in /boot/efi

I think you actually haven’t said what happens when you try boot into your Testing install. We need details. Do you see grub menu at some point? Do you get to boot the kernel or what happens. As you can see this is a chain of events and I’m not sure at what point it’s broke.

Right now I think the problem may be in the bootx64.efi file. Check that it is the same file that grubx64.efi in the manjaro’s folder (with other name of course)

If the file it’s the same, you should reinstall grub from your Testing install:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck

And then copy the file from the manjaro folder in the ESP to the boot folder (changing the name).

Let’s see how this works…

PS: Reinstalling grub it’s going to add an UEFI entry for your Testing install…