Tech Articles and Tutorials.

user@tech-zone: ~

user@arch:~/tech-zone$ cat README.md

The Tech Zone_

Tech tutorials, dotfiles, and lessons from building my personal computing stack piece by piece.

Currently: my first Arch Linux install on an old laptop — on the way to a dual-boot Ubuntu/Arch workstation with BTRFS, LUKS, and zram, and eventually a triple-boot with a minimal Windows partition for collaborators who live in Office-suite land.

Next on this thread: Neovim from scratch, tiling and scrolling window managers, and whatever else I break and fix.

Eventually: a privacy-first home setup with custom DNS routing, a personal VPN I can connect to from anywhere, and self-hosted services on a NAS.

showing 10 of 10

published

arch linux ubuntu dual-boot btrfs no encryption shared partition chainload

Dual-Boot Arch + Ubuntu (Plain Btrfs, No Encryption) — With a Shared Data Partition

2026-06-12 tested end-to-end

Ubuntu 24 LTS alongside Arch on one drive, no encryption anywhere: two plain Btrfs roots, one shared 150 GiB Btrfs /data both distros mount read-write, per-OS zram + NoCOW hibernation, pinned UID-1000 ownership, and one GRUB menu (Arch's) that chainloads Ubuntu. No cryptsetup, no keyfile, no passphrase prompts, and none of the grub> boot failures that come with GRUB unlocking an encrypted /boot. Built and verified on real hardware — the live-install fixes (chainload menu, swap-file hibernation, the editor and recordfail gotchas) are folded in.

plain Btrfs — no mapper, no passphrase no-luks

[user@arch-dual ~]$ findmnt /data TARGET SOURCE FSTYPE OPTIONS /data /dev/nvme0n1p2[/@data] btrfs rw,noatime,compress=zstd:3 # raw partition, no /dev/mapper [user@arch-dual ~]$ grep -c sd-encrypt /etc/mkinitcpio.conf 0 # no LUKS hook — root mounts directly, no passphrase at boot [user@arch-dual ~]$ grep menuentry /etc/grub.d/40_custom menuentry "Ubuntu 24.04 LTS" { # Arch's GRUB chainloads Ubuntu — one menu, both OSes_

read the no-encryption dual-boot →

raspberry pi tailscale pi-hole caddy vpn self-hosting

A Beginner Homelab on a Raspberry Pi — One Pi, One Tailnet, Nothing Exposed

2026-06-02 tested on my own Pi

A build-one-job-at-a-time guide I wrote and tested: a single always-on Raspberry Pi that streams my media (Audiobookshelf), blocks ads for the whole house (Pi-hole), serves pretty HTTPS URLs behind Caddy, hands me one dashboard at home.home, reaches everything from my phone, and routes traffic through a VPN — all over a private Tailscale mesh with no port forwarding and nothing on the public internet. Includes the honest VPN chapter: why two full-device VPNs can't both be on, and what I actually run.

private by default — reached over the tailnet homelab

[user@homelab ~]$ tailscale status --self | head -1 100.x.y.z homelab user@ linux - [user@homelab ~]$ docker compose ls --format '{{.Name}}' audiobookshelf pihole caddy dashboard [laptop ~]$ curl -sI https://home.home | head -1 HTTP/2 200 # Caddy + local DNS, real HTTPS, no ports [laptop ~]$ dig +short doubleclick.net @100.x.y.z 0.0.0.0 # Pi-hole follows me over Tailscale_

read the homelab build →

arch linux btrfs luks snapper compilation

Three Single-Boot Arch Variants: Btrfs, LUKS, or Both

2026-05-18 compilation

A side-by-side compilation of three single-boot variants — Arch + Btrfs, Arch + LUKS, and Arch + LUKS + Btrfs — distilled from what I learned writing Articles 01–04. Each variant is a complete, copy-pasteable procedure isolated to one variable change relative to the basic install. Reasoned from the wiki and the lessons of those four articles; not all three are runs I executed line-by-line.

read the variants →

arch linux pacman aur yay paru reference

Pacman, Yay, Paru, and the AUR — What Every Prompt Actually Means

2026-05-17 reference

A practical reference for every interactive prompt, warning, and error you'll see during pacman installs and AUR builds — Y/n confirmations, provider selection, file conflicts, cleanBuild / diffs / PKGBUILDs-to-edit, the snap-pac perl warning that looks scary but isn't, side-by-side coverage of yay and paru (defaults, configs, flag differences), and how to layer your own dotfiles on top of opinionated bundles with GNU Stow.

yay — interactive prompts reference

[user@arch ~]$ yay -S caelestia-meta 3 caelestia-shell (Build Files Exist) 2 quickshell-git (Build Files Exist) 1 libcava (Build Files Exist) ==> Packages to cleanBuild? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled ==> Diffs to show? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled ==> PKGBUILDs to edit? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled_

read the reference →

arch linux luks btrfs snapper hibernation zram single-boot

Arch + LUKS + Btrfs — Encrypted, Snapshot-Ready Single-Boot

2026-05-17 booting version

Article 01's ambition, executed correctly: LUKS2 on the root partition, Btrfs with the canonical @/@home/@snapshots/@var_log/@swap subvolumes, zram for everyday swap plus a NoCOW Btrfs swap file for hibernation, snapper + grub-btrfs from day one — with every cryptdevice= typo from the failed-boot post-mortem fixed. Desktop-agnostic: stops on the console, with Part 4 as a fork between Caelestia (Article 05) and a custom Hyprland (upcoming).

first boot — sanity checks booting version

[user@arch ~]$ sudo cryptsetup status cryptroot type: LUKS2 cipher: aes-xts-plain64 device: /dev/nvme0n1p2 [user@arch ~]$ findmnt -t btrfs -o TARGET,OPTIONS TARGET OPTIONS / subvol=/@,compress=zstd:3,noatime /home subvol=/@home,compress=zstd:3 /.snapshots subvol=/@snapshots,compress=zstd:3 /var/log subvol=/@var_log,compress=zstd:3 /swap subvol=/@swap,noatime [user@arch ~]$ swapon --show NAME TYPE SIZE PRIO /dev/zram0 partition 8G 100 /swap/swapfile file 20G -2 [user@arch ~]$ sudo snapper -c root list | tail -3 42 | pre | 2026-05-17 21:14 | root | timeline 43 | post | 2026-05-17 21:14 | root | timeline_

read the install log →

arch linux first install ext4 grub systemd

My First Arch Linux Install: A Basic Setup on an Old Laptop

2026-05-01 booting version

A copy-pasteable walkthrough of installing Arch Linux 2026.05.01 on an old test laptop — verifying the ISO, partitioning, pacstrapping, configuring locale and users, and getting GRUB to actually boot the thing. No Btrfs, no LUKS, no zram — just the boring, dependable first install.

post-install — boot check booting version

[user@arch ~]$ lsblk NAME SIZE TYPE MOUNTPOINTS nvme0n1 465G disk ├─nvme0n1p1 1G part /boot ├─nvme0n1p2 35G part [SWAP] ├─nvme0n1p3 200G part / └─nvme0n1p4 229G part /home [user@arch ~]$ systemctl is-system-running running [user@arch ~]$ uname -r 6.13.4-arch1-1_

read the install log →

arch linux luks btrfs mkinitcpio debugging

An Ambitious Arch Install That Didn't Boot — LUKS, Btrfs & Lessons

2026-05-05 boot failed

The opposite of the boring install: full-disk LUKS, Btrfs subvolumes for / and /home, zram swap, a shared data partition, and dual-boot with Ubuntu. GRUB loaded, the LUKS prompt accepted my passphrase, and then the kernel dropped me into emergency mode. The plan, the failure, and everything I've tried so far.

boot — emergency.target boot failed

A start job is running for /dev/disk/by-uuid/0e6caf44-… A password is required to access the Arch volume. [FAIL] Timed out waiting for device /dev/disk/by-uuid/0e6caf44-... [DEPEND] Dependency failed for /sysroot. [DEPEND] Dependency failed for initrd-root-fs.target. You are in emergency mode. root@archiso ~ # ls /dev/mapper control arch …_

read the post-mortem →

in progress · reasoned, not yet executed

Articles in Progress

This triple-boot guide is fully written and readable, but I haven’t yet run it end-to-end on real hardware — so treat it as a carefully-reasoned draft, not a battle-tested runbook. (Its dual-boot sibling is now tested and lives in the published grid above.) It keeps the disk on plain Btrfs with no encryption: two Btrfs roots plus a shared Btrfs /data, rebuilt next to an existing Windows on its reused, unencrypted ESP (mounted at /boot/efi), zram for everyday swap, and a Btrfs swap file for hibernation. Keeping the ESP unencrypted sidesteps the whole class of grub> boot failures that comes with GRUB unlocking an encrypted disk. The card is clickable — just expect rough edges until the amber status pill flips to done.

arch linux ubuntu windows triple-boot btrfs no encryption rebuild

Triple-Boot Arch + Ubuntu + Windows (Plain Btrfs, No Encryption)

2026-06-07 reasoned, not yet executed

A machine that already runs Windows 11, rebuilt to triple-boot it with Arch and Ubuntu 24 LTS on plain Btrfs. Delete the old Ubuntu and swap partitions, reclaim the unallocated space, and carve a shared plain-Btrfs /data plus separate roots — all without touching Windows, its ESP, or its recovery partitions. The existing EFI is reused at /boot/efi, with the UTC-clock / Fast-Startup / BitLocker fixes. One GRUB with os-prober chainloads all three. No encrypted disk, so no --modules EFI surgery and no grub> recovery to learn. Secure Boot off, BitLocker off; the tradeoff (unencrypted at rest) stated plainly.

three OSes, one GRUB, zero passphrases no-luks

[user@arch-triple ~]$ sudo grub-mkconfig -o /boot/grub/grub.cfg 2>&1 | grep Found Found Windows Boot Manager on /dev/nvme0n1pXX@/EFI/Microsoft/Boot/bootmgfw.efi # Ubuntu comes from a hand-written 40_custom chainload, not os-prober [user@arch-triple ~]$ findmnt / /data /boot/efi -o TARGET,SOURCE,FSTYPE / /dev/nvme0n1pXX[/@] btrfs # Arch root, plain Btrfs (no LUKS) /data /dev/nvme0n1pXX[/@data] btrfs # Arch + Ubuntu, Linux-only /boot/efi /dev/nvme0n1pXX vfat # reused Windows ESP [user@arch-triple ~]$ ls /boot/efi/EFI/ GRUB Microsoft Ubuntu # one unencrypted ESP, three boot paths_

read the no-encryption triple-boot →

upcoming · drafts in progress

Planned Articles

The roadmap below is a queue, not a library — these are write-ups I've committed to but haven't shipped yet, listed in the order I plan to publish them. Cards are dashed, amber-flagged, and intentionally non-clickable so it's clear there's nothing to read yet. Check back, or watch the commit log if you're impatient.

hyprland wayland custom waybar dotfiles

A Custom Hyprland Setup — Built Piece by Piece, No Bundle

tba planned

The desktop layer I'm actually moving toward — Hyprland built piece by piece: my own bar (waybar or ironbar), my own terminal, my own keybinds, my own theme, with no project-bundle layer baked in. Slower to "first screenshot" than a pre-made bundle, but every component is one I picked and there's no surprise opinion to discover later. This is the desktop layer Article 03's Part 4 points to.

scope

Hyprland 0.55+ with hyprland.lua as the primary config language
Bar: comparison of waybar, ironbar, eww — pick one and wire it up
Audio (PipeWire), GPU drivers, login manager (greetd + tuigreet) — every prerequisite installed à la carte
Minimal app set; honest opinions on what's worth keeping vs. dropping
How it feels on older hardware: first-screenshot time, idle CPU/RAM, no bundle overhead

arch linux 2019 mac mini broadcom wifi bcm4360 ext4

Arch on a 2019 Mac mini — Same Basic Install, Special Wi-Fi Card

tba planned

The boring-but-dependable first install, ported to a 2019 Mac mini. The catch: its Broadcom Wi-Fi card isn't supported by the default kernel modules, so the install needs an Ethernet bootstrap and the proprietary broadcom-wl driver before networking comes back.

scope

Mirrors Article 02 (ext4, GRUB, systemd, no LUKS, no Btrfs)
Diverges on Wi-Fi: broadcom-wl via wired install + DKMS
Notes on Apple T2 / EFI quirks specific to this Mac mini revision