The SableLinux project has moved through one of those release-engineering phases that every serious system eventually encounters: the point where a working artifact exists, but the path that produced it becomes unclear, fragile, or partially broken.
In plain English: we had a USB/install/staging snafu.
The short version is that an earlier working live/install USB had not been backed up at the right time. That left us exposed when the disk-image and file-state situation became damaged enough that we could no longer treat the existing artifacts as clean, reproducible release material. We still had working SableLinux systems, but the exact install-media pipeline had become muddy.
The first recovery attempt was to regenerate a new ISO from the EliteBook installation. That was the right instinct, but the result did not produce a usable new release artifact. At that point, rather than piling more ad hoc fixes onto a confused state, the project effectively paused for a much-needed “beauty rest break” of roughly two weeks.
That break helped.
When work resumed, the focus shifted back to disciplined engineering: verify the running systems, rebuild the live staging process from known-good material, and stop treating one-off rescue steps as a release pipeline. That effort succeeded. A new squashfs live staging artifact was generated, installed to USB media, and used successfully to live-boot and install SableLinux on the ASUS laptop.
That was the major recovery milestone: SableLinux was again able to boot live and perform a real installation from the reconstructed live/install media.
The USB story is not finished. One install USB works, but encryption still needs more testing, and a cloned second USB currently fails on both the ASUS and the EliteBook. Those are real issues, but they are no longer the immediate priority. The systems themselves are running successfully, and the project now has a better path forward than chasing every USB quirk first.
The next phase was repository cleanup.
The SableLinux Git repository had accumulated exactly the kind of clutter that happens during intense system recovery work: old scripts, duplicated notes, book mirrors, temporary artifacts, historical build logs, staging fragments, planning files, and partially obsolete helper material all living too close to the active engineering tree.
The cleanup objective was simple:
Make the repository look like the institutional memory of a professionally maintained source-built distribution, not like the aftermath of a live-fire rescue session.
That cleanup is now complete.
The top-level layout has been rationalized. Historical material was moved into appropriate archive locations. Obsolete helper scripts and artifacts were quarantined or archived. Active scripts were separated from historical scripts. Planning and inventory documents were moved under documentation. The repository layout policy was documented so that future work has a structure to follow instead of relying on memory. The cleanup was synced across the active SableLinux repo, the mounted Kubuntu-side repo, and the GitHub development branch.
Current active branch:
development
Current repo status at checkpoint:
clean, organized, and synced.
With the repository stabilized, the project moved to the next engineering target: QEMU/KVM validation.
The goal is not merely to boot something in a VM. The goal is to validate the live/install process in a controlled virtual environment approximating the newer hardware class before returning to USB-specific problems. Physical laptops are useful for final validation, but QEMU/KVM is the right place to tighten the release process.
Initial inspection confirmed that KVM support is present and usable on the current SableLinux system. /dev/kvm exists, QEMU is installed, and the host CPU exposes Intel VT-x. The older QEMU notes were recovered from a QEMU-TESTING directory, but that directory contained only a small boot-command note file, not a live VM disk or launcher.
The important discovery was under /var/lib/qemu/disks.
There we found the existing SableLinux live test image:
/var/lib/qemu/disks/sablelinux-live-test.img
At first glance, it looked suspicious: a large 115 GiB raw disk image with a relatively small live partition and a lot of unused image space. But read-only inspection showed that the image is structurally useful and should not be deleted.
The image contains:
- an EFI partition
- a live ext4 partition labeled
SABLELINUX /boot/vmlinuz/boot/initramfs-live.img/live/filesystem.squashfs
The squashfs identifies as:
Sable Linux 1.0
It also contains the expected live desktop components:
/usr/bin/sway/usr/bin/swaybar- Sway configuration under
/etc/swayand/home/sable/.config/sway - the installer at
/usr/local/bin/sable-install
That means the live image is a useful baseline. It is not the broken piece.
The likely stale artifact is the old installed VM target:
/var/lib/qemu/disks/sable-install-target.qcow2
That disk was from the earlier VM experiment, the one that had reached a Sway desktop but had an incomplete or outdated state. Rather than delete it outright, the release-engineering approach is to quarantine it and create a fresh target disk for a clean install test.
The first QEMU/KVM live boot test from the preserved live image has now succeeded.
The VM initially landed in the UEFI interactive shell. That was not a SableLinux failure; it simply meant the firmware variable store did not automatically select the fallback EFI bootloader. Manually launching the fallback path from the EFI shell worked:
FS0:\EFI\BOOT\BOOTX64.EFI
After that, the SableLinux live environment booted successfully into the graphical desktop.
Current QEMU/KVM validation state:
- QEMU/KVM host capability verified
- OVMF firmware files present
- old QEMU notes recovered
- stale VM target identified
- existing live image inspected read-only
- live image confirmed to contain kernel, initramfs, squashfs, Sway, swaybar, and installer
- live image successfully booted in QEMU/KVM
- SableLinux live desktop reached successfully
- top bar / desktop environment is visible in the VM
The next task is to create a fresh 64 GiB virtual install target, boot the live image with both disks attached, run sable-install from inside the live VM, and install to the blank target disk. For the first validation pass, encryption will be disabled. That keeps the test focused on the normal install path: partitioning, formatting, squashfs extraction, user creation, GRUB installation, first boot, login, Sway startup, swaybar behavior, and basic networking.
Encryption remains a known follow-up item. It should be tested only after the unencrypted VM install path is clean and repeatable.
The project is now in a much better state than it was during the USB recovery mess. The working systems are intact, the repository has been cleaned and documented, the live image has been verified, and QEMU/KVM testing is underway with a successful live boot already achieved.
This is exactly the direction SableLinux needs to move: away from heroic rescue work and toward reproducible release engineering.
Next milestone:
A clean QEMU/KVM install from the live image to a fresh virtual disk, followed by independent boot of the installed VM.
Jonathan Brown is a cybersecurity researcher and investigative journalist at bordercybergroup.com.
If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.
Member discussion: