In this post I’ll discuss my experience setting up dual boot on my desktop, why I did it, why I did it in the particular way I did it, and why you might want to as well. I’ll reveal only my broadest motive initially, that being that I wanted to have easy access to The Trifecta of modern popular desktop operating systems: MacOS, Windows, and a Linux distro.
Index
Setting the Scene
Most of my coding is done on a not-too-old Mac, a genuinely thoughtful parting gift from a past employer (who likely also didn’t want to have to reclaim the slightly-outdated hardware). I also have a modest gaming rig which runs Windows, and I occasionally code on it, though those sessions are usually reserved for experimentation with tools which are Windows-exclusive or for which the easiest (or only) instructions are written for Windows.
While the end goal of this project was to have easy access to The Trifecta, in some ways I already had it. For years i’ve had an old Samsung laptop, which got me through some early seasons of treeplanting, where isolation was one of the greatest difficulties when trying to stay productive throughout the entire planting season. We often didn’t have internet in the bush camps, but both distracting myself during the evenings and being able to connect to free wifi in the closest town on days off were crucial to my sanity. It has been many years since I tried setting up dual boot on that laptop, and my previous dual boot experience predates my career in software, so I was excited to see what I would understand differently about the process this time.
That laptop was not bought with hardiness in mind, nor was it manufactured with much future-proofing. Its usefulness had long since diminished, as its sluggish factory-installed Windows 7 was no longer viable due to updates not well suited to older hardware. As is appropriate for an elderly dear digital pet, I set out to extend its life, seeking to lighten its load with a more minimal OS. Linux Mint answered my call, and I once again had a somewhat usable machine. Still not usable for much due to its age and wear, but alive! That said, towards my current motive of having easy access to The Trifecta, I did not count this machine relic, since such a machine, unused for years, is generally not a great environment for playing around with new tools that might require high processing loads, or might assume you’re working with modern hardware (which for greatest compatibility they shouldn’t assume, but might). During experimentation it’s best to minimize the reasons for unexpected behaviour, and being able to trust your hardware (to a reasonable degree) goes a long way towards limiting the required scope of debugging.
Rejected Alternatives
There are other ways of achieving The Trifecta that would have been a bit simpler. First off, I could have used the Linux Mint distro set up on my beat up decade+ old laptop. I would have been able to achieve most coding tasks on it, though it would likely be a bit slow, especially if I was doing something graphics-intensive since it has no notable graphics card.
Another reasonable strategy would have been to purchase a new laptop with a Linux distro pre-installed, which would have given me mordern processing and RAM, but likely would have run into the same “lack of graphics card” problem, and would have increased the cost of the project from $100 (for the new SSD) to $600+ (for a low-end but decent new laptop). If there had been benefits to that extra cost over the alternatives, then it may have been the right call, but the reality was that I already had good hardware on my desktop PC, and all that was standing in the way of me using that hardware towards The Trifecta was a bit of time and effort (the calculated cost of which is especially low considering it’s time and effort I would have otherwise spent playing video games).
One last alternative that I could have explored in more depth would have been to create a Docker container running Linux. This would potentially be a great solution, as it would have no monetary cost, however it would introduce a new layer of complexity and a new set of points of failure. It would also change the experience to be more about learning Docker than more deeply exploring Linux. That might become a great separate project for building greater expertise in Docker, but it does not replace the pure Linux experience, at least for the scope of this project.
The Project
I won’t repeat all the steps to setting up dual boot here. Others have already given great instruction on how to set this up, and I want to Keep The Internet DRY. Of the many instructions I found on the web, you can find the one I followed most closely at It’s Foss. With that source in mind, let’s focus on what I did differently:
- I’m working with two SSDs rather than an HDD and an SSD. My primary drive is a 1TB M.2 SSD and for this project I decided to add a second similar drive.
- I chose to configure both the root and home on the new drive, which goes against the recommendation in the guide, but for good reason I’ll go into later.
- I didn’t make a backup of my data. This is not because I’m the rootinest tootinest cowboy in the west, but because my data habits meant no important data was at risk. If you’re planning a similar project, at least consider making backups.
- The guide assumes EFI partitions exist on your disks already. That was not the case for me and caused some headaches in the form of crashes during Ubuntu installation. Scouring over the guide, the EFI partition assumption was enough to prompt that I should add such a partition, but problems continued. It was only when I analyzed the screenshots and saw the EFI partition was first on the list of partitions that I was able to set my own drive up that way and resolve the issue.
That’s about it for project steps. One last piece of advice in terms of enacting the project would be to set yourself up for low-risk iteration. Setting up dual boot is relatively easy as far as tech projects go, but if you’ve never attempted it you’ll likely be exposed to things you’ve not had to do before, such as disk partitioning. If you can eliminate risks, it frees you up to iterate from a place of curiosity rather than caution. For me in the context of this project, the main risk I eliminated was having no important data on any of the drives involved. I may go into further detail about that data habit in another blog post in the future, but for now it suffices to say that reasonable worst-case failure would have resulted in needing to set up my Windows desktop environment again and install some games. Low stakes.
Why
“Why” is the most important part of this project. “Why” makes the difference between time on a single activity being wasted time or time well spent. My time well spent will, for you, result in wasted time if you don’t have a similar set of your own motivations internalized.
First I want to touch on a “Why” internal to The Project. I indicated that I deviated from the guide I was initially following, which recommended leaving root on one SSD and having your home directory on your HDD. I instead separated my drives so that one SSD contains contains my OS and storage for Windows, and the other contains my root and home for Ubuntu. I was conifdent this was the right decision for a few reasons. First, because my drives are near-identical SSDs, I didn’t have to consider the space-speed tradeoffs that the guide’s author was taking into account. More importantly, my chosen layout means that each drive is an encapsulation and isolation of an OS, and they can operate independently if one is removed or corrupted. This type of encapsulation is, in my opinion, important enough that even if I were working with an SSD and HDD, I may have chosen to keep this style of layout, relegating the OS I felt would be used less to the HDD to offset the annoyance of reduced speed.
For the project as a whole, there are a few layers to why I undertook it, spread broadly across the domains of education, entertainment, and utility.
The education and utility components to this project are closely linked. I’m not currently in a position where I have a strict need for a Linux OS, but many of the roles I find most interesting have some Linux component or benefit from Unix knowledge. Some of the Unix knowledge can as easily be gained while coding on a Mac, but there are limits to that interchangability, and there are still lots of projects out there that are built or optimized for Linux. So, there’s an education component of going through the dual boot process itself, but it also opens up more avenues of learning through access to Linux, and the utility of always having the right system for any job. The final utility component is that hardware upgrades intended for gaming benefit the coding environment, and vice versa.
Of course, I probably wouldn’t have done this project if I didn’t consider it at least a bit fun. Reading guides and documentation, learning about disk partitions for a practical purpose, watching installation progress bars and seeing all the messages about what’s going on in the background, that’s my jam! Well, one of my jams at least. I have many jams, including literal jam (apricot jam being an unlikely hero, and raspberry being great for peanut buttered toast or for Dark Helmet’s radar dishes).