My Arch Linux Journey

Motivation

I have dinked around with computers for a long time. My preferred daily driver is a Mac (I've used Macs since 1991), and I've used Windows at work a lot throughout the years, but I've always had a latent interest in Linux. I've installed Ubuntu on several occasions in the past to play around with something, but I typically ended up back on my Mac because Linux didn't offer me any practical advantages.

I've recently noticed a surge in Linux discussion in the corners of the internet I tend to observe, and saw a lot of it was about Arch Linux. Arch is not new, but my impression was that it was primarily for folks that want to kit-bash their own system, so I assumed it was beyond my capabilities. However, my interest was piqued, so I started poking around and almost immediately stumbled upon Omarchy. Neat. This seemed to fit right into this whole renaissance of “old” technology I've also noticed has been gaining momentum (for example, VFC Midwest).

As a quick aside, I used to spend a lot more time doing hobbyist-type projects on computers, but because I work in technology, I slowly began to drift away from computing for fun. I estimate I'd entirely dismissed computers as a hobby for at least the last five years. Some of it was due to work fatigue, and some was the stark realization that the tech world was moving faster than I could ever keep up. Why bother? Poor attitude, I know, but I think this “hiatus” put me in a good position to realize a couple of things:

  1. I don't need to be a 10x developer to find value in even the smallest of computing projects.
  2. There's still a lot of cool stuff that can be done with old computers.

I have to thank a friend of mine with an extensive vintage computer collection for inspiration—this man attends a Tandy-specific computing con every year, if that tells you anything.

Anyway, after I got over the googly-eyed wonder of Omarchy, I realized I didn't want another plug-and-play solution that I'd spend an afternoon setting up and never use again. I wanted to really learn. That's when I decided to go with Arch.

Below is a summary of the steps I took to get it installed on my particular system. There was a lot of trial and error, but the process was surprisingly smooth. I'm still chipping away at it, so while I have a functional system, I'm still figuring out a good workflow and getting various tools installed to improve the UX.

Setup

I started with the Arch Installation Guide, which is generally the best resource to get through the installation.

  1. Downloaded the Arch ISO.
  2. Created a bootable USB flash drive with Rufus on Windows.
  3. Since my UEFI/BIOS wasn't cooperating with an on-the-fly boot disk selection, I set boot priority in the BIOS to the flash drive first.
  4. Pinged google.com to make sure the network was working (amazingly, it was).
  5. Partitioned the dedicated drive, using fdisk /dev/the_disk_to_be_partitioned following the recommended scheme (see Table 1).
  6. Formatted / and /boot with mkfs.ext4 /dev/partition_name.
  7. Formatted swap with mkswap /dev/swap_partition.
  8. Mounted the volumes, e.g. mount /dev/root_partition /mnt.
  9. Enabled swap, e.g. swapon /dev/swap_partition.
Mount Point Partition Partition Type Suggested Size
/boot /dev/efi_system_partition EFI system partition 1 GiB
[SWAP] /dev/swap_partition Linux swap At least 4 GiB
/ /dev/root_partition Linux x86-64 root (/) Remainder of the device. At least 23–32 GiB.

My drive was called “sda”, so I used:

Installation

  1. Installed base software with pacstrap: pacstrap -K /mnt base linux linux-firmware nano amd-ucode fsck man-db man-info
  2. I went through the config steps, but I think I forgot to generate the fstab or I did something wrong. I'll mention this later.
  3. Installed GRUB as a boot loader: grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB. I read it doesn't play nicely with Windows (and in fact, it doesn't recognize my Windows disk for some reason yet), but I've used it before so decided to use it again.

Launch

  1. At this point, I rebooted, but because I didn't set up GRUB to use secure boot, I had to disable it in the UEFI/BIOS. The good news is that Arch booted successfully. There were two bits of bad news:
    1. The boot seemed unusually slow.
    2. I couldn’t connect to the internet.
  2. First to tackle the internet issue because I wouldn't be able to install anything with pacman otherwise (aside from using pacstrap). Fortunately, I found this: https://linuxvox.com/blog/arch-linux-network-ip/. I booted off USB, installed networkmanager with pacstrap, and then the network config was trivial:
    • sudo systemctl start NetworkManager
    • sudo systemctl enable NetworkManager†
  3. Next, I installed zsh, and found this nice little guide to set the default shell and install PowerLevel10k: https://davidtsadler.com/posts/arch/2020-09-07/installing-zsh-and-powerlevel10k-on-arch-linux/.
  4. I was also interested in dwm from suckless.org after watching a lot of Bread on Penguins, and followed another guide from the same author to get it, dmenu, and st installed: https://davidtsadler.com/posts/arch/2020-08-17/installing-st-dmenu-dwm-in-arch-linux/.
  5. Next, I tackled the slow boot issue. Arch is configured to quiet boot by default so I had no idea what might be happening. Fortunately, I found this useful thread: https://bbs.archlinux.org/viewtopic.php?id=308506. My problem was exactly the same as the OP's, so fixing the swap partition's UUID in the fstab was the key. This is why I'm not sure whether I configured this properly during installation.

†Note: to be fair, I did try editing some network config files prior to this following some instructions on a site I didn't keep notes on so I can't reference it here. It's possible something I did there helped, but nothing worked until I got NetworkManager installed and enabled.

Tailoring: Attempt One

  1. I installed qutebrowser, again following the lead of Bread on Penguins.
  2. Set up dual monitors using xrandr: xrandr --output DP-1 --primary --auto --output DP-3 --auto --right-of DP-1.
  3. Decided to install LibreWolf for general browsing. It's a little easier for me to navigate for now instead of qutebrowser.
  4. Installed pass as a command line password manager, which required me to generate GPG keys. I'm not sure whether I'll stick with this long term, but it'll at least allow me to easily keep a few passwords handy for now and copy them to the clipboard for use.
  5. Patched dwm successfully with the functionalgaps patch to improve the aesthetics of the tiled windows. This was my first time applying a .diff file, and is as simple as downloading the .diff file and running patch < path/to/patch-file.diff in the dwm folder. After that, a sudo make clean install failed because I discovered suckless patches wisely update the config.def.h file instead of the user-edited config.h file, so my config didn't contain some necessary definitions from the patch. Fortunately, I haven't done any customization, so I was able to copy the default on top of my config and then built successfully.
  6. I had installed feh a while ago but hadn't tried using it to set the background (though I did snag a few background images at some point). It turns out, it's pretty trivial: feh --bg-fill /path/to/image and it set the background on both monitors. It's possible to set the monitors independently, but I like the same image on both monitors. The next challenge was to get the background to persist, which required me to create a .fehbg file in my home directory with essentially that same command and include a line in my .xinitrc to call it when starting up Xorg. It didn't work initially, but I eventually figured out that I needed to have the call to run my window manager last in the .xinitrc file for it to work properly.
  7. With the background set, I wanted to play with pywall to set some system colors. This also works pretty easily, though to get this working system-wide is going to take more work. A simple wal -i /path/to/image will at least set the terminal colors to a palette that matches the background. I tried some simple scripting to get the background set with a selection menu and then set the colors with wal, but I'm only partially successful. I'll have to get back to it later. UPDATE: I realized that pywal will use feh if it's installed, so I don't need to use feh separately&emdash;just make the call to wal and feed it the file, and it sets the background and terminal colors. I just need to figure out the best way to make it persist.
  8. At some point along the way, I didn't fully set my locale so I would see errors stating my locale was not supported after running some commands. Checking locale showed I was missing some things like LC_TYPE and LC_ALL. I dug around and found the /etc/locale.gen file (after reading through some forums), edited it to uncomment the line for en_US.UTF-8, and then ran locale-gen to regenerate my locales. All is good now...just not entirely clear why this was necessary in the first place.
  9. I just realized today that at some point I had installed yay. I'll have to make a note about that, because it's compiled from source.
  10. Grabbed the Dwm default keys cheat sheet gist and created an alias in .zshrc to quickly display the cheat sheet in the terminal.
  11. I set up bat to colorize several things like man pages.

Tailoring: Attempt Two

I was browsing YouTube the other day, and I ran across this interesting video by Josean Martinez: How To Make Your Boring macOS Terminal Amazing With Alacritty. I've been using iTerm 2 for years and never saw much reason to use anything else, but I decided to check out Alacritty and see what Josean had to say.

The good news is that I learned a lot:

After watching Josean fly around in his TUI interfaces using a split keyboard, I realized I was probably chasing the idea of being some kind of 1337 DevOps pro instead of being realistic. The whole reason I started playing with Arch was to learn and get comfortable with Linux, which doesn't mean exclusively using the keyboard and becoming a neovim wizard. Especially since I never learned to touch-type.

So, after farting around some more with dwm and dmenu, getting completely frustrated trying to remember which keys to press to do simple things like close windows and navigate the tiling window manager, I did a little research and settled on switching to Hyprland. That may bring an eye roll or two, but I wanted to try out something that used Wayland and something that would be easier for me to configure and use. Hyprland fit the bill nicely.

Along the way, I set up my shell environment with many of the recommendations made by Josean, installed a few apps like Visual Studio Code and Firefox, and changed a couple of Hyprland keybindings to something more familiar (e.g. I made the launcher open with alt-space since I'm so used to cmd-space for Spotlight on macOS). I even managed to compile a handful of apps for amateur radio: wsjt-x, fldigi, and SDR++. I've also been playing around with some other terminal emulators like kitty and ghostty.

Anyway, now I'm in business. I have a Linux machine I can actually use for something... exciting times!

<<<<<<< HEAD

An AI Adventure

I recently received an RTL-SDR v4 and wanted to give it a spin. Of course, there's always one little thing to address before playing—Xorg was still trying to start after a TTY login, and I wasn't sure why. Even though I'd decided to switch to Hyprland, I still had this annoying issue where the machine would start Xorg and dwm, so I'd have to exit and manually launch Hyprland. It was time to address this.

This should be simple, right? Edit ~/.xinitrc and comment out eval dmw, right? Nope. That prevented dwm from starting, of course, but Xorg would still try to run and then will error and kill itself. An improvement, but annoying. I poked around in a few config files and knew either xinit or startx were getting called somewhere, but I couldn't figure out where. I didn't want to uninstall Xorg, but since I couldn't figure out how to disable it, I did the unthinkable... I fired up my local OpenClaw agent and asked it for some help.

Even though this whole chronicle is about computing, I'm actually kind of a luddite. AI is not something I have a lot of interest in, and the OpenClaw agent I set up was more of a curiosity, but I decided to see if it would do something useful. The agent is running on my Mac, so it couldn't do anything for me. It could only advise.

As tempting as it is to post the entire transcript here just to see how crazy it went, but I'll just say that I created a ~/.xinitrc that just immediately exits (which didn't work) and eventually found myself reading through /usr/bin/startx, which gave me a clue. It was calling xinit, which means something was calling startx. I went through everything the AI suggested, which took me in a giant circle right back to my home directory: it turns out ~/.zshenv had a three line shell script that would call startx after logging into TTY. In retrospect, I remember writing this. I just wish I'd remembered sooner.

Fortunately, a couple of quick changes, and I had Hyprland launching on login and the Xorg problem was fixed.

The Sound Problem

Finally! I plug in the RTL-SDR, fire up SDR++, connect to my dongle, and I'm tuning in a local FM station. That's when I remembered one small issue I'd chosen to ignore at this point: I never did get sound working. It turns out sounds output is pretty useful for operating a software-defined radio.

Admittedly, I didn't take a lot of notes getting this fixed. It involved updating alsa, installing PulseAudio and PipeWire (I'm still not sure whether both are necessary), and then a lot of farting around to figure out how to get the system to use the correct audio device.

My machine has two audio outputs: one apparently on the graphics card, and one on the motherboard. It seemed like the system was trying to use the graphics card output as the default, which isn't what I wanted, but I couldn't figure out how to point it to the correct one. After a lot of trial and error, eventually one of my attempts to run speaker-check finally worked! I'm still not sure what I did, unfortunately. Once I knew I could get something going, though, I knew I could get things working properly.

Once I figured out I needed PulseAudio running as a daemon, I was able to control the sound through the UI. I launched SDR++ with confidence and when I tuned to a local FM station, I heard sound. Choppy sound. A little Googling brought me to a forum thread from 2020 talking about rtaudio needing to be rebuilt without alsa support (which doesn't make sense to me), so I cloned it, removed the currently installed version with yay and then built rtaudio. Violà!