Tag: Windows

  • A Quick WSL Swap

    I have been using WSL and Ubuntu 22.04 a lot more in recent weeks. From virtual environments for Python development to the ability to use Podman to run container images, the tooling supports some of the work I do much better than Windows does.

    But Ubuntu 22.04 is old! I love the predictable LTS releases, but two years is an eternity in software, and I was looking forward to the 22.04 release.

    Upgrade or Fresh Start?

    I looked at a few options for upgrading my existing Ubuntu 22.04 WSL instance, but I really did not like what I read. The guidance basically suggested it was a “try at your own risk” scenario.

    I took a quick inventory of what was actually on my WSL image. As it turns out, not too much. Aside from some of my standard profile settings, I only have a few files that were not available in some of my Github repositories. Additionally, since you can have multiple instances of WSL running, the easiest solution I could find was to stand up a new 24.04 image and copy my settings and files over.

    Is that it?

    Shockingly, yes. Installing 24.04 is as simple as opening it in the Microsoft store and downloading it. Once that was done, I ran through the quick provisioning to setup the basics, and then copied my profile and file.

    I was able to utilize scp for most of the copying, although I also realized that I could copy files from Windows using the \\wsl.localhost paths. Either way, it didn’t take very long before I had Ubuntu 24.04 up and running.

    I still have 22.04 installed, and I haven’t deleted that image just yet. I figure I’ll keep it around for another month and, if I don’t have to turn it back on, I probably don’t need anything on it.

  • My Very Own Ship of Theseus

    A while back, I wrote a little about how the “Ship of Theseus” thought experiment has parallels to software design. What I did not realize is that I would end up running into a physical “Ship of Theseus” of my own.

    Just another day

    On a day where I woke up to stories of how a Crowdstrike update wreaked havoc with thousands of systems, I was overly content with my small home lab setup. No Crowdstrike installed, primarily Ubuntu nodes… Nothing to worry about, right?

    Confident that I was in the clear, I continued the process of cycling my Kubernetes nodes to use Ubuntu 24.04. I have been pretty methodical about this, just to make sure I am not going to run into anything odd. Having converted my non-production cluster last week, I started work on my internal cluster. I got the control plane nodes updated, but the first agent I tried was not spinning up correctly.

    Sometimes my server gets a little busy, and a quick reset helps clear some of the background work. So I reset… And it never booted again.

    What Happened?

    The server would boot to a certain point (right after the Thermal Calibration step), hang for about 10-15 minutes, and then report a drive array failure. Uh oh…

    I dug through some logs on the Integrated Lights Out system and did some Google sleuthing on the errors I was seeing. The conclusion I came to was that the on-board drive controller went kaput. At this point, I was dead in the water. And then I remembered I had another server…

    Complete Swap

    The other server was much lighter on spec: a single 8 core CPU, 64 GB of RAM, and nowhere near the disk space. Not to mention, with a failed drive controller, I wasn’t getting any data off of those RAID disks.

    But the servers themselves are both HP ProLiant DL380P Gen 8 servers. So I starting thinking, could I just transfer everything except the system board to the backup server?

    The short answer: Yes.

    I pulled all the RAM modules and installed them in the backup. I pulled both CPUs from the old server and installed them in the backup. I pulled all of the hard drives out and installed them in the backup. I even transferred both power backplanes so that I would have dual plugs.

    The Moment of Truth

    After all that was done, I plugged it back in and logged in to the backup server’s ILO. It started up, but pointed me to the RAID utilities, because one of the arrays needed rebuilt. A few hours later, the drives were rebuilt, and I restarted. Much to my shock, it booted up as if it were the old server.

    Is it a new server? or just a new system board in the old server? All I know is, it is running again.

    Now, however, I’m down on replacement parts, so I’m going to have to start thinking about either stocking up some replacements or looking in to a different lab setup.

  • WSL for Daily Use

    Windows Subsystem for Linux (WSL) lets me do what I used to do in college: have Windows and Linux on the same machine. In 1999, that mean dual booting. Hypervisors everywhere and increased computing power mean today, well, I just run a VM, without even knowing I’m running one.

    Docker Started It All

    When WSL first came out, I read up on the topic, but never really stepped into it in earnest. At the time, I had no real use for a Linux environment on my desktop. As my home lab grew and I dove into the world of Kubernetes, I started to use Linux systems more.

    With that, my familiarity with, and love of, the command line started to come back. Sure, I use Powershell a lot, but there’s nothing more nerdy than running headless Linux servers. What really threw me back into WSL was some of the ELT work I did at my previous company.

    Diving In

    It was much easier to get the various Python tools running in Linux, including things like the Anaconda virtual environment manager. At first, I was using Windows to clone and edit the files using VS Code. Through WSL, I accessed the files using the /mnt/ paths in Ubuntu to get to my drives.

    In some reading, I came across the guide for using VS Code with WSL. It describes how to use VS Code to connect to WSL as a remote computer and edit the files “remotely.” Which sounds weird because it’s just a VM, but it’s still technically remote.

    With VS Code setup to access remotely, I stopped using the /mnt/ folders and started cloning repositories within the WSL Ubuntu instance itself.

    Making It Pretty

    I am a huge fan of a pretty command line. I have been using Oh My Posh as an enhancement to Powershell and Powershell Core for some time. However, Oh My Posh is meant to be used for any shell, so I got to work on installing it in WSL.

    As it turns out, in this case, I did use the /mnt mount path in order to share my Oh My Posh settings file between my Windows profile and the WSL Ubuntu box. In this way, I have the same Oh My Posh settings, regardless of whether I’m using Windows Powershell/Powershell Core or WSL Ubuntu.

    Bringing It All Together

    How can I get to WSL quickly? Well, through Windows Terminal! Windows Terminal supports a number of different prompts, including the standard command prompt, Powershell, and Powershell Core. It also lets you start a WSL session via a Terminal Profile.

    This integration means my Windows Terminal is now my “go to” window for most tasks, whether in WSL or on my local box.