Dual Boot Struggles

On a beautiful day, I was minding my own business, tinkering around on my computer and suddenly… Pitch black! Power outage. All electronics go dark, and I have to resort to pre-digital-era distractions until the power’s back. No big deal. Some time passes and the power is finally restored. Back in my comfy seat, ready to pick up my digital wandering where it got interrupted, I press the power button and eagerly wait. Few seconds later, I’m greeted with an unfamiliar boot menu. It definitely isn’t Grub, to my surprise. It’s the Windows bootloader¹… How? Why? Where did my beloved Arch installation go? And just like that, down the rabbit hole I dove in pursuit of a plausible explanation for this mystery. But before I take you down with me through this tortuous investigation, I think I need to lay down some foundational context first.

My Dual Boot Setup

I currently have a dual-boot setup with Windows and Arch Linux on my computer. Wait! Before you leave, let me explain. I don’t use Windows, and haven’t in many years now. When I first got my computer back in the day, it came with Windows installed. So when it was time for me to completely switch to Linux, I just created a second partition to host my new favorite OS and left the Windows partition there until I get around to backing up any data I might have left behind. Needless to say I never gotten to do that. This hasn’t really bothered me, to be honest, since the Windows partition is small and I have way more disk space than I need on the Linux partition. When I installed my current Linux distro², I had configured Grub to default to it, so I don’t even see the Windows entry most of the time and I’ve kind of forgotten it was there. To recap, I have Grub as my bootloader that supports both my Arch and Windows installations, and the Windows bootloader is completely out of the picture.

The Investigation

Now, back to the power outage. I was confused by the Windows bootloader and didn’t know where to go from there. Hitting the escape key took me to the BIOS menu. Nothing seemed to trigger Grub to load. Since I was on the BIOS menu, I went to check the boot order. That seemed fine, except the item for booting from the hard drive now had “Windows” in the name, instead of “Grub”. I was getting a bit stuck, and slowly coming to terms with the possibility that it might be a hardware failure.

I figured the boot partition got corrupted by the power outage, so I whipped out my trusty Linux flash drive and plugged it in. Once in the live environment, I tried to mount the boot partition and inspect it. Everything looked normal. I was able to mount all partitions and read their content. The problem had to come from somewhere else.

Next, I started poking around a little deeper in the BOIS menu, since I kept being taken there whenever I tried to skip the Windows bootloader. I noticed that Secure Boot was enabled despite having a vague memory of having to disable it in the past. I decided to disable it and see what happens. I rebooted the computer and to my disappointment, the Windows bootloader was drawn on the screen. “I have to keep digging!”, I thought to myself. I hit the escape key, ready to peel off even deeper layers of the BIOS menu, except it didn’t show up! I was instead taken to the Grub loader. Finally! I can boot my Arch installation once again. It seemed as if my computer reset the Secure Boot to “enabled” in the BIOS after the power outage. I have no idea why this would happen, though. Perhaps the motherboard battery was drained so the firmware got reset to its factory settings when the power came back? Unclear.

Now that I have a workaround to load my beloved Linux installation, I started troubleshooting the Grub configuration and EFI boot setup. Grub looked fine. I even reloaded the configuration, which had no noticeable effect. I used the efibootmgr command to examine the EFI boot configuration and noticed that the boot order was off indeed. The Windows Boot Manager was the one set to launch first, which explains the problem I was seeing. But when I tried to update the boot order with efibootmgr -o in order to promote the Grub loader to the top of the list, I kept getting a weird error that read:

1
2
3
4

Could not set BootOrder: Input/output error
error trace:
 efivarfs.c:441 efivarfs_set_variable(): writing to fd 5 failed: Input/output error
 lib.c:78 _efi_set_variable_mode(): ops->set_variable() failed: Input/output error

I did some research to understand what this was all about but without any conclusive findings. So, I decided to call it a win and not invest any more time on this issue, especially since I at least have a reasonable workaround. It’s just an extra keystroke³ during boot time. Furthermore, I have been planning to nuke the Windows partition for the longest time but haven’t had the chance to get to it. Maybe this is yet another reason to bump that up in my to-do list.

Wrap Up

Given where this problem started, i.e. not being able to boot my Arch installation at all, I’m glad I landed in a position where I can at least get to the Grub menu during boot time. However, I’ve got to admit that I’m still very curious about the root cause of the immutable EFI boot order. Have you had a similar issue before, or know what could be causing this? If so, please reach out on Mastodon or via email. I would love to hear your insights! If not, no big deal. Thanks for tuning in to my latest struggle in my Linux journey. Until next time, take care!