Laptop no longer seems to be booting to the EFI partition - Dual boot of Arch alongside Win 10

Question

A while ago I installed Arch Linux alongside Windows 10 on my Dell XPS15, everything seemed to be working fine, however recently my laptop is suddenly booting straight into Windows and skipping the systemd-boot menu.

I created a bootable Arch USB and looked at the EFI and Arch partitions and everything seemed unchanged, I've tried looking a boot sequence options in BIOS settings and the only option is the SSD as a whole and i cannot select specific partitions to boot to.

Does anyone know what could have caused this sudden change? Has anyone had a similar problem occur, and does anyone know how I can fix this?

Here's a screenshot of my windows disk manager, I've noticed that the Windows partition is set with the Boot flag, I'm not sure if it is meant to be like this? Does it help at all?

Answer 1

I figured out the issue, I had selected default EFI loader in the systemd-boot menu and for some reason that had changed the efi file that booting to my SSD loads. I fixed it with the following steps:

1. Booted to Arch on a Bootable USB
2. Mounted my EFI partition
3. Used bootctl to see each of the current boot entries
   • this confirmed what I had thought: there was an entry for my SSD that was set to load my windows EFI file
4. Booted back to the menu on the bootable Arch USB
5. Selected the UEFI Shell v2
6. Used bcfg to add a new boot entry pointing to my systemd-boot efi file
   • (Deets on how to do this here: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface)
7. Set the new boot entry to the top of the boot sequence in my BIOS.

Done.

Answer 2

Background Information

I've tried looking a boot sequence options in BIOS settings and the only option is the SSD as a whole and i cannot select specific partitions to boot to.

You're operating under a misapprehension -- you seem to think that EFI boots to partitions, but this isn't really so. Under EFI, boot entries are stored in NVRAM, and these entries point to files. You can have one, two, ten, a hundred, or more boot programs on a single partition, or spread across as many partitions as you like. If you think of an EFI as booting a disk or a partition, you're likely to draw incorrect conclusions and try to fix things in completely inappropriate ways.

One partial exception to this rule is the fallback filename, EFI/BOOT/bootx64.efi (or variants for other CPU types). This is the filename that the EFI will try to boot if it finds nothing else available. It was originally meant to be used on removable media, but modern EFIs (almost?) always recognize it on hard disks' ESPs, too. This can be a useful tool for working around boot problems, such as if your firmware forgets its regular boot entries -- as seems to have happened with you. Note also that many EFIs treat the Windows boot loader, EFI/Microsoft/Boot/bootmgfw.efi, as a fallback filename. This can keep Windows booting even when the computer's firmware settings have been messed up -- but of course this does nothing to help Linux users.

I've noticed that the Windows partition is set with the Boot flag, I'm not sure if it is meant to be like this?

AFAIK, Windows ignores the "boot flag" on GPT disks. Also, beware that the "boot flag" reported by the Windows tool whose screen shot you've shown and the "boot flag" reported by parted and GParted in Linux are entirely different things! (In the Linux tools, this "flag" is synonymous with an ESP's type code on GPT disks.)

A More Direct Answer

Briefly, you're encountering what I call a boot coup. See this page of mine for more on this topic. You might be able to correct it in Windows by using the EasyUEFI tool to restore your Arch Linux entry to the top of the boot order; however, you say that your firmware's boot manager is showing you no OS-specific entries. (The whole-disk entry you mention might launch a fallback boot loader or might boot the system in BIOS/CSM/legacy mode; I can't be sure which without seeing the entry and perhaps trying it to see what happens when it's used.) This suggests to me that your boot coup has been caused by the firmware "forgetting" its NVRAM entries entirely. This could happen because of a bug in an OS, a bug in the firmware, user error, failing hardware, etc. The best solution is to create a fresh EFI NVRAM entry using efibootmgr. See the efibootmgr entry in the Arch wiki for more on this subject. In brief, you'd use a command like this (taken from the Arch wiki):

# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager"

You'd need to change the disk ID, partition number, filename, and label for your own system. You can type this command in any emergency Linux system booted in EFI mode; or if you can get your main installation to boot (for instance, by using my rEFInd boot manager on a removable disk), you can type it from your main installation. Alternatively, you could use EasyUEFI to create an equivalent entry.

If your system regularly forgets its NVRAM entries, it might be better to use a fallback filename; however, since you're dual-booting Linux and Windows, that can be awkward -- if your firmware favors the Windows boot loader entry over the official fallback filename, the only way to get it to work reliably will be to "hijack" the Windows boot loader, putting your Linux boot loader or boot manager in its place and then launching the Windows tool from another location. Windows might eventually re-install its own boot loader to that location, putting you back where you are now. That's one of the reasons I strongly advise people to return defective computers that forget or ignore their NVRAM boot entries to the store for a refund whenever that's possible. Unfortunately, it often isn't possible, since this defect is often discovered months after the computer is bought.