Windows-Linux Dual Boot Achieved

Estimated reading time at 200 wpm: 8 minutes

The transition to a Linux-based dual-boot system is often marketed as a streamlined experience. However, when high-performance hardware meets specialised networking requirements, the path quickly shifts from a standard installation to a deep-dive into kernel modules and system architecture. This is a technical post-mortem of a transition involving an RTX 3080, an Archer TXE70UH Wi-Fi adapter, and the pursuit of a protected dual-boot environment that leaves the Windows side untouched. Yes that’s my higher powered desktop. After the dedicated installation of BigLinux on the old laptop last month, I had to try and create a dual boot for my good desktop. It had to be dual boot because I had to keep Windows 11.

Now dual booting Linux is no walk in the park from my experience and many others over the years.

The Objective: An Invisible Dual Boot

The primary goal was a “Protected Dual Boot“. This means stopping Windows from seeing Linux and having a panic attack. In typical configurations, a Linux installer might overwrite or significantly alter the Windows Boot Manager, creating a fragile dependency. Windows would see this and start bullying. The achievement here was maintaining physical and logical separation. By ensuring the Linux EFI partition remained distinct, the Windows installation remained entirely unaware of the second OS. The Linux bootloader (GRUB) acts as a non-invasive gatekeeper, providing a link to Windows without modifying its core boot files.

The success of the dual-boot strategy rested on a meticulous collaboration between the human (me) and AI, when approaching disk partitioning, drive identification and all other wrestling matches with the technology. . Rather than allowing the installer to manage the drive automatically—a common source of accidental data loss or bootloader corruption—the storage landscape was mapped with manual precision.

Surgical Partitioning and Installation

The process began within the Windows environment, using the Disk Management utility. This would have been used to create a specific block of “Unallocated Space” at the end of the physical drive. However, a 186 GB partition was found lying there, that was more than sufficient for Linux. Balena Etcher was used as the Linux installer, to deposit BigLinux in a clear, vacant “landing zone”.

During the Linux installation phase, the “Manual Partitioning” or “Something Else” option was selected. This allowed for the explicit identification of the unallocated block. The space was then formatted to ext4 and assigned the root mount point (/). Crucially, the installer was directed to use a specific, newly created EFI partition for the bootloader, rather than sharing the existing Windows EFI partition. This siloing ensured that Linux had its own “home” and its own boot instructions, preventing the “shared brain” syndrome where one OS update can cripple the other. This level of care at the partitioning stage was the essential insurance policy that allowed the experiment to proceed without risking the existing Windows environment.

Bottleneck I: The Networking Dead Zone

The journey began with a significant hardware hurdle. Modern high-performance Wi-Fi dongles, specifically the Archer TXE70UH (rtl8852cu), rarely have out-of-the-box support in the standard Linux kernel. This created a “Dead Zone”: a system with no internet access and, therefore, no ability to download the drivers needed to fix itself.

The Rabbit Hole: The Tethering Impasse

The first logical pivot to escape the “dead zone” was USB Tethering via a mobile device. The intent was to use the smartphone as a temporary network bridge to pull down essential build tools. However, this attempt spiralled into a technical rabbit hole.

Despite the device being physically connected, the Linux kernel failed to initialise a network interface. We encountered a fundamental conflict between the modern kernel’s security modules and the RNDIS (Remote Network Driver Interface Specification) protocols typically used by mobile devices. In this specific environment, the system viewed the tethering attempt as an unrecognised USB peripheral rather than a network gateway. Standard troubleshooting—switching cables, toggling developer modes, and searching for legacy “Easy Tether” workarounds—proved fruitless. The system remained an island, successfully blocking the very “bridge” designed to save it.

The Human Element: Creative Intuition and the Manual Build

Technical documentation often glosses over the moment of decision-making. When standard procedures failed and the “dead zone” seemed absolute, it was human creativity namely me – who refused to accept a failed project. Rather than following the rigid path of manufacturer-supported hardware or waiting for an automated fix that wasn’t coming, the manual build approach was suggested. This pivot—moving from seeking a pre-packaged driver to manually compiling source code—was the creative spark that allowed the project to proceed. It transformed the hardware from a plastic brick into a software challenge.

The Breakthrough: The “Crazy” Archer Build

The solution required a manual build approach. The rtl8852cu driver was sourced externally and transferred via physical media. The process involved:

1. Manual Compilation: Treating the Wi-Fi driver as a software project, compiling the source code directly against the system’s kernel.
2. The Kernel Update Conflict: A major system update immediately invalidated this work. In Linux, custom drivers are often tied to specific kernel versions; when the system’s “brain” updated, the driver was rendered obsolete.
3. The DKMS Victory: To solve this permanently, the driver was integrated via DKMS (Dynamic Kernel Module Support). This framework ensures that every time the kernel updates, the system automatically rebuilds the Archer driver, making the Wi-Fi “update-proof”. That was not easy. See below.

The Breakthrough: The Hard-Won DKMS Victory

The solution required a manual build approach, but the road to a permanent fix was fraught with secondary obstacles. The rtl8852cu driver was sourced externally and transferred via physical media, but simply running an install script was not enough.

The first attempt at installation was met with a frustrating security hurdle: “invisible” password prompts in the terminal. Because Linux does not show asterisks or characters during sudo password entry, it created a moment of doubt—was the system frozen or just waiting? Once past this, the initial manual compilation worked, but it was fragile. A major system update immediately upgraded the kernel, effectively “orphaning” the custom driver and killing the internet connection once again.

To achieve a true “DKMS Victory”, the driver had to be registered with the DKMS (Dynamic Kernel Module Support) framework. This was the most difficult technical hurdle. It required:

1. Identifying the Kernel Headers: The system needed specific “header” files to rebuild the driver, which were missing. We had to use the hard-won internet connection to pull these down before the driver broke again.
2. The Manual Registration: We bypassed the standard install scripts and used sudo dkms add . to force the system to acknowledge the source code.
3. The Final Handshake: The command sudo dkms install rtl8852cu/20240510 was the final blow. It forced the system to compile the driver in a way that is “update-proof”.

The victory was confirmed when the Archer’s blue LED began to blink during a reboot—a signal that the driver was now an integrated part of the system’s “brain” rather than a temporary patch.

Bottleneck II: High-Resolution Scaling

With an RTX 3080 driving the display, the initial desktop environment suffered from “microscopic” UI elements. At a 4K or high-resolution baseline, standard 100% scaling rendered text in applications like Gmail nearly unreadable.

• The Fix: A shift to 125%–150% Global Scaling. This required a session reset to ensure all applications, including Chromium-based browsers like Microsoft Edge, correctly inherited the new DPI settings.

Environmental Polish: Language and Credentials

The final phase focused on transforming the installation into a daily driver:

• Purging “Ghost” Locales: An initial install with mixed language remnants was strictly transitioned to UK English (en_GB) across the UI, date formats, and system messages.
• Edge & RoboForm: Microsoft Edge was installed via the Arch User Repository (AUR) to bypass terminal-based password entry issues. RoboForm was then forced into “Standalone Mode” to operate without a native Linux desktop application, ensuring seamless credential synchronising with existing Windows and mobile setups.

Conclusion: A Triumph of Method and Persistence

What began as a frustrating series of technical failures—a networking “dead zone,” unrecognised peripherals, and invisible terminal hurdles—ultimately concluded in a significant personal and technical victory. This journey underscores that the true power of a custom computing environment is found not in the automated scripts, but in the human persistence required to see a method through to its conclusion.

By refusing the “nuclear option” of a total system reinstall, and instead methodically peeling back the layers of kernel headers and module registrations, the system was not merely repaired; it was mastered. The result is a high-performance workstation that stands as a testament to the value of creative problem-solving. This project proves that even when the software resists and the documentation falls short, a combination of disciplined methodology and creative intuition can forge a stable, protected, and update-proof environment that utilises every ounce of the RTX 3080’s power and the Archer’s speed.