0

I'm obviously missing something in how BIOS determines which disk to boot with UEFI. I have a dual boot setup with two SSD disks. Disk0 has Arch, Disk1 has Windows10. Ordinarily I use systemd boot on Disk0 to boot Arch or Windows.

I needed to upgrade Windows10 and it fails in dual boot, so I disconnected Disk0. The system didn't have any trouble booting into Windows, so I finished the upgrade and restarted a couple of times just to make sure the upgrade had completed.

I then put Disk0 back in but Windows10 loads directly and I don't have a UEFI boot option in BIOS for Arch on Disk0 any longer.

Removing Disk1 still doesn't allow booting from Disk0.

How does BIOS detect a valid UEFI partition and why wouldn't it now detect the partition on Disk0?

0

Duplicate question. Anyway

Either method will work, but there are some caveats and differences:

  • Some EFIs "helpfully" remove inaccessible boot loaders from their NVRAM lists of boot loaders. If yours is one of those, and if you put a boot loader that's to be launched directly from the firmware on your removable disk, its entry will disappear if you ever boot the computer with the external disk unplugged. This is obviously undesirable, but it may not be important if you only launch boot loaders stored on that disk from another boot program stored on the first disk (like GRUB or rEFInd).
  • If you want to move the external disk between computers and boot it on multiple computers, you'll want to have an ESP on the external disk. In this case, I'd recommend storing your boot loader, or at least a copy of it, as EFI/BOOT/bootx64.efi on the external ESP. This way, the target computer will probably pick it up and give you the option of booting it from its built-in boot manager. (This trick can also be helpful in overcoming the problem identified in the previous bullet point.)
  • If you move the drive around and manage to boot it on a secondary computer even without an ESP (as can be done with rEFInd, for example), an /etc/fstab entry pointing to the ESP on the primary computer will probably not work. This will most likely be a harmless failure, but you may see complaints about the missing partition. The worst-case scenario might be if it does work (say, because you refer to the ESP by device filename, like /dev/sda1) and if you run a software update that tries to update GRUB; that could cause severe problems on the secondary computer.

Overall, I'd say you should consider how you intend to use the disk (always plugged into one computer, plugged in sometimes but never used on another machine, or as a roaming OS installation used on multiple machines) and what sort of boot loader configuration you want (a single GRUB or the like that boots everything, a boot manager that boots a separate boot loader for each OS or distribution, using the machine's built-in boot manager to launch a boot loader for each OS, etc.). Once you've decided on these factors, the advantages and disadvantages of using a separate ESP on the external disk will become clearer. In many cases the differences will be small to nonexistent.

Source: link

  • Sorry, all my disks are internal not external – ash May 18 '17 at 3:23
0

Discovered that BIOS doesn't detect EFI partitions on disk but instead are told about them. UEFI stores boot manager information in NVRAM. In my case Windows overwrote the systemd-boot NVRAM entry with one of its own even though it already had one. I used the arch installation media and ran 'efibootmgr' to delete the duplicate Windows10 entry and add an entry for systemd-boot/arch as per this wiki https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#efibootmgr

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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