Yesterday, a good chunk of my day went into installing Linux. It was supposed to be a quick task: install it and be done. However, a few mistakes here and there cost me hours of time, and I was quite upset. Writing this blog post is a means of catharsis. At least I’ll have something to talk about from the whole experience.
I recently quit working at Scale and was enjoying a few weeks of downtime between jobs. In preparation for resuming work, I had an itch to create an environment dedicated to work. Specifically, I wanted to turn my gaming desktop into a coding workstation by dual booting Linux on the machine. That way, there was some compartmentalization between work and play, since I would have to explicitly reboot the machine to change operating systems. Dual booting was nothing new, so I generally knew the process.
I took a random flash drive, used Rufus to put Ubuntu on the stick. Then booting from the flash drive, I went through the Ubuntu installation wizard. My first mistake was enabling ZFS. The wizard explicitly marked it was an experimental feature, but I figured nothing much could go wrong. The installation completed without complaint.
Although the Ubuntu machine was ready, I needed the bootloader find the hard
drive that contained Windows in order to enable dual-booting. Googling yielded
the suggestion that I use
os-prober to scan for other operating systems.
However, the command failed on a fresh Ubuntu install.
$ sudo os-prober device-mapper: reload ioctl on osprober-linux-sda2 failed: Device or resource busy Command failed.
More Googling uncovered that the culprit was a bug with ZFS. Realizing that I was at a dead end, I decided to start fresh.
With the same flash drive, I waited through the same installation wizard. This
time, I was careful not to enable any experimental features. With Ubuntu
reinstalled, I still had the issue that the bootloader could not detect Windows,
os-prober worked this time. My spirits fell quickly though, as
couldn’t find anything. Back to Googling.
$ sudo os-prober <imagine nothing here>
The process of searching up causes to the bootloader behavior was generally a haze. One irrelevant search result followed the other. In the back of my mind, I knew that Windows 10 used UEFI, but I had no idea about its deeper implications. That knowledge, however, did give me a lingering suspicion that it could be the cause of some issues. Eventually, I learned from Googling that for operating systems to recognize each other, they either need to both be using UEFI or neither should be using UEFI. Thus the Ubuntu machine not being a UEFI installation could explain the bootloader issues. My spirits dropped when I realized that the fix entailed restarting the whole process from scratch.
It turns out that Rufus had an option to write to a flash drive in UEFI mode. By default it was off, and it was how I wrote to the flash drive originally. With my certainty rising, I rewrote the flash drive and waited anxiously for Rufus to do its work. I booted from the flash drive one last time and saw this.
It was a sign that I was on the right track. The original Ubuntu installation was definitely not using UEFI. I disabled legacy mode in my BIOs and waited through the installation process for the third time. The difference was night and day. The bootloader automatically detected Windows, and I didn’t have to do any work after installation completed. I was done. It would have been so easy had I used the correct setting at the beginning.
So what have we learned from this whole ordeal?