I consider myself a casual Linux user. An old laptop here, a cloud server there, and a dash of Raspberry Pi. Lately, that old laptop running Linux has become my couch companion. It’s been working so well that I decided to refresh the dual‑boot setup on my desktop PC.

I booted into Ubuntu 22 and was told there was an update (as expected). I clicked update, and the update failed. I’m sure there was an upgrade path if I tried hard enough, but remember: I’m a casual Linux user. I know I’d try five things to get it working and the other four would have side effects until the end of time. It was time for a fresh install.

My setup has Windows on an NVMe drive and Ubuntu on a SATA SSD. Nice and easy. All I needed to do was boot the installer, tell it to install to the SSD, and we’d be good to go. I knew I’d probably have to reconfigure GRUB, but since I wasn’t touching the NVMe, I figured it would be simple.

A quick Google search said all I needed to do was install and run os-prober, then run update-grub. Nice and easy.

Turns out my setup was a bit… complex. I’m pretty sure my Windows EFI System Partition was on the SATA drive, not the NVMe. So when I told Ubuntu to wipe and set up the SATA drive using the defaults, I wiped that partition.

I’ve been in enough tech‑related damage‑control situations to know you should take a breath before making more changes. Frantically copy‑pasting commands from Google to try to solve the problem will likely make it worse. This is when I brought in Copilot. I’m sure I could have found someone who made the same mistake or pieced it together myself, but being able to give Copilot my specific setup and get the details I was looking for was a huge time saver.

My original plan was to create a new partition on my NVMe drive for the EFI partition. I found the commands to add the partition, but my NVMe drive already had two partitions taking up 100% of the space. If I wanted the EFI partition on the NVMe, I was going to have to adjust existing partitions. That felt risky — one wrong command could wipe everything — but I decided to go for it. The partitions were my Primary and my Recovery. I didn’t want to touch the Primary partition, so I ultimately decided to remove the Recovery partition. I took a breath, thought about what I was going to do, chatted with Copilot, double checked with a Google search, and decided to go for it. I deleted the Recovery partition and created a new EFI partition in its place.

After that, I made a handful of non‑critical mistakes. First, I didn’t set an ID on my EFI partition. This was new to me, and I want to learn more about why that matters, but the ID command seemed harmless. Second, I was pointing the bcdboot command at the bootable Windows USB I was using instead of my existing Windows partition. Luckily, those mistakes prevented the command from running and didn’t do any damage. Once those were corrected, I had my Windows EFI boot partition back! Yay, almost done.

Back in Ubuntu, I updated the GRUB bootloader and confirmed Windows was detected and had a boot record. Looking good. I rebooted, saw Windows as an option in GRUB, and booted into it. Still good. I rebooted again to go back to Ubuntu, but this time I didn’t get GRUB — it went straight into Windows. Maybe I just missed it, so I restarted again. No luck. Right back into Windows.

Time to bring Copilot back in. It turns out Windows will rewrite the boot order so that the Windows Boot Manager is the first entry. Another easy fix. Boot back into Ubuntu, verify the hypothesis (Windows did change the boot order), then set the EFI boot order to what I wanted.

A few reboot tests later, and I was done.

The ability to plan and execute instead of panic is a skill. I had never rebuilt the Windows bootloader before, and I didn’t have all the fdisk, diskpart, and efibootmgr commands memorized. But I was able to interpret them, look them up, and execute them when needed. In my opinion, the ability to plan and execute is what prevents a small problem from becoming a disaster.