Gagabyte z690 Gaming X DDR4 M.2 not bootable


It seems I can’t use any of the following M.2 ssds as bootable drives on Gigabyte Z690 Gaming X DDR4 motherboard. All 3 drives were recognized by the bios but none could be used as bootable.

  1. Intel 600p Series 1TB
  2. Intel Optane 900p 280GB
  3. HP EX950 1TB

I could however boot with the following drives.

  1. Samsung SSD 970 PRO 512GB
  2. Samsung SSD 960 EVO 1TB

I am running the latest BIOS version F6. Anyone noticed similar problem ?


That’s pretty common across multiple motherboard brands. If the drive doesn’t contain an EFI parition there won’t be a boot option a lot of times. Once you install an OS to the drive it should work as expected.

All drives do have OS, some windows 10 others have Linux installed on them. I pulled them out of my existing Intel (Z370) and AMD (Zen1) systems. When I said system can’t boot from a certain drive I meant drive has bootable OS already installed on it.

Sorry, misunderstood. So the issue then is with your UEFI NVRAM boot entries. Some motherboards will add boot entries on the fly as they detect a new drives with an EFI system partition, while others will require you manually add an entry. You can try clearing CMOS to see if your board chooses to reset and readd the default boot entries (I know my Gigabyte X570 board doesn’t). If it does you’ll probably only have entries for Windows Boot Manager (\EFI\Microsoft\Boot\bootmgfw.efi) and the default bootloader (\EFI\Boot\bootx64.efi). If the linux distro bootloader is located at a different path you’ll need to manually add it to the NVRAM array.

So if clearing CMOS didn’t do the trick, or you need to add a non-default bootloader path then you need to use a tool such as efibootmgr. Almost all linux live ISOs will include this tool.

From the terminal run efibootmgr -v and it will list all current boot entries

And you can create new entries with -c

[Examples below assume OS drive is /dev/sda and the EFI system paritition (ESP) is first partition on the disk]

Windows Example

efibootmgr -c -d /dev/sda -p 1 -L "Windows Boot Manager" -l "\EFI\Microsoft\Boot\bootmgfw.efi"

Linux Example
efibootmgr -c -d /dev/sda -p 1 -L "Distro name for boot menu" -l "\EFI\<distro path>\grubx64.efi"

You can also delete and reorder the boot entries with the tool, but that’s not entirely necessary unless you just want to clean up the list.

I know that still doesn’t answer your question specific to your Z690 Gaming X board and I apologize if this is more than you wanted to know. I had a similar problem in the past and once I understood the basics of the UEFI boot process troubleshooting became a lot easier.

I just want my existing drives to work in the old systems so I did not touch the partition.So I looked at motherboard’s Nvme QVL and ordered new Samsung 980 pro 1TB which worked as boot drive.

Thanks for the help.

The efibootmgr tool doesn’t make changes to the partitions or data on the drives. All your boot entries are stored in NVRAM on the motherboard.

Glad you found a workaround.

1 Like

What’s with that explanation. Although it’s better than no input of course. What was meant was Just be simple about it…

When a drive is removed from a system and put into another it does not carry the NVRAM with it and thereby the bootloader from the motherboard it was removed from.

That’s what is causing the hassle on another system, it can be bypassed in several ways, for example using another bootloader that’s programmed to recognize more than simply what’s stored in NVRAM.

Almost any bootloader, would recognize the drives just fine. Like literally. Open browser, type download bootloader from sourceforge or whatever, use a bootable usb stick to boot from the new bootloader and if drives are bootable as op says, then the drives will magically appear and it’ll work just fine.

I could be overthinking the OPs problem but it sounds like he’s missing the boot options in UEFI setup or from the boot select menu (F12). If that’s the case then the UEFI boot process never makes it far enough to read the bootloaders from the EFI partition on “guest OS” drive. And the existing UEFI boot entry is probably tied to the original disk GUID. I could be wrong though.

And now that I’ve had to re-think the problem again, you’re probably right that I’m over complicating the solution. Got too caught up in trying to explain what was happening rather than providing a simple(r) solution. Just adding a generic boot entry that points to \EFI\BOOT\BOOTX64.EFI without specifying a disk would probably work with just about any drive you connect. Something like this
sudo efibootmgr -c -L "Default Boot" -l "\EFI\BOOT\BOOTX64.EFI"
should work… but I haven’t tested it.

It added the entry on my PC as:
PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0xa,0x0)/Pci(0x0,0x0)/Sata(0,65535,0)/File(\EFI\BOOT\BOOTX64.EFI). Which I think means it will look for the path on any NVMe or SATA drive(?)

Interesting. I’ve never used a bootable USB drive for that purpose of bootloading an attached OS drive before. Definitely a less technical and easier solution than modifying boot entries, but not a long term fix if you’re wanting to transplant a drive. I’ll see what projects are out there that I can use later. Thanks for the tip.

1 Like

Nothing wrong with overthinking it or providing solutions that are explained that well. Was just trying to simplify the steps to make it work for op.

Nope, don’t think you’re wrong about the GUID table being tied to the UEFI, probably works along those lines. Although should still be possible to boot from it using another bootloader.

The cool thing about using another bootloader than the defaults of whatever system is not just the attached usb, because you can copy it’s contents over to your system. EFI folder for example, to the internal drive. That way you won’t even need a usb for booting.

That’s how Hackintosh’s work, (example) otherwise you have to have a usb plugged in to make it boot as it has all the NVRAM virtualization going on in the usb drive.

Is it possible the m.2 are in Intel raid mode? Watch our raid on z690 mobo, toggle those Opti js off, then reboot and see if that works better?

Intel wants you to be in rapid storage mode bt default these days…

1 Like

Hi Wendell,

VDM used to be enabled in early BIOS versions of the motherboard which caused motherboard having trouble detecting ssds. It was fixed post F4 BIOS. In the latest BIOS (version F6) its disabled by default. I double checked it.


1 Like

you could boot to linux live usb and give us more info about the partition layout. Sounds like an efi/csm/legacy mode problem if it is not vdm.

A bootloader, one of the more known and better ones. Also works for EFI partitions. If op is sure drives are recognized by bios, although without providing boot entry then perhaps rEFInd could help. Otherwise resetting bios options to defaults could be an option.

Why run so many systems without a proper bootloader anyway? That could provide so much more than just booting.

Edit: fixed links.