[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-----

[Rohan Mithari]

Hi Marek, 

Thanks for the resources you shared — I spent some time going through the storage pool, template, and secondary storage docs to understand how things fit together.
I’ve written down my notes while studying this (mainly around how volumes are separated and how this could map to a read-only + RAM-backed setup for a live environment). Sharing it here: Learnings
From what I understand so far, the key idea seems to be separating the root volume from runtime data — keeping the base system read-only, and routing private/volatile volumes to a RAM-backed pool so that everything remains non-persistent.
While thinking about how this would actually be implemented, I had one doubt regarding the boot sequence:

1.When adapting Fedora’s live boot process for Qubes, at what stage would it make more sense to initialize such a RAM-backed storage pool?

2.Should this be done early inside the initramfs (dracut stage), or slightly later using a systemd service before Qubes starts creating the default VMs?
I’m also trying to get a better sense of how to scope the first milestone for this.

3.Would it make sense to start with something minimal — like just getting Xen and dom0 to boot reliably from a live image, and then bringing up networking (sys-net) and a basic AppVM on top of that?
Also, if there are any smaller issues or parts of the codebase that would be a good starting point to get familiar with things, I’d love to try working on them.

I have started drafting the proposal,any suggestions would you like to give for it.
Thanks again — I’ll continue exploring the build and storage side on the newly setup of Qube on my laptop.

Regards,
Rohan

[Marek Marczykowski-Górecki]

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

On Sat, Mar 21, 2026 at 06:27:41AM -0700, Rohan Mithari wrote:
> Hi Marek,
>

> Thanks for the resources you shared — I spent some time going through the
> storage pool, template, and secondary storage docs to understand how things
> fit together.
> I’ve written down my notes while studying this (mainly around how volumes
> are separated and how this could map to a read-only + RAM-backed setup for

> a live environment). Sharing it here: *Learnings*
> <https://docs.google.com/document/d/10BP0T5n3gEgJS4Wql46hDAvUPjOaj6b1DZPkJqyqYdM/edit?usp=sharing>

Minor note: the "root-cow.img" is part of the "file" storage driver. It
kinda works (it uses device mapper "snapshot" target using root.img +
root-cow.img), but is deprecated. Newer drivers use backend storage CoW
functionality (either thin volumes in LVM, reflink copies on btrfs or
xfs, or snapshots on zfs).
Yes, this part of our documentation is a bit outdated...

> From what I understand so far, the key idea seems to be separating the root
> volume from runtime data — keeping the base system read-only, and routing
> private/volatile volumes to a RAM-backed pool so that everything remains
> non-persistent.

Yes, exactly.

> While thinking about how this would actually be implemented, I had one
> doubt regarding the boot sequence:
>
> 1.When adapting Fedora’s live boot process for Qubes, at what stage would
> it make more sense to initialize such a RAM-backed storage pool?
>

> 2.Should this be done early inside the i*nitramfs (dracut stage)*, or
> slightly later using a *systemd *service before Qubes starts creating the

> default VMs?
> I’m also trying to get a better sense of how to scope the first milestone
> for this.

This is a very good question. The answer might be "both". AFAIR Fedora
live boot creates RAM-backed overlay in initramfs, and this is generally
convenient as requires less system changes. But then, qubes storage
pools might need to be reconfigured (basically creating separate one for
"volative" volumes, and maybe "private" volumes) later during startup
(when qubesd service is already running, but before starting any VM).

> 3.Would it make sense to start with something minimal — like just getting
> Xen and dom0 to boot reliably from a live image, and then bringing up
> networking (sys-net) and a basic AppVM on top of that?

Yes, this is definitely a good idea, and the proposed milestone sounds
good.

> Also, if there are any smaller issues or parts of the codebase that would
> be a good starting point to get familiar with things, I’d love to try
> working on them.

Take a look at "good first issue" label, here is for example one related
to storage pools:
https://github.com/QubesOS/qubes-issues/issues/3261

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/f49358fd-36ca-4da0-9af3-83691de22166n%40googlegroups.com.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmnC0LEACgkQ24/THMrX
1ywL4Qf9GJd8tKFmjs1LF0Muzo/yps3p/uhWC4nPziYv3ep0+mTBCoechUHEpqiH
sVsxuWG/GeuiqyQOWTdY9D4EStCzyA+uWQ2LKXQSftGEUGs9LSpj3aagd2sfm1qh
VT2+zk9TNlWKCOM02eWS9rLb6tERYOhH1hU6Dkx4/DaUyeRrPHTpCXk1UPcz1xy7
6x6N/muB3ASvGreGU9r9GdI+mbq++caIEdYgC0gfgREZhycM3CicNom3gCErSf6F
lK0taUjPWur1kZZpQNeYW+YaAF11rRX3+tUUFxdYWSNYJDFhj8asxkLJTlbNJOka
UzOxKS75fquVIDD9LvnH6uiR7D2nYQ==
=8pw/
-----END PGP SIGNATURE-----

[Rohan Mithari]

Hii,
I wanted to share a quick update on my progress and also ask for some feedback on my proposal.

Over the past few days, I picked up the issue you suggested (#3261) related to qvm-backup-restore. I just opened a PR for it here: https://github.com/QubesOS/qubes-core-admin-client/pull/461. Working on adding support for the destination storage pool override was a great way to get comfortable with the storage pool handling and see exactly how volumes are mapped during a restore. I’m now going through  the surrounding storage flows  and codebase to better understand how to connect this to liveUSB.

Alongside with this I have been working on the proposal for Revive LiveUSB and here is it draft- Drive link   
I would really appreciate review and feedback on it please.

While mapping out the implementation timeline, I had one  question regarding the storage setup based on your last email: Since part of the storage pool configuration might need to happen after qubesd starts, would it make more sense to treat the RAM-backed pool purely as a dynamically added "volatile/private pool" at runtime? Or is it safer to try and integrate it tightly into the early initramfs stage? I’m trying to pin down exactly how much of the storage configuration needs to live in early boot versus what can be handled cleanly within Qubes’ existing abstractions later on.

I’m going to continue exploring these parts of the codebase and looking for other small, relevant issues to tackle in parallel.(suggest if any good issue that I should go through)

Regards,
Rohan 

[Marek Marczykowski-Górecki]

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

On Sun, Mar 29, 2026 at 02:10:25AM -0700, Rohan Mithari wrote:
> Hii,o

Hi,

> I wanted to share a quick update on my progress and also ask for some
> feedback on my proposal.
>
> Over the past few days, I picked up the issue you suggested (#3261) related
> to qvm-backup-restore. I just opened a PR for it here:
> https://github.com/QubesOS/qubes-core-admin-client/pull/461. Working on
> adding support for the destination storage pool override was a great way to
> get comfortable with the storage pool handling and see exactly how volumes
> are mapped during a restore. I’m now going through the surrounding storage
> flows and codebase to better understand how to connect this to liveUSB.
>
> Alongside with this I have been working on the proposal for Revive LiveUSB
> and here is it draft- Drive link

> <https://drive.google.com/file/d/1opoAOSTTC8_aCdbfXyCf8t98evIknBcr/view?usp=drive_link>


Re using fedora-minimal template - note it isn't ready to use out of the
box, needs customization to become useful:
https://doc.qubes-os.org/en/latest/user/templates/minimal-templates.html

A simpler approach might be to just exclude some templates (for example
have just Fedora or just Debian).

I think you'll also need to mention choice of storage driver is use for
different pools. I don't think you need choose specific driver now, but
do include evaluating them in the plan.

> I would really appreciate review and feedback on it please.
>
> While mapping out the implementation timeline, I had one question
> regarding the storage setup based on your last email: Since part of the
> storage pool configuration might need to happen after qubesd starts, would
> it make more sense to treat the RAM-backed pool purely as a dynamically

> added "*volatile/private pool*" at runtime? Or is it safer to try and

> integrate it tightly into the early initramfs stage? I’m trying to pin down
> exactly how much of the storage configuration needs to live in early boot
> versus what can be handled cleanly within Qubes’ existing abstractions
> later on.

That is a good question. Currently there is no support for changing
storage pool of existing qube:
https://github.com/QubesOS/qubes-issues/issues/9216

Well, one can clone into new pool and remove the original, but that's
an overkill. So, I see two options:
1. Implement the above feature and configure storage pools later - after
qubesd starts.
2. Implement creating RAM-backend pool before qubesd starts (might be
harder as standard tools like qvm-pool/qvm-volume require qubesd running
already).

The second approach might require a bit more Live-USB specific steps
(like separately creating specific volumes, as you can't rely on
qvm-volume for that), but may enable moving some of the steps into
image build time (kickstart file?).

The first approach is more elegant (and also useful outside of Live USB
use case), but may be less efficient (boot time and memory usage).

Honestly, at this point I'm not sure which one is better. I'd say to try
to experiment with the first one first (like using qvm-clone workaround
initially) and see how it behaves. If it's good enough (not too slow,
and not too memory hungry), then implement it properly. Otherwise go
with the second one.

> To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/23a8ed0f-3dfa-46d7-a284-4edf5fc32cebn%40googlegroups.com.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmnJOokACgkQ24/THMrX
1ywh+Af+OqYxz8b8mF8sQxwr/fwS4ituL7XiGT02+9ENdC2VkaNhdGa9WF97Cw9T
u6O5Zj3vzDRXHzjoQYBa2Ds8DugXTzA7wIkNWNqtpI0T9mugxIzkxXijmXPEgNLt
RFSjockGnNRWFNHiW8EhIMohk6nF4W65lAkjZ6JpVn/97YRt7ULCUDCBU6xqXNZI
dwImg11+UAIEawXngoNhKbapuHcq4+uf7hWN3SriXGVnAoR/VCquOwdJnh5CfTDP
01ePPEiHxNU7MMCEfvFWgZINpb/lS/d9ZO/VPf4OgVKxyNovkq3MbGP/RjULi1kG
btQ/yyctherxNI+4eeh/81Ja+9TRGg==
=Ou+H
-----END PGP SIGNATURE-----