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]
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.
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.
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.
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.
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.