I have a fairly complex storage setup. For the purposes of this question, the important part is that I have a SSD with GRUB in MBR, three partitions (the first of which is marked bootable), and a bunch of LUKS full-disk encrypted storage devices (both SSD and HDD) on a mixture of controllers (on-board and off-board).

The motherboard is an Asus M5A97 Pro, running UEFI BIOS revision 1604. OS is Debian Wheezy.

When I have all devices listed in the BIOS boot order and boot normally, the system loads GRUB just fine after a short delay and presents me with the GRUB menu. Perfect, except for potentially scanning a large number of drives and being potentially confusing in the BIOS setup. And that I generally like clean configurations.

If I remove from the boot order all devices except for the SSD that holds GRUB's first-stage loader in the MBR (the one I want to boot from, and which is hooked up to the on-board SATA controller), and reboot, I am presented with the following message:

Reboot and Select proper Boot device
or Insert Boot Media in selected Boot device and press a key_

where _ represents the blinking cursor. If at this point I simply press a key (spacebar, say), the message is repeated after a blank line with identical behavior:

Reboot and Select proper Boot device
or Insert Boot Media in selected Boot device and press a key

Reboot and Select proper Boot device
or Insert Boot Media in selected Boot device and press a key_

If I force the system to try to boot from the SSD, I get the same error behavior.

If I add all devices back into the boot device order, then the system boots normally.

I have confirmed that out of all devices, only the SSD I want to use as boot device has the string GRUB within the first 512 bytes stored. I have confirmed the partition table layout on that one using fdisk -l.

All other devices are used as full-disk LUKS containers and don't even contain a valid MBR, much less any valid boot code. None of the storage devices have boot device (case insensitive) within the first 16 KiB, so it's not a LUKS thing. Google also indicates that the message is fairly common, and judging by the hits, it's from the BIOS, not anything related to Linux.

I have run grub-mkdevicemap, the output of which says (hd0) is the SSD I want to boot from, and reinstalled GRUB (I think I did this using dpkg-reconfigure grub-pc, but I'm not positive about that).

What's going on here? Why won't the BIOS, when I explicitly tell it to, boot from the one device it's pretty clearly booting from in the end? How can I convince it to boot from only this one SSD without having to list everything in the boot order?


This is probably just a design flaw with the firmware. Since it's UEFI, it likely expects (requires) that a GPT disk with an EFI bootloader be present in the boot menu (probably the first entry in the boot menu even).

I'm just guessing here, but whoever designed the firmware probably didn't expect that you'd be using it in UEFI mode if the only bootable device was a (legacy BIOS) MBR disk. After all, Windows won't boot that way, and Windows is the only operating system that matters, right? ;-)

Try this first: make sure that the grub partition is flagged "active". I always seem to forget that step personally (because UEFI doesn't care).

Barring that, try adding just one other UEFI boot entry to the menu and see if it solves your problem. If it does, then this is the issue you're facing. You would then either have to convert the GRUB disk to GPT, or put the firmware into Legacy BIOS mode. Just bear in mind that Windows will refuse to boot from a GPT disk on a legacy BIOS. Sounds like you don't much care.

And FYI... UEFI is not "better" for the purposes of this argument, so don't feel like you're losing anything by switching back to "legacy BIOS" mode. All it's doing is changing the way drives are handled by the firmware, and the way Windows boots (because Linux doesn't care).

  • I have no UEFI boot entries at all at present. It's a single MBR SSD and a bunch of unbootable "garbage" disks (thanks to LUKS). And if this was the problem, wouldn't it behave the same way whether I have a single device or all devices listed in the boot order? – a CVn Nov 13 '15 at 20:35
  • I've never used LUKS so I can't speak to how it works. But yes, if it is the flaw I'm talking about, it would behave the same if you only had 1 entry or all of them (as long as there was at least one). If it ONLY works with ALL of the entries, then something else is going on. – Wes Sayeed Nov 13 '15 at 20:47
  • It works fine with all entries in the boot list. It doesn't work with only the one bootable device in the list. It doesn't work when I try to force booting from the one device that is actually bootable. That's the weird part that I just don't understand; it should either be able to boot or not be able to boot, it shouldn't need all the non-bootable devices listed in order to be able to boot from the bootable device. I looked through the BIOS settings, but unfortunately didn't find anything about switching between UEFI and Legacy BIOS mode... – a CVn Nov 13 '15 at 21:03
  • In firmware setup there should be at least 2 options for boot settings present - 1)enable/disable Secure Boot and 2)enable/disable CSM (e.g. BIOS emulation), eventually there should be a way of setting boot order list - CSM entries first or UEFI entries first. – snayob Nov 13 '15 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.