Border Cyber Group | May 2026

There is a particular kind of satisfaction that comes from watching a system you built — kernel, libc, compositor, audio stack, every userspace tool compiled from source — boot on a machine you've never touched before, from a USB stick you wrote yourself. Not installed. Not copied. Just... alive.

On May 2nd, 2026, SableLinux booted to a working Sway desktop on a dusty HP Pavilion desktop that had nothing to do with the machine it was built on. The live user — sable, no password — autologged in, Sway initialized on an Intel UHD 630, and a few minutes later YouTube was playing in Firefox. We took a screenshot and pushed it to GitHub.

This is how we got there.

What We Were Starting From

SableLinux is a custom Linux distribution built from scratch on Linux From Scratch 12.4-systemd. No package manager, no binary base, no shortcuts. The build machine — call it the forge — runs an Intel Core Ultra 5 245K paired with an AMD RX 9070 XT (RDNA4), 32GB of DDR5, and kernel 6.16.1. The system is a fully operational daily driver: Sway 1.10 as the permanent desktop, PipeWire for audio, ROCm 7.2.2 with a llama.cpp HIP backend for local AI inference, and a deep security toolchain including Ghidra, Metasploit, radare2, and a few hundred other tools.

The problem was that it ran on one computer. One NVMe drive. One very specific hardware profile.

A Linux distribution that can't leave its birth machine isn't a distribution. It's a very complicated personal computer.

The goal: a bootable live ISO. Something you could hand to a stranger, write to a USB drive, and boot on commodity hardware.

The Gap Between "Works Here" and "Works Anywhere"

The forge kernel was built for the forge. It knew its own hardware intimately — RDNA4 firmware, a specific NVMe controller, a particular PCIe topology. The broader world of commodity x86 hardware was a different problem entirely.

The first serious diagnostic session was a kernel configuration audit. Going line by line through the existing config against what a generic live boot environment actually needs, two blockers surfaced immediately:

CONFIG_SQUASHFS=y — missing. No squashfs support meant no compressed live root filesystem. The entire live boot architecture — squashfs + overlayfs + tmpfs writes — was dead before it started.

CONFIG_OVERLAY_FS=y — missing. The mechanism that makes a compressed read-only filesystem appear writable to the live user. Also dead.

Beyond those hard blockers, modular driver coverage was thin: no DRM_NOUVEAU for NVIDIA cards, no DRM_VMWGFX for VMware, no IGB or IXGBE for Intel server NICs, no IWLWIFI for Intel wireless. The kernel was a precision instrument that wouldn't play well on a stage.

Kernel build number nine. make -j14. Initramfs rebuilt. System rebooted clean.

Building the ISO Pipeline

The forge didn't have any ISO tooling. Everything had to be built from source — that's the deal with LFS.

squashfs-tools 4.6.1 — the engine for compressing a 25GB live filesystem down to something that fits on a USB drive.

xorriso 1.5.6 — the ISO assembly and burning tool.

mtools 4.0.44 — FAT filesystem support, needed for UEFI GRUB deployment.

Staging the live filesystem was its own project. The goal was to copy the full SableLinux root into a clean staging directory — /mnt/liveroot — with careful exclusions: no /home/pepper, no QEMU disk images, no swap, no SSH host keys, no machine-id, no logs. A live image should arrive as a blank slate with a specific identity, not a snapshot of a developer's working session.

A live user named sable was created: UID 1000, wheel group, NOPASSWD sudo, tty1 autologin, .bash_profile configured to launch Sway automatically.

Then the squashfs build ran:

mksquashfs /mnt/liveroot /mnt/liveiso/LiveOS/squashfs.img \
  -comp zstd -Xcompression-level 19 -b 1M -no-xattrs

475,427 inodes. 427,846 files. 25GB of compiled system compressed to 6.3GB in under five minutes on RDNA4-adjacent hardware. The zstd ratio came in at 26% of uncompressed size. Satisfying numbers.

The Initramfs Init Script

The init script is the pivot point of a live system — the small shell script that runs before systemd, finds the USB device, mounts the squashfs, layers overlayfs on top, and hands control to the real init. Writing it correctly is unforgiving work.

The architecture:

  1. Mount proc, sysfs, devtmpfs, tmpfs for /run
  2. Wait briefly for USB devices to settle
  3. Walk every block device looking for a partition labeled SABLELINUX containing /LiveOS/squashfs.img
  4. Mount the squashfs read-only
  5. Create a tmpfs, split it into upper/ and work/
  6. Mount overlayfs: lowerdir=squashfs, upperdir=tmpfs/upper, workdir=tmpfs/work
  7. Bind-mount proc/sys/dev/run into the merged root
  8. exec switch_root /run/rootfs/merged /sbin/init

The first version had a set -e at the top. That caused silent failures — a single non-fatal error would kill the init without any message, leaving the system in initramfs limbo. Removing set -e and adding explicit error output to each step turned silent panics into diagnosable output.

The xattr issue surfaced early: an ominous-looking error message — SQUASHFS error: Xattrs in filesystem, these will be ignored — that turned out to be harmless. Building the squashfs with -no-xattrs eliminated it.

The HP Pavilion Trials

The first test target was an HP Pavilion desktop from the mid-2010s. Hardware that was in every office and living room for a decade — exactly the kind of commodity machine a security researcher might grab when they need a field box.

Specs:

  • Intel Core i3-8100 (Coffee Lake, 4 cores, 3.6GHz)
  • Intel UHD 630 integrated graphics
  • 16GB DDR5 RAM
  • 1TB SATA SSD
  • Realtek RTL8111 Gigabit Ethernet (r8169, in-kernel, no firmware needed)
  • UEFI boot

The first USB write failed before the machine could even try to boot. The USB drive had old iso9660 signatures on it from a previous experiment. BIOS firmware was recognizing the iso9660 structure instead of the GPT partition table. wipefs -a on the USB device cleared the signatures, and GPT was recognized on the next boot attempt.

The USB layout settled on:

  • sdb1 — 100MB vfat EFI System Partition
  • sdb2 — 14.5GB ext4, labeled SABLELINUX

GRUB deployed via grub-mkstandalone with explicit module baking: --modules="part_gpt fat ext2 linux search". The ext2 module handles ext4 reads — GRUB's ext2 driver is ext4-compatible. Without explicitly baking these modules, the standalone GRUB binary can't read the ext4 partition and dies silently.

The first boot attempt hit emergency mode. Root cause: /etc/fstab still had UUID entries for the forge's actual NVMe partitions. Systemd was trying to mount drives that didn't exist. The fix was stripping /etc/fstab in the live image down to a single tmpfs entry for /tmp. Anything else causes a mounting timeout and drops to emergency shell.

The second failure: sable couldn't start a Wayland session. XDG_RUNTIME_DIR wasn't being set. systemd-logind creates /run/user/1000 on login — but there was a conflict. The forge's build had pepper at UID 1000. The live image had sable at UID 1000. The two entries were colliding in /etc/passwd. Removing the pepper entry from the live image's passwd and ensuring sable was the sole UID 1000 user resolved it.

The third failure: Sway started, then immediately crashed. The WLR_DRM_DEVICES environment variable was set to /dev/dri/card1 — correct for the forge (where RDNA4 is on the secondary PCI slot). The HP Pavilion has only one GPU. Its DRM device is /dev/dri/card0. The live .bash_profile needed to either detect the correct DRM device dynamically or default to card0 for generic hardware.

And the iris driver. The forge's Mesa build included radeonsi and llvmpipe but not iris. Intel integrated graphics from UHD 630 onward requires the iris Gallium driver for accelerated rendering under Wayland. Without it, wlroots falls back to software rendering via llvmpipe — functional, but slow and potentially unstable. The Mesa rebuild to add -Dgallium-drivers=radeonsi,iris,llvmpipe was queued as follow-on work.

On May 2nd, 2026, after iterating through those fixes and rebuilding the squashfs image:

"I'm in SWAY!!!!!!!!!"

Sway desktop. Working. On the HP Pavilion. From a USB stick.

A few minutes later: YouTube playing in Firefox. Wired ethernet working. First screenshot captured and pushed to black-vajra/sablelinux on GitHub: assets/screenshots/first-iso-live-desktop-boot.png.

Audio required a manual systemctl --user start pipewire pipewire-pulse wireplumber because the user session bus wasn't fully initialized in the live environment — XDG_RUNTIME_DIR setup for the sable session needed tightening. A known issue, next iteration.

The Next Target: maya

The ASUS Q503UA — internally called maya — is a different challenge.

Specs:

  • Intel Core i5-6200U (Skylake, 2C/4T, 2.3–2.8GHz)
  • Intel HD Graphics 520 (Skylake GT2, older i915 generation)
  • ~8GB RAM
  • 298GB Hitachi SATA HDD
  • Intel Wireless-AC 7265 (iwlwifi + firmware required)
  • Realtek RTL8111 Ethernet (r8169, in-kernel)
  • Intel Sunrise Point-LP HDA audio, ALC255 codec
  • ASUS AMI UEFI, 2015

Skylake is a generation older than Coffee Lake. The Intel HD 520 predates the UHD naming scheme and requires older i915 firmware blobs — specifically skl_dmc_ver1_27.bin for display power management. The iris Gallium driver becomes critical here: without it, hardware-accelerated compositing under Sway is unavailable on Skylake.

The WiFi situation is different from the HP Pavilion. The RTL8111 gives the HP wired connectivity with no firmware requirement — the driver is entirely in-kernel. maya's Intel 7265 requires iwlwifi-7265D-*.ucode firmware blobs bundled into the live environment. Without them, the 7265 card comes up with no firmware and sits silently. For a laptop without a wired Ethernet adapter nearby, that means no network from the live session.

The porting work to maya is the current frontier: Mesa rebuild with iris, firmware bundle for iwlwifi-7265D, validation of touchpad (Atmel maXTouch via I2C-HID) and audio initialization.

What's Left

The live ISO is alive. It is not yet finished.

Immediate polish:

  • PipeWire/WirePlumber autostart in the sable user session (XDG_RUNTIME_DIR properly set before user services attempt to start)
  • Sway exit loop in .bash_profile — currently exits cleanly to shell, should offer to relaunch or shut down gracefully
  • Squashfs rebuild with the above fixes, stable session test

mesa rebuild: Add iris to the Gallium driver set: -Dgallium-drivers=radeonsi,iris,llvmpipe. iris does not require libclc — that misconception cost time in earlier planning. Only rusticl (ROCm OpenCL) requires libclc. iris is a standalone Gallium frontend.

Installer: The live session currently runs entirely in RAM. There is no installer. That's the next significant feature — a shell-based installer that partitions a target disk, copies the squashfs contents, installs GRUB, and writes a working /etc/fstab. Custom shell-based, not Calamares — avoiding the Qt/KDE dependency weight is a hard constraint.

maya validation: Boot the live USB on the ASUS Q503UA. Validate iris GPU init on Skylake. Verify iwlwifi-7265D firmware is present and WiFi connects. Confirm touchpad and audio.

Why It Matters

A from-scratch Linux distribution that can only run on the machine it was built on is a research project. One that boots on hardware it's never seen before is something else — a system with its own identity, capable of existing independently of its origin.

That's what crossed over on May 2nd.

SableLinux is still early. The team is small, the codebase is hand-built, and there's a long list of things that don't work yet. Audio in the live session needs a manual kick. The iris driver needs to land before Intel GPU users get a real experience. There's no installer. maya hasn't booted yet.

But the foundation is real. LFS 12.4-systemd, a full security toolchain, a working Wayland desktop, local AI inference on consumer hardware — all of it compressing into a 6.3GB image that boots on a machine from a decade ago. That's not nothing.

The next phase is getting the ISO into the hands of people who will break it in ways we haven't thought of yet — security researchers, developers, people building on unusual hardware. Early testers who care about what's under the hood. Professional-grade users who will tell us exactly what's wrong.

That feedback loop is what turns a working prototype into a distribution worth using.

The build continues

Jonathan Brown (A.A.Sc., B.Sc) writes about cybersecurity infrastructure, privacy systems, the politics of AI development and many other topics at bordercybergroup.com and aetheriumarcana.org. Border Cyber Group maintains a cybersecurity resource portal at borderelliptic.com . He works from a custom-built Linux platform (SableLinux™) which is currently under development and fully documented at https://github.com/black-vajra/sablelinux.

If you would like to support our work, providing useful, well researched and detailed evaluations of current cybersecurity topics at no cost, feel free to buy us a coffee! https://bordercybergroup.com/#/portal/support