[GSoC 2026] Intro - Revise Qubes Live USB Project

[Rohan Mithari]

Hi Marek, Frédéric, and the Qubes team,

My name is Rohan Mithari. I’m an Electrical Engineering undergrad, and I’d love to work on the "Revive Qubes Live USB" project for GSoC 2026.

I’ve been reading through issues #1552 and #1965, along with the recent mailing list and forum discussions. The recent threads really helped clarify the real-world constraints of this project. It makes complete sense that sys-usb must be excluded so it doesn't accidentally unmount the live boot drive. I also appreciate the reality check on memory limits—shifting the baseline to 16GB (while maybe experimenting with 8GB) feels like a much more practical goal than fighting the old 4GB target.

I also found the forum discussion about running dom0 entirely in RAM for a non-persistent, amnesic boot really fascinating. Figuring out how to balance the Xen boot sequence with the memory overhead of multiple VMs seems like the biggest, but most interesting, challenge here.

I am currently setting up my local qubes-builder environment to get hands-on, but I have a few quick questions to help focus my proposal:

1. Old Scripts: Are the old R3.2 live-build scripts still kept somewhere in the repositories as a reference, or is it better to start completely fresh with the current infrastructure?

2. The End Goal: Is the main vision for this Live USB to be a quick hardware-compatibility tester (and potential installer), or is the team hoping to build a fully functional, privacy-focused temporary OS?

3. Past Roadblocks: When it comes to managing the memory overhead, are there any specific storage setups (like certain device-mapper configs) or past attempts you highly recommend I look into?

Thanks for your time and for all the great information already shared on the list. I look forward to learning more and putting my proposal together!

Best regards,

Rohan Mithari

[Marek Marczykowski-Górecki]

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

On Mon, Mar 16, 2026 at 06:06:24AM -0700, Rohan Mithari wrote:
>
>
> Hi Marek, Frédéric, and the Qubes team,
>
> My name is Rohan Mithari. I’m an Electrical Engineering undergrad, and I’d
> love to work on the "Revive Qubes Live USB" project for GSoC 2026.
>

> I’ve been reading through issues *#1552 *and *#1965*, along with the recent

> mailing list and forum discussions. The recent threads really helped
> clarify the real-world constraints of this project. It makes complete sense

> that *sys-usb* must be excluded so it doesn't accidentally unmount the live

> boot drive. I also appreciate the reality check on memory limits—shifting

> the baseline to 16GB (while maybe experimenting with *8GB*) feels like a

> much more practical goal than fighting the old 4GB target.
>
> I also found the forum discussion about running dom0 entirely in RAM for a
> non-persistent, amnesic boot really fascinating. Figuring out how to
> balance the Xen boot sequence with the memory overhead of multiple VMs
> seems like the biggest, but most interesting, challenge here.
>
> I am currently setting up my local qubes-builder environment to get
> hands-on, but I have a few quick questions to help focus my proposal:
>

> 1.
>
> *Old Scripts:* Are the old R3.2 live-build scripts still kept somewhere

> in the repositories as a reference, or is it better to start completely
> fresh with the current infrastructure?

If you really want, they are still in
https://github.com/QubesOS/qubes-installer-qubes-os/, see "iso-liveusb"
make target. But I'm pretty sure they are completely defunct, and it's
probably a better idea to start with looking what Fedora (or other
distribution) uses nowadays for creating live image.

> 2.
>
> *The End Goal:* Is the main vision for this Live USB to be a quick

> hardware-compatibility tester (and potential installer), or is the team
> hoping to build a fully functional, privacy-focused temporary OS?

This is a very good question. I'd say lets focus on the former first,
it's a more realistic goal.

> 3.
>
> *Past Roadblocks:* When it comes to managing the memory overhead, are

> there any specific storage setups (like certain device-mapper configs) or
> past attempts you highly recommend I look into?

Past attempts were before qubes had extensible storage pools, and all VM
images were stored in (sparse) files. I'd recommend with starting
exploring what storage pool would be best here. See here about
alternative storage pools:
https://doc.qubes-os.org/en/latest/user/advanced-topics/secondary-storage.html
Note, that different VM volumes can be stored in different storage
pools. Especially interesting may be configuration when root volume is
set to read-only (see qvm-volume tool), and volatile+private volumes are
stored on a separate (in-ram) pool.
You may want to look at
https://doc.qubes-os.org/en/latest/developer/system/template-implementation.html
the backend part is rather outdated (it consider just files and
dm-snapshot), but the in-VM part is rather similar.
For a more up to date documentation of the backend part, take a look at
https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-storage.html

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmm4vLYACgkQ24/THMrX
1yxVfAf/X9B9n/zuWQb/nvcxLzU6+NrTP89dSFHZikID3aQ0H53kj0Hz+BO+eFS4
LerNgfD3ybVgYYCr9mIhUPl9n8aoBDKDiZm6tecpniYhIBpyQBI37FcNvJNCJZ8p
BKZ/BSB+XMzLxc7DWjmGRkLErtSs9QVKto6BSQlKMwsYVwTguOuBavdsEjaHm3Th
0bsWbWphD+zs574YF02+BZXzxq1bdGN0cStC75nqebEhUnBzxpcb5C6XnWilp9Jb
ollw4Kw8PebaRpgcpjhDylPDDJgeLrjB7SncL38iu+nuxLm88XLL1VE8ZFYDsk7T
Z3eWw9WaHJ1GJ4TJgVuCCOeJLZicmQ==
=0KZA
-----END PGP SIGNATURE-----