Three Machines, One Obsession: Installing Omarchy on ANDREA, Valentina, and Songbird

I have a habit of naming my hardware. ANDREA is my NVIDIA-powered gaming desktop. Valentina is my work MacBook Pro 2019. Songbird is the newest arrival, a Lenovo ThinkPad T14s. Over the past months, all three ended up running Omarchy — DHH's opinionated Arch Linux + Hyprland setup. But it didn't start as a grand plan. It started with a much simpler itch: gaming on Windows felt heavier than it needed to be.

Chapter 0: It Started with Gaming

The whole journey began on ANDREA. I wanted to migrate away from Windows, chasing a hunch that a lighter operating system could actually improve my gaming experience — less background noise, more of the hardware working for the game. But jumping straight from Windows to Arch felt like skydiving without a parachute. So I picked a stepping stone built exactly for this: Bazzite.

The Bazzite Detour

Bazzite is Fedora Atomic tuned for gaming — and being immutable, it rewired how I think about a Linux system:

• There's no dnf on the host. The root filesystem is read-only; extra CLI tools get layered with rpm-ostree install (ideally with --apply-live so you don't reboot for every package — and when that's not supported, the layer queues up and you reboot to apply it).
• Updates are a single command. ujust update refreshes the image, flatpaks, everything — the system feels more like a console than a traditional distro.
• Some tools route around the image entirely. Things like lazygit and a recent Neovim aren't in the base, so they land in /usr/local/bin — which on ostree systems is really the writable /var/usrlocal. No layering needed.
• Small distro dialect shifts. fastfetch instead of the retired neofetch, fd/bat under their real names, and Caps→Esc configured through KDE's settings instead of gsettings.

And the important part: it worked. Games ran great. Linux gaming in 2025+ is real. Bazzite proved the concept — and gave me the confidence to go all-in with Arch.

Finding Omarchy

With that courage in hand, I went looking for the simplest possible path into Arch — something opinionated that wouldn't require weeks of assembling a desktop environment from parts. That search led me to Omarchy: Arch + Hyprland with beautiful, sane defaults, and above all, effortless customization. Everything is a config file waiting to be version-controlled — which is exactly why so much of this story ends up living in my dotfiles. The tinkerer in me was sold.

Round 1: ANDREA — The Desktop (MSI Z690, i7-12700K, RTX 3080, 64GB DDR5) — The Power Play

So ANDREA graduated from Bazzite to Omarchy. You'd think the desktop would be the easy one — modern standard parts, no security chip in the way. But NVIDIA + Wayland + Hyprland is its own genre of problem-solving.

What the desktop threw at me:

• NVIDIA drivers. For an Ampere card like the RTX 3080, nvidia-open-dkms turned out to be the right choice over the proprietary legacy path.
• Steam on Wayland. Gaming under Hyprland has quirks — window behavior and compatibility issues that needed per-app attention.
• Spotify window rules. Hyprland 0.53 changed its window-rule syntax, so my rules needed rewriting to match the new format.
• Boot time optimization. Two big wins here: tuning the Limine bootloader timeout, and taming DDR5's slow memory training by enabling MRC Fast Boot in the BIOS. DDR5 retraining on every boot is a real time thief.
• LUKS encryption. Full-disk encryption, because a fast machine shouldn't be an insecure one.

Verdict: the gaming migration that started it all, completed — a daily-driver Omarchy rig that boots fast, games, and looks great doing it.

Round 2: Valentina — The MacBook Pro 2019 (T2 Chip) — The Hard-Fought Win

With ANDREA conquered, I wanted a real challenge — and Valentina had been asking for one. The 2019 MacBook Pro is infamous for overheating, throttling itself into misery under macOS. My theory: a leaner OS might treat that thermally-cursed chassis with more respect. Installing Linux on a T2-era MacBook is famously "fun" — Apple's T2 chip sits between you and half the hardware (SSD, keyboard, trackpad, Wi-Fi), so a stock Arch ISO gets you nowhere.

The highlights of the battle:

• GRUB configuration. Getting the bootloader to play nicely with Apple's EFI took several rounds of trial, error, and chroot rescues.
• Networking. NetworkManager and the iwd backend needed careful wrangling before Wi-Fi worked reliably.
• A broken pacman.conf. At one point I managed to corrupt my package manager configuration mid-install. Repairing it from a live environment was its own mini-adventure.
• The Touch Bar. Yes, it works. Getting the Touch Bar active under Linux felt like the victory lap of the whole install.

The one item still on my list: setting up rEFInd so I get a proper dual-boot menu alongside macOS instead of my current bootloader arrangement.

Verdict: fully working Omarchy on Apple hardware. Deeply satisfying.

Round 3: Songbird — The ThinkPad T14s Gen 3 — The Comeback

For the final chapter I wanted to do the thing every Linux lover eventually does: get a ThinkPad. The legendary Linux compatibility, the durability, the cult status — Songbird, a T14s Gen 3 (i5-1245U), was going to be the Linux laptop. Except my first attempt died at a wall no Arch wiki can climb: a corporate BIOS Supervisor Password. No BIOS access, no boot order changes, no install. For a while, this was the machine that got away.

But eventually I got into the BIOS — and then the real Lenovo experience began:

• BIOS/UEFI surgery. Disabled Secure Boot and OS Optimized Defaults so the firmware would tolerate anything that isn't Windows, and set the Sleep State to Linux S3 for proper suspend.
• The USB boot saga. Lenovo's strict firmware simply refused to see my install media at first. Isolating the problem meant testing flashing methods against each other (BalenaEtcher vs. Rufus/Ventoy) and discovering that Windows Fast Startup was quietly interfering with the boot process.
• Keyboard layout. The laptop has a physical Latin American Spanish keyboard, so the console and Wayland needed la-latin1 / latam configured (/etc/vconsole.conf and Hyprland's input config).

Today, Omarchy runs on it with Hyprland under Wayland, same as its siblings — and the ThinkPad reputation holds up.

Verdict: from 0 packages installed to full member of the fleet. Persistence beats firmware.

Next up: a keyboard transplant

The pending mod on this machine is swapping the latam keyboard for a US layout one — and on the T14s Gen 3, that's not a casual swap. In this ultra-thin chassis the keyboard is plastic-riveted to the palmrest (C-cover). The options:

• The official route: a full palmrest + keyboard assembly (~$300), which means tearing down to the motherboard and transferring everything over.
• The brave route: the keyboard part alone ($30–65), which means breaking the plastic rivets and re-melting them to secure the new one.

And no, mechanical switches inside this chassis are physically impossible — there's simply no room. That dream stays external.

Bonus Round: The Mouse Dongle Mystery

Even after the installs, Linux keeps you humble. My 2.4GHz wireless mouse started stuttering under Omarchy, and the culprit was a two-headed monster: USB autosuspend aggressively powering down the dongle, plus good old RF interference. Disabling autosuspend for the device and repositioning the dongle brought it back to life.

The Glue: One Dotfiles Repo for Every Machine

Installing an OS three times is one thing; reconfiguring your entire environment three times is where people give up. My answer was to pour everything into a single cross-platform dotfiles repo — savaf/dotfiles — that works the same on Omarchy, macOS, Ubuntu/WSL, and Fedora/Bazzite (yes, the Bazzite era left its mark on the repo too). Here's what it took to make one repo serve all three machines.

GNU Stow as the backbone

Every top-level folder in the repo (zsh/, git/, nvim/, tmux/, lazygit/…) is a GNU Stow package. Running stow <package> symlinks its contents into $HOME, preserving the directory layout. Config lives in one place, and every machine just points to it.

One bootstrap script that detects where it's running

The entire setup is a single entry point:

git clone [email protected]:savaf/dotfiles.git ~/dotfiles
cd ~/dotfiles
./scripts/bootstrap.sh

The script detects the OS and branches accordingly. macOS is easy ($OSTYPE == darwin*), and most Linux distros identify themselves in /etc/os-release. But here's the fun part: Omarchy doesn't change /etc/os-release — it still says ID=arch. So the bootstrap detects Omarchy by its footprint instead:

if [[ "${ID:-}" == "arch" ]] \
    && { [[ -d "${HOME}/.local/share/omarchy" ]] || command -v omarchy >/dev/null 2>&1; }; then
  echo "omarchy"; return
fi

WSL gets its own check (grep -qi microsoft /proc/version), which matters for things like keyboard remapping — on WSL, Caps→Esc is Windows' job, so the script skips it.

Per-OS package manifests

Instead of one giant install script full of if-statements, packages/ holds plain-text manifests per package manager: brew-cli.txt, apt-cli.txt, dnf-cli.txt, pacman-cli.txt. The bootstrap picks the right one — and uses idempotent flags (pacman -S --needed, etc.) so re-running is always safe. On Bazzite there's no dnf at all, so the bootstrap layers packages with rpm-ostree install --idempotent --apply-live instead.

Conditional packages: Omarchy-only extras

Some config only makes sense on one machine. The omarchy/ Stow package (Hyprland bindings, waybar config, autostart) is only added to the stow list when the detected OS is Omarchy. My favorite piece in there is an Omarchy theme-set hook that syncs my RGB hardware to the current theme: it reads the accent color from the active theme's colors.toml and pushes it to every device via OpenRGB — in two passes, because my Lian Li strips and Corsair RAM only speak "direct" mode while the GPU and keyboard only speak "static". Change the desktop theme, and the whole case changes color with it.

A modular zsh that adapts at runtime

.zshrc is just a slim loader that sources focused modules from ~/.config/zsh/ (exports, path, plugins, aliases, integrations…). Cross-platform behavior comes from runtime guards rather than separate configs: Homebrew's shellenv loads from /opt/homebrew on macOS or /home/linuxbrew on Linux — whichever exists; the cat replacement resolves to bat or Ubuntu's batcat, whichever is installed; macOS-only integrations sit behind an $OSTYPE == darwin* check.

Respecting each platform's quirks

• macOS puts configs in weird places. lazygit reads from ~/Library/Application Support, not ~/.config, so the bootstrap symlinks the stowed config there. VS Code settings get the same per-OS symlink treatment.
• WSL's .wslconfig lives on the Windows side. The bootstrap locates the Windows user profile from inside WSL and copies it over.
• Node everywhere via nvm. LazyVim's TypeScript extras and my global npm packages need a modern Node on every OS, so the bootstrap provisions it through nvm instead of each distro's (often ancient) package.
• Safety first. Before stowing anything, real (non-symlink) files that would collide are backed up to ~/.dotfiles-backup/<timestamp>/. Nothing is ever silently destroyed.

The sneakiest bug: making zsh the actual shell on Omarchy

Omarchy defaults to bash. The bootstrap runs chsh to switch to zsh — but on Omarchy, reopening the terminal isn't enough. The running Hyprland/uwsm session captured SHELL=/usr/bin/bash at login, and new Alacritty windows inherit that instead of reading /etc/passwd. So terminals stubbornly keep opening bash. The fix is two-fold: pin zsh in alacritty.toml so new windows open correctly immediately, and re-login to Hyprland so PAM re-exports the right $SHELL session-wide. That one took a while to understand.

What I Learned

1. Stepping stones matter. Bazzite was the low-risk experiment that proved Linux gaming works — without it, I might never have jumped to Arch.
2. Every machine is its own project. The same distro behaves like three different operating systems across three different machines.
3. The bootloader is where journeys begin and end. GRUB, Limine, rEFInd — most of my pain and most of my wins lived there.
4. Read the version notes. Hyprland's window-rule syntax change alone cost me an evening I could have saved with five minutes of changelog reading.
5. Some walls just take longer. A BIOS supervisor password looked like the end of the road — until it wasn't. The difference between "blocked" and "done" was patience, not skill.
6. The install is temporary; the dotfiles are forever. Detecting the environment at runtime — instead of maintaining per-machine configs — is what made three installs feel like one.

What's Next

The rEFInd dual-boot setup on Valentina is still pending, Songbird is awaiting its US-keyboard transplant, and knowing myself, the fleet will keep growing. If you're considering Omarchy on unusual hardware: do it. The fights are the fun part.

Have you tried Omarchy or Arch on weird hardware? I'd love to hear your war stories.