WangLu's Notes

My current daily driver is Fedora Silverblue combined with Firefox. It’s a fantastic setup, but there’s a catch: Fedora websites kept showing up in my address bar suggestions. For example, if I typed “get”, Firefox would immediately suggest “getfedora.com.” It was quite annoying and surprisingly difficult to remove. Today, I finally decided to fix it once and for all. My first thought was to simply remove the fedora-bookmarks package, which introduces these bookmarks in the first place. However, the suggestions were still there! After exploring the Firefox settings, I realized these autocomplete suggestions were coming from saved bookmarks. But I don’t have those bookmarks! By checking the Firefox Browser Console (not the web developer console) and using PlacesUtils , I verified that there were still many hidden bookmarks pointing to Fedora websites. Interestingly, these bookmarks were tagged. While the tags themselves were visible in the standard Firefox bookmark manager, the act...

I’ve been using Fedora Silverblue as my daily driver for a while now. Over time, I’ve fully adopted Flatpak, which I really enjoy using alongside Flatseal. I particularly appreciate how Flatpak gives each application its own isolated directory structure, making backups incredibly straightforward. However, I eventually hit a wall when it came to proprietary GPU drivers for workloads like media decoding, 3D rendering, and running local LLMs. In these scenarios, Flatpak’s runtime abstraction can sometimes become a liability. While this can sometimes be solved by enabling the Flathub repository or installing custom packages, I wanted to avoid that route. After comparing various alternatives, I decided to write my own lightweight application launcher. The Problem Flatpak achieves portability by bundling apps inside standardized runtime environments (like the Freedesktop or GNOME runtimes). While this solves the “dependency hell” of the 2000s, it introduces a subtle friction point for he...

In Part 2 , I got a basic proof-of-concept running: a single headless microVM booting a minimal Debian kernel and forwarding Firefox back to my daily-driver desktop (“Viewer VM”) over VSOCK using Waypipe and PipeWire. It proved the concept, but it was essentially a static, single-instance test rig. To actually live in this setup like I used to in Qubes OS, I needed to turn this prototype into a scalable, multi-domain system. In this post, I’ll walk through the next iteration of the architecture: building a centralized VM lifecycle manager, isolating VMs under dedicated host users, scaling dynamic TAP networks, and running the Waypipe viewer inside a confined nested compositor container. 1. Domain Modeling & Host VM Management In Qubes OS, workloads are categorized into Disposable VMs (DispVMs) for ephemeral tasks and AppVMs for persistent user data, both derived from centralized Template VMs . While Qubes relies on Template VMs to maintain packages across domains, I chose ...

I decided to take the plunge into micro VMs. My goal? To set up a headless micro VM capable of running graphical programs remotely. As a first milestone, I wanted to get Firefox running and smoothly playing videos. (See Part 1 for a breakdown of why I passed on other isolation methods.) Overview At a high level, the concept is simple: I click an icon, and Firefox opens seamlessly on my screen while actually running securely in a VM. This setup is similar to disposable VMs in Qubes OS. When the program closes, the VM is destroyed, leaving absolutely zero trace on the disk. To pull this off, I needed to boot a micro VM with a minimal kernel and disk image, and seamlessly forward both graphics and audio to my daily-driver main VM. The Kernel Unlike standard VMs, micro VMs do not support PCI devices. Instead, they rely on different protocols (like virtio_mmio and virtio_blk ), which the kernel must support natively. Crucially, these drivers must be compiled directly into the kernel...

I’ve really been missing the experience of Qubes OS, where all programs are properly isolated. However, I can’t install it on my daily driver because I use that machine for gaming. Instead, I’ve been exploring ways to approximate that isolation on a standard Linux setup. Firefox Profiles Let’s start with the browser. There are many privacy and security benefits to separating profiles. My general workflow is as follows: I create separate .desktop files to run Firefox with different profiles. Each file uses a unique --name and StartupWMClass= . This prevents the icons from stacking together on the GNOME Panel. I use ImageMagick to tint the icons so I can tell the profiles apart at a glance: magick input.png -colorspace gray -fill "#cc0000" -tint 100 output.png The “new” Firefox profile manager didn’t work well for me. For example, I couldn’t set a default profile for opening external URLs. I eventually had to switch back to the old profile management style. However, whil...

My daily driver setup has been working exceptionally well. If you missed them, you can check out the previous posts for details: Part 1 Part 2 Part 3 Recently, I decided to harden my setup by writing custom AppArmor profiles and nftables rules. During my research, libvirt kept popping up in tutorials. In fact, most “QEMU/KVM” guides simply assume you are using it. Initially, I decided against using libvirt because I wasn’t a fan of its design philosophy. However, I kept hearing that it can automatically generate AppArmor profiles and firewall rules for each VM. Furthermore, this article highlighted several things that libvirt genuinely simplifies. Intrigued, I decided to dive in and get some first-hand experience. The plan was to migrate my existing VM setup (which relies on bare QEMU scripts) to libvirt to see if it was a good fit. I specifically wanted to evaluate the parts of libvirt I was previously skeptical about: Reliance on a highly privileged daemon. Configuration stored...

I have a USB game controller that works flawlessly during gameplay, but it keeps disconnecting and reconnecting every ~40 seconds whenever it is left idle. While it is mostly harmless in practice, it is annoying to see the kernel messages are flooded with messages about the game controller. Many online resources, such as the Arch Wiki , suggest disabling USB autosuspend to fix this. Unfortunately, that didn’t solve the issue in my case. I suspect the controller expects to be continuously polled rather than entering a power-saving state, especially since it immediately tries to reconnect after dropping. Since I primarily use this controller by passing it through to a VM, I needed a way to manually manage its connection state. Here is the workaround that eventually did the trick: Add the following rule to udev . This ensures the controller is ignored by the host system upon connection. ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTR{idProdu...

Now that I have my VMs running, what if I want to switch between them? What if I want to put the VM or the host to sleep, or shut them down? In this post, I’ll discuss a few options. Just a quick overview of my setup: Only one VM is running at a time. All VMs have GPU passthrough, and the GPU is connected to a display. I have a secondary display, which I prefer not to use unless absolutely necessary. See also: Part 1 Part 2 Option 1: Deep Integration with Guest OS Ideally, I could just click on a “Power off and Switch to VM X” menu from within the guest OS. This isn’t difficult to support on the host side: the guest OS could pass the VM name to the host (e.g., via a serial port), and the host would automatically start the next VM when the current one exits. However, I didn’t find an easy way to implement this menu, especially considering I plan to support multiple operating systems. I also couldn’t find a way to prevent the guest from shutting down without providing the next V...

Previously, I decided to set up a headless VM orchestrator for daily driving and gaming. In general, installing a minimal Debian and QEMU is fairly straightforward, but the devil is in the details. Here are my notes on the process. See also: part 1 Overall Setup The machine is a laptop. The built-in display is connected to the iGPU, and an external display is connected to the dGPU. I prefer to use only the external display; the built-in one is rarely used. I have two VMs: one as a daily driver and the other for gaming. Both have GPU passthrough. Only one runs at a time. Resources Reserved for the Host CPU: 1 core, 2 threads. RAM: 2GB (typical usage is around 500MB). Disk: 32GB. The OS only needs ~2GB, but I need extra space for cache, log, OS images, etc. CPU The main QEMU process and IO thread should be pinned to the host CPUs. vCPU threads should be pinned to the CPUs reserved for the VM. CPU pinning cannot be done through QEMU command-line arguments. I had to talk to the QEM...

For years, I've been playing games and doing everything else on the same PC. Hoever, after a recent positive experience with Qubes OS, I no longer feel comfortable keeping my games, passwords, and other stuff all in the same place. Because of this, I decided to change my gaming setup. My requirements are: Performance. Gaming should be functional and playable. Isolation. At a minimum, game binaries should not have access to my other files. Quick Switch. I need to be able to switch between gaming and non-gaming easily. Single Display. All my workflows should be performance well on a single display. I do have a secondary display, but I want to rarely use it. So, here goes my adeventure. Option 1: Dual Boot This is the classic solution, which sounds boring but almost always works. Performance: Good. All operating systems have direct access to physical hardware. Isolation: OK-ish, each OS technically has access to all data from other OSes. Disk encryption and Secure Boot can mitigate th...

After a routine system update and an unfortunate hang that required a hard reset, my Linux machine refused to boot. Instead of the familiar login prompt, I was greeted by a cryptic GRUB error:  error: no cryptodisk module can handle this device. My setup uses LUKS2 + LVM. From the GRUB rescue shell, I could actually decrypt the LUKS container. But once decrypted, GRUB completely failed to detect any LVM volumes. It simply acted as if the LVM structure didn't exist. Meanwhile, if I boot it from a Live Rescue USB, everything worked perfectly. I could open the LUKS container, and the volume group appeared immediately. Tools like  vgck  and  pvck  reported no issues. After a length discussion with AI, eventually I found the magical commands: vgcfgbackup -f lvm_backup.txt <vg_name> vgcfgrestore -f lvm_backup.txt <vg_name> After running these commands and rebooting, GRUB recognized the LVM volumes immediately, and I was back in my system. Supposedly this f...

I recently tried to install Qubes OS alongside an existing Windows installation. It turned out to be surprisingly difficult—way harder than my last attempt—likely due to a combination of my encrypted  /boot  setup and older hardware. Here are some notes from the process. Shrinking an NTFS Volume I needed to free up some space from a Windows NTFS volume. Normally, this just takes a few clicks in Disk Management. This time, however, Windows reported a "shrinkable volume" that was suspiciously small. Following  this answer , I tried the standard fixes: Disabled hibernation ( powercfg /h off ) Disabled the pagefile Disabled system protection This increased the shrinkable volume a bit, but nowhere near the actual free space left on the partition. Digging into the Windows Application logs in Event Viewer, I finally found the culprit:  The last unmovable file appears to be: \$Mft::$DATA . It turns out  $Mft  is a special block in NTFS that cannot be easily moved, ...

I've been running Qubes OS on Machine A alongside Windows for a while. My setup involved storing the unencrypted  /boot  partition and the LUKS header on an external USB drive. Recently, I planned to install Qubes on Machine B, also in a dual-boot configuration. However, the complexity jumped significantly: Machine B has Secure Boot enabled because BitLocker requires it. On previous installs, I grew tired of toggling Secure Boot in the BIOS every time I switched operating systems. I only have one USB drive. Managing separate  /boot  partitions for two different Qubes installations on a single thumb drive is messy. After some experimentation, I found a way to solve both problems. Sharing One USB Drive for Multiple Qubes Installations The solution is elegant: Don't store  /boot  on the USB drive. Instead, move  /boot  to the encrypted internal disk partition. The USB drive's only job is to unlock that partition and hand over control to the system. O...

After writing a Nonogram solver, I decided to tackle a Sudoku solver to practice Rust. My goal wasn't just to support classic Sudoku rules, but also to handle variants like Thermometer, Arrow, and Cage etc. 1. Brute Force It is fairly easy to write a brute force or backtracking algorithm. This approach is sufficient for most classic Sudoku puzzles, but it becomes unbearably slow as soon as variant rules are introduced. I considered this step a warmup—a baseline to improve upon. 2. Constraint Propagation Here, I tried to introduce "logical thinking" to the algorithm. I used  u16  as a bitmask to represent the possible values of a cell. Whenever a cell's state changes (due to guessing, backtracking, or propagation), the algorithm consults all constraints to eliminate impossible candidates. While Nonogram is technically an NP-Complete problem, in practice, my constraint-propagation solver (without guessing) can solve almost all puzzles found online. I’ve only seen one ex...

I've been experimenting with Qubes OS on my new laptop and wanted to share some notes on the experience. Hardware Overall, Qubes OS works quite well on my hardware. Aside from typical issues like deep sleep, speaker performance, and touchpad scroll speed, the experience has been smooth. I particularly like that I can boot directly from a microSD card. This allowed me to move the  /boot  partition to the card while completely disabling USB access in  dom0  for better security. Detached  /boot  and LUKS Header Moving  /boot  and the LUKS header to a microSD card is a fun project, but it has some drawbacks: I have to remember to mount  /boot  before updating  dom0 . The system won't shut down properly if I forget to unmount  /boot . Testing Qubes OS 4.3 rc3 I decided to test the Qubes OS 4.3 rc3 release by performing an in-place upgrade. Unfortunately, the system failed to boot afterward. dracut  Issues After the upgrade, the...