Packetize Me No Packet Left Behind

GPD MicroPC: Installing NixOS

Steps taken to install NixOS after partitioning and reinstalling Windows on the GPD MicroPC.

Note: Paritioning was performed before reinstalling Windows in order to ensure a large EFI partition was created, as this will be used by both Windows and NixOS.


The graphical NixOS installer will boot successfully without setting nomodeline. Guides I found elsewhere on booting Linux required this setting, but it actually prevented X from starting for me; CLI works either way.


The display will be rotated 90 degrees when booted. Deal with this for a few minutes and then make your life easier by updating KDE’s display settings to correct for this rotation.

Follow the normal NixOS install process, but note the specific configurations called out below. I use ZFS on LUKS, but there’s nothing unique to the MicroPC. If you’re dual booting with Windows as in my previous post, remember that /boot will be same as the EFI partition used by Windows.

For reference, my MicroPC’s configuration is available on Github.

Getting the keyboard to work at boot

After installing I found that I was unable to enter my LUKS passphrase without attaching a USB keyboard. After entering the passphrase via an external keyboard, everything worked fine.

In order to make the keyboard available during Stage 1 boot, where the LUKS passphrase is entered, the battery kernel module must be available. Add it by appending "battery" to boot.initrd.availableKernelModules in the nix configuration. This makes no sense to me, but when trying to find a solution I found the battery module requirement noted in Josh Skidmore’s GPD MicroPC Arch Guide.

Rotating the display

Add the following to your configuration in order to avoid having your display rotated by 90 degrees when logging on.

services.xserver.monitorSection = ''
  Option "Rotate" "right"

Power management

Enable thermald and TLP.

services.thermald.enable = true;
services.tlp.enable = true;

GPD MicroPC: Replacing the SSD and Installing Windows

The GPD MicroPC comes with Windows 10 Pro, which is great - if you like using Windows. I have uses for a Windows PC, namely amateur radio software as used to program my DMR radio, but prefer to live in Linux-land. Either way, a downside to this device (as I purchased it) is the tiny 128GB SSD that Windows comes installed on. In order to dual boot it and feel comfortable in either OS, I really needed more capacity.

Create Windows 10 install media

Download and install the Windows 10 media creation tool. Use it to create a bootable USB drive with the Windows installer. Note: if you visit this link from a browser not detected as running on Windows it will redirect you to download a Windows 10 Disc Image (ISO file). Don’t do this; open the link from within Windows and use the tool.


  • If you visit the download page from a browser not detected as running on Windows it will redirect you to download a Windows 10 Disc Image (ISO file); don’t do this. Open the link from within Windows and use the tool to create the install media.
  • Don’t download the Windows 10 installer ISO. This works well for every other install I’ve done, but didn’t play well with the MicroPC; when using the standard installer I was prompted to insert a disk with drivers – but this didn’t work out for me when I used a driver bundle from GPD’s site. (It’s totally possible that I grabbed the wrong bundle – they have many and they are not well labeled)
  • Don’t create a recovery drive if you want to modify the EFI partition; reinstalling via the recovery drive will work great if you’re just wanting to replace your SSD with a larger disk, but if you’re intending to repartition it you’re out of luck. The main windows partition will be automatically grown to fill disk space but recovery and EFI partitions will be as they were with the original install. If you’re just upgrading to a larger SSD recovery media is fine; if you’re doing more, use the media creation tool.

Back up necessary drivers

Obtain and run Double Driver to back up drivers currently in use. These can be added to the support folder of the win10 install media once it’s created.

Replace the SSD

The GPD MicroPC uses a M2 2242 SSD, so obtain one.

  1. Remove the five small Phillips-head screws at the bottom of the case. There is one screw at each corner and one centered at the front of the case, beneath the GPD logo. The fifth screw for my MicroPC was hidden under a quality control label.
  2. Split the case open. I found that starting at the corner with the LAN port and working my way toward the serial port was the easiest way to do this.
  3. Remove the factory SSD and install your shiny new one.
  4. Snap the case back together.

Format (skip if sticking to a Windows-only install)

  1. Boot up your live system of choice; your preferred OS probably has all of the tools you need to do this. I booted the NixOS installer.
  2. Create an EFI partition; Windows and your alternate OS of choice will share this. Windows will create a small partition of ~100MiB, I created a 512MiB partition to accommodate NixOS as well.
  3. Create a temporary placeholder partition to fill out space for windows. I gave Windows 100GiB.
  4. Create partitions as desired for your planned alternate-OS install; I created an 8GiB swap partition at the end of the disk and a second partition for the rest of my data with the remaining space.
  5. Remove the placeholder Windows partition; Windows will create what it needs during the install process.

Install Windows

Not much to say here; insert the install media that you’ve created and boot from it. If it doesn’t boot automatically, press F7 at startup and select your media as the boot device.

Note: your screen is going to be in portrait mode, so you’ll be twisting your neck. Maybe HDMI works at this point, but I didn’t test. If you stumble on this post (or I need to do this again in the future), give it a try (and let me know so that I can update this!)

Install third party drivers

Open double driver and reinstall drivers previously backed up.


That’s it. That’s the post. Now you can remove all of the extra junk included with Windows and install an alternate OS on the partitions that you left when formatting, if that’s your kind of thing.

Stop deadnaming me, Samba!

A brief follow-up to Stop deadnaming me, Linux!

One thing I do is run a Linux VM on my MacOS laptop. I generally want these to be isolated, but to have a single folder available to share between them. To do this I previously created a samba share in the VM which I mount as necessary in MacOS. Changing my username broke this, but it was easy to fix. The VM I’m using is running Fedora 30, samba is from the fedora repository; if you’re on a different distribution or using a different package you may have a slightly different experience – these are really just notes-to-self, but I hope you’re able to benefit from them if you stumbled upon this.

Fix samba users

  1. Create a new samba user. As root, run smbpasswd -a [name] to create a new samba user for your username. This should match your system username, but when prompted to set a password you can use any password you like.
  2. Banish your deadname samba user. As root, run smbpasswd -x [deadname]. You should see a response like this:

Failed to find a Unix account for deadname Deleted user deadname

Update the samba share configuration

Edit your samba share configuration; for me, this was located in /etc/samba/smb.conf:

        comment = Shared with Host
        valid users=deadname
        write list=deadname
        create mask=0770
        Force create mode=0770
        force group=deadname

Using your favorite text editor or sed1, replace deadname with name and restart samba (systemctl restart smb as root).

You’re done!

  1. Sed oneliner: sed -i 's/deadname/name/' /etc/samba/smb.conf – if you’re not using GNU sed, you’ll need to specify an extension after -i for creation of a backup file when performing inline edits. [return]

Stop deadnaming me, Linux!

If you’ve changed your name for any reason, you’ll know that doing so can be an arduous process. I’m currently working through this myself and was getting tired of being greeted by my old name (deadname) every time I opened up my laptop. Here are my notes on addressing this; if you’re on Windows, MacOS, or anything other than Linux, these instructions aren’t likely to help. I followed this process on Fedora, but I believe it will be applicable on most other distributions. When in doubt, consult the man page for the command you’re about to run.

Updating your account

Log in as root, or a user other than your normal account which has the ability to execute usermod as root (e.g. via sudo). You’ll want to update your username while not actively using it; things might be OK, but they may not. Besides, if you’re going through this: do you want to log in as deadname again? I logged in as root from a console, opened via CTRL+ALT+F2, but you should be able to do this via your display manager.

Update your username

If you’re like me, you may have used your deadname as your username. Or maybe you’re adopting a new last name, and your old one was reflected in your username. Either way, you can easily change your logon name.

Replacing [name] with your desired username and [deadname] with the username that you previously used, execute the following as root:

usermod -l [name] -d /home/[name] -m [deadname]

Reboot for good measure; good riddance deadname!

Upon reboot, be greeted with your deadname. Shit.

Update your full name

Thanks for deadnaming me again, computer. It’s OK, I just forgot that changing my username wouldn’t update the full name associated with my account. Let’s do that now:

usermod -c "[Display Name]" [name]

Learn from my mistakes

Don’t be greeted by your deadname even one more time. Rather than using the previous two commands, combine them:

usermod -l [name] -c "[Display Name]" -d "/home/[name]" -m [deadname]

More headaches

If you relied on symlinks to /home/deadname, congratulations: you broke them. Let’s fix that.

You can use find to identify all of the symlinks in your home directory which point to your old (deadname) home directory. I tee’d this to a log so that I could review it easily:

find /home/[name] -lname '/home/[deadname]*' -ls

What to do from here? Honestly, I fixed these manually. I had a fairly small number of links to fix and, although I believe that it could be coerced into doing this for me, I’m unfamiliar with the finer points of find. Not liking the way I’m leaving this, and knowing that I will need to repeat this process for other systems, I intend to update this post when I come up with a proper solution. Sorry for leaving you hanging here.

Follow-up posts:

The Humble Homelab

It’s a common joke that when something is prefixed with “humble”, it often isn’t. My homelab isn’t a rack full of shiny new equipment, but it isn’t a couple of Raspberry Pis either. My lab lives in a cabinet nestled in to a corner of my home office, primarily to keep it from being used as a cat warmer.

What’s in my rack?

An Ubiquiti router and switch provide network connectivity. Power in the rack is distributed by an APC PDU, backed by an APC UPS.

The heart of the lab is a MiniITX tower (“virt1”) living on a shelf in the rack, rather than in a proper rackmount chassis. It was available at the time, and works pretty well. One day I’d like to move this into another chassis. virt1 has a Xeon D-1540 CPU, 64GB of memory, a ~500GB M2 SSD, and 8 4TB HDDs.

virt1 runs ESXi; I’m interested in moving this to something else, but like many small organizations my production environment and lab environment are not cleanly separated. Yes, I feel shame for this. But you didn’t really think I was going to dedicate 32TB of storage to a lab, did you?


Now that you know the truth, let’s call virt1 what it is: homeprod. It will host lab VMs too, but this post is about the “production” systems that I use at home. At home, we test in prod all the time. I’m going to list it all, because I want to be a

The homeprod network consists of:

  • virt1: VM host for the rest of homeprod, running ESXi.
  • code: CentOS VM dedicated to running Phabricator. I use this to host my git repositories, some of which are replicated to Github. It also keeps local copies of some Github repositories. The wiki (“phriction”) and project workboards are lightly used; I want to like them, but find the wiki to be lacking and my own habits to be lacking with regard to the workboards.
  • trun: CentOS VM acting as a Drydock host, used by phabricator’s CI system (Harbormaster) to build various things (like this website).
  • storage: FreeNAS VM. All 8 of the previously mentioend HDDs are connected to a Host Bus Adapter (HBA), which is passed through directly to this VM, and added to a raidz3 pool. Primarily used to provide local network shares for our photos, digitized copies of CDs that we own, etc. This system has become more than it was originally intended to, and is something I intend to replace. I’m a huge fan of ZFS, but I’m becoming less a fan of FreeNAS with time; I will probably replace this with a simple FreeBSD or Linux VM, still running ZFS and without changes to the pool.
  • dns1: CentOS VM. DNS server for my local domain, recurses to root servers. Handed out via DHCP to systems in homeprod.
  • dns2: Ubuntu VM. DNS server for my local domain, recurses to root servers. Handed out via DHCP to systems in homeprod.
  • huginn: Ubuntu VM. Runs Huginn, performing basic recurring tasks like compiling an email equivalent to a made-just-for-me daily newspaper.
  • LibreNMS: CentOS VM. Runs LibreNMS, mostly used to track CPU, memory, disk and power usage by homeprod.
  • pihole: CentOS VM. Runs Pi-hole and recurses to dns1 and dns2. This is the DNS server handed out by DHCP to clients on my network, except for those running in homeprod itself.
  • salt: CentOS VM. Runs a Salt master, configuring (most of) the other VMs.
  • bookmarks: CentOS VM. Runs a bookmark manager called Shiori.
  • unifictl: Ubuntu VM. Runs the UniFi controller software required to manage the wireless access points in our house.
  • logger: Runs a graylog virtual appliance, handling logs from everything in the house.

Storage runs a few jails:

  • plex: Runs Plex, allowing us to stream the digital copies I’ve made of the music and movies that we own. I often enjoy the act of inserting physical media into a player, but sometimes convenience can’t be beat.
  • backup: Has read-only access to a number of datasets that I want to back up. Runs borg, sends backups to
  • syncthing: Runs syncthing, a file synchronization program. This acts as a hub for all of the files that I want to sync between my various devices. This runs a bit contrary to syncthing’s usual mode of operation, but results in a dropbox-like experience which is what I wanted.


OK, homeprod was a mess - what does the lab look like? Right now, non-existent. I’m starting fresh.

Previous uses of the lab:

  • Exploring the use of FreeIPA
  • Trying out Salt, before it was put into use in homeprod.
  • Network monitoring using Suricata
  • Network monitoring using BroZeek

Entering the World of DMR: Prerequisites

I recently became interested in joining a Net but was unable to do so as it takes place over DMR. Entering the World of DMR is a collection of notes that I took while trying to get on the air and join that net.

This first post will cover the basic prerequisites needed to get on the air with DMR. Subsequent posts will cover configuring the equipment and making a contact.



There are many radios available which support DMR. On a recommendation, I picked up an AnyTone AT-D878UV.


Know that hotspots are nice but not necessary. If you only intend to use DMR locally, not connecting to one of the networks, or have sufficient repeater coverage, you can skip getting a hotspot.

Hotspots connect to DMR networks over the internet and act as an RF gateway to those networks: if you have an internet connection, you can join any talkgroup you want.

I picked up a DVMEGA Hotspot, but the openSPOT hotspots seem fairly popular too. If you’re feeling adventurous, consider building your own MMDVM hotspot.

DMR ID Registration

Amateur radio callsigns aren’t sufficient for DMR operation, as DMR utilizes numeric IDs for each radio1 on a network. I will only be covering getting on to the Brandmeister network, but multiple DMR networks have now standardized on for DMR ID registration for the Americas, Asia and Oceania. Amateurs in Europe and Africa should register a DMR ID with


Once you have been assigned a DMR ID, you will need to register with any networks you wish to join. There are multiple networks, but I’ve only joined Brandmeister. DMR-MARC seems to be another popular network.


Visit the BrandMeister registration page and provide the requested information; you will need to already have a DMR ID to do so.

  1. A unique DMR ID must be in use for each radio actively taking part in a given QSO. It’s OK to have one DMR ID in use by all of your radios as long as you only use one at a time. [return]

Thanks, Let's Encrypt!

I have been intending to move this site to HTTPS for some time but it’s finally happened. Thanks to Let’s Encrypt for providing wonderful tooling as well as free certificates!

Although their automated config for Nginx isn’t ready for prime time, it was quite simple to obtain a certificate using letsencrypt certonly. Nginx configuration was handled as it would have been for any other certificate, which is easy enough; being able to run letsencrypt-renewer via cron means that certificate renewal should be a stress-free experience.