[GSOC 2026] - QUBES LIVE USB PROJECT

[ISHWAR KUMAR]

Introduction

The Qubes Live USB distribution is currently out of date and based on the older Qubes 3.2 architecture. In previous versions, the entire suite of default Qubes OS virtual machines was packed into the image, exceeding the capacity of a standard 16GB thumb drive. Furthermore, live systems are notoriously prone to memory exhaustion because all write operations across the OS accumulate in a RAM-backed Copy-on-Write (CoW) overlay. Qubes OS—which requires running Xen, dom0, sys-net, sys-firewall, and multiple AppVMs concurrently—exacerbates this issue due to extreme memory pressure, making it nearly impossible to operate on constrained hardware (like a 4GB RAM machine) without triggering the OOM killer.

The goal of this project is to revive the Qubes Live USB project, modernize its build scripts for current Qubes OS releases, dramatically compress its disk and memory footprint, and explore unifying the Live USB with the official installer. My solution introduces a localized, highly-optimized initramfs boot sequence using zram and Device-Mapper snapshots (to drastically lower the RAM overhead of CoW) and prunes the template roster to only essential minimal environments, ensuring a smooth and responsive live operating experience.

Project goals
Deliverables for this GSoC term:

• Modernize Build Scripts: Update and fix the live build scripts to work with the latest Qubes OS version and the qubes-builder infrastructure.
• VM Portfolio Selection: Adjust the set of included VMs and templates (e.g., stripping down to minimal templates like fedora-minimal or debian-minimal) ensuring they fit comfortably on an 8GB/16GB drive.
• Storage & Memory Optimization (The Core Goal): Modify the early boot startup script to mount critical directories using highly optimized CoW (device-mapper snapshots) and tmpfs. Explicitly disable unnecessary logging and I/O to actively suppress memory growth.
• Resource Constraint Target: Successfully boot dom0, sys-net, sys-firewall, and two lightweight AppVMs on a physical machine with strictly 4GB of RAM without exhausting memory.
• Live Installation Prototyping: Research the feasibility of installing Qubes OS directly from this Live OS session (running the Anaconda installer within dom0) and implement it if feasible.

What I will not do:

I will not be rewriting the Xen hypervisor or modifying the core security isolation model of Qubes; the focus remains strictly on the surrounding live boot infrastructure, filesystem abstractions, and packaging optimization. Implementation.This project addresses several complex architectural layers of the Qubes stack. To achieve the goals above, I propose the following technical implementations:

1. Build System & VM Selection: I will integrate the live build process cleanly into qubes-builder. Instead of packaging the full suite of standard Qubes templates, the Live OS will pull fedora-minimal or debian-minimal templates. I will write a custom Salt state module specific to the Live USB build that prunes unneeded packages, strips debug symbols, and natively reduces the base image size.

2. Boot Sequence and Xen Hypervisor Tuning: During boot (via GRUB/UEFI to initramfs), Xen must be initialized prior to the Linux kernel (dom0). I will ensure the Xen boot parameters (dom0_mem and dom0_max_vcpus) allocate just enough resources to dom0 (e.g., forcing a strict 1024MB limit) to ensure sufficient logical RAM is left exclusively for the hardware-emulated AppVMs.

3. Advanced Memory & CoW Management (The Unique Approach): To safely squeeze an entire Qubes environment into 4GB of RAM, we must prevent the CoW layer from saturating system memory:

• ZRAM-Backed Device-Mapper Snapshots: For volatile VM storage pools (.img files and AppVM /rw segments), I will utilize device-mapper snapshots over a zram upper-layer block device. By using compressed RAM (zram) explicitly for the CoW layer, we can comfortably achieve a 2.5x to 3x compression ratio for written blocks, substantially extending the lifetime of the live system before memory exhaustion.
• Overlayfs Application: I will utilize overlayfs for standard root filesystem modifications in dom0, isolating it from the heavy block-level operations in the VMs.
• Log Suppression Protocols: I will create a systemd preset invoked automatically only on live boots that remounts /var/log entirely in RAM, configures journald with a strict RuntimeMaxUse=16M limit, and masks rsyslog. I will also disable crash dumps and verbose module loading.

4. Unified Installer Architecture (Stretch/Research Goal): I will design the Live USB bootline to accept a target environment toggle. To allow installation from the Live UI, I will investigate exposing a calibrated block device map to the Anaconda installer running within dom0. This would allow Anaconda to clone the read-only squashed system onto the user's permanent local disk, adjusting UUIDs and regenerating the initramfs natively prior to the first real system boot.

About me

Name: Ishwar Kumar

I am an undergraduate pursuing computer science and linux enthusiast focusing on privacy. I also work in application security.

Thanks

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Mar 14, 2026 at 11:20:24AM -0700, 'ISHWAR KUMAR' via qubes-devel wrote:
> Introduction
> The Qubes Live USB distribution is currently out of date and based on the
> older Qubes 3.2 architecture. In previous versions, the entire suite of
> default Qubes OS virtual machines was packed into the image, exceeding the
> capacity of a standard 16GB thumb drive. Furthermore, live systems are
> notoriously prone to memory exhaustion because all write operations across
> the OS accumulate in a RAM-backed Copy-on-Write (CoW) overlay. Qubes
> OS—which requires running Xen, dom0, sys-net, sys-firewall, and multiple
> AppVMs concurrently—exacerbates this issue due to extreme memory pressure,
> making it nearly impossible to operate on constrained hardware (like a 4GB
> RAM machine) without triggering the OOM killer.
>
> The goal of this project is to revive the Qubes Live USB project, modernize
> its build scripts for current Qubes OS releases, dramatically compress its
> disk and memory footprint, and explore unifying the Live USB with the
> official installer. My solution introduces a localized, highly-optimized
> initramfs boot sequence using zram and Device-Mapper snapshots (to
> drastically lower the RAM overhead of CoW) and prunes the template roster
> to only essential minimal environments, ensuring a smooth and responsive
> live operating experience.
>
> Project goals
> Deliverables for this GSoC term:
>

> - Modernize Build Scripts: Update and fix the live build scripts to work

> with the latest Qubes OS version and the qubes-builder infrastructure.

> - VM Portfolio Selection: Adjust the set of included VMs and templates

> (e.g., stripping down to minimal templates like fedora-minimal or
> debian-minimal) ensuring they fit comfortably on an 8GB/16GB drive.

> - Storage & Memory Optimization (The Core Goal): Modify the early boot

> startup script to mount critical directories using highly optimized CoW
> (device-mapper snapshots) and tmpfs. Explicitly disable unnecessary logging
> and I/O to actively suppress memory growth.

I think you implicitly said it already, but worth mentioning: currently
booting from USB is not compatible with running sys-usb, so sys-usb
should be excluded.

> - Resource Constraint Target: Successfully boot dom0, sys-net,

> sys-firewall, and two lightweight AppVMs on a physical machine with
> strictly 4GB of RAM without exhausting memory.

4GB of total memory is not a realistic goal nowadays. The minimum
requirements for non-live installation is 6GB, and in practice it's
barely usable even then. I'd say a more realistic goal would be to fit
it all in 16GB physical memory, but if you manage to also work with 8GB,
I would be impressed :)

> - Live Installation Prototyping: Research the feasibility of installing

> Qubes OS directly from this Live OS session (running the Anaconda installer
> within dom0) and implement it if feasible.
>
>
> What I will not do:
> I will not be rewriting the Xen hypervisor or modifying the core security
> isolation model of Qubes; the focus remains strictly on the surrounding
> live boot infrastructure, filesystem abstractions, and packaging
> optimization. Implementation.This project addresses several complex
> architectural layers of the Qubes stack. To achieve the goals above, I
> propose the following technical implementations:
>
> 1. Build System & VM Selection: I will integrate the live build process
> cleanly into qubes-builder. Instead of packaging the full suite of standard
> Qubes templates, the Live OS will pull fedora-minimal or debian-minimal
> templates. I will write a custom Salt state module specific to the Live USB
> build that prunes unneeded packages, strips debug symbols, and natively
> reduces the base image size.
>
> 2. Boot Sequence and Xen Hypervisor Tuning: During boot (via GRUB/UEFI to
> initramfs), Xen must be initialized prior to the Linux kernel (dom0). I
> will ensure the Xen boot parameters (dom0_mem and dom0_max_vcpus) allocate
> just enough resources to dom0 (e.g., forcing a strict 1024MB limit) to
> ensure sufficient logical RAM is left exclusively for the hardware-emulated
> AppVMs.
>
> 3. Advanced Memory & CoW Management (The Unique Approach): To safely
> squeeze an entire Qubes environment into 4GB of RAM, we must prevent the
> CoW layer from saturating system memory:
>

> - ZRAM-Backed Device-Mapper Snapshots: For volatile VM storage pools

> (.img files and AppVM /rw segments), I will utilize device-mapper snapshots
> over a zram upper-layer block device. By using compressed RAM (zram)
> explicitly for the CoW layer, we can comfortably achieve a 2.5x to 3x
> compression ratio for written blocks, substantially extending the lifetime
> of the live system before memory exhaustion.

> - Overlayfs Application: I will utilize overlayfs for standard root

> filesystem modifications in dom0, isolating it from the heavy block-level
> operations in the VMs.

> - Log Suppression Protocols: I will create a systemd preset invoked

> automatically only on live boots that remounts /var/log entirely in RAM,
> configures journald with a strict RuntimeMaxUse=16M limit, and masks
> rsyslog. I will also disable crash dumps and verbose module loading.
>
> 4. Unified Installer Architecture (Stretch/Research Goal): I will design
> the Live USB bootline to accept a target environment toggle. To allow
> installation from the Live UI, I will investigate exposing a calibrated
> block device map to the Anaconda installer running within dom0. This would
> allow Anaconda to clone the read-only squashed system onto the user's
> permanent local disk, adjusting UUIDs and regenerating the initramfs
> natively prior to the first real system boot.

Overall looks good. What might be a good idea is to include also some
proposed timeline, to ease monitoring if project is on track.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmm3aeYACgkQ24/THMrX
1yzWMAf/ckNic0hgacDlScgISuZkdvVPWeuZk9vjEdgchkaw+u6NbalV4sC4IFwm
yrbsyUhUWKso4XzzB4ZDHbLVA8uBvDhpLJrb9JDSYflQYCTiO3UOtlSxtpLMEI5a
z7qxm4c7w9VOOdKv99XfJguuZROK72QbS5YufxShy0HOjexVZPO8gTQlmjZzbHfY
6LcpZ0R8N7u7fCwIXY9KT5grZtk8APZdv0XrYm5yE7OjId4WoQ07uxHiXLV5ieBW
C0/LplzftTA9XW7yb7iqo+CuvksooYUvBYn2Ze1+gUAXukUfo7Cnhx3+hvHv81a0
uspPI27i4e1L1XKFD8etpRnbyj+BGg==
=ZUfw
-----END PGP SIGNATURE-----