Preload disposables only when their net qube is running

[Minimalist73]

The problem you're addressing (if any)

Currently, the preloaded disp qubes feature starts new disp qubes at boot, which starts up all the service qubes in the chain until the one that is supposed to be used. I usually just keep sys-usb for autostart, but the preloaded qubes also start sys-net and all the other sys-* qubes that I use in-between.

The solution you'd like

When preloading disp qubes, check to see if their net qube is running. If not running, allow them to not be created until it is. Disp qubes without a net qube can be preloaded without issues.

The value to a user and who that user might be

It would give the following benefits:

• Stop service qube from being started automatically, even if they aren't set to start automatically when booting.
• Keep a clean system at boot without a lot of qubes starting at the same time.
• Only provide users the preloaded disp qubes they need at the moment.

Completion criteria checklist

No response

[ben-grande]

When preloading disp qubes, check to see if their net qube is running. If not running, allow them to not be created until it is. Disp qubes without a net qube can be preloaded without issues.

I haven't talked with others to know if they think it is a good idea. I think it can be confusing to users whey they see some preloads have been autostarted and others not. The value of implementing a feature flag in this case, might not be very great, considering the solution below:

To solve your immediate case of:

• Stop service qube from being started automatically

systemctl disable qubes-preload-dispvm

This will prevent every preload from autostarting.

Another option is to copy /usr/lib/qubes/preload-dispvm to a new path, edit the systemd unit to use a drop-in directory to modify the ExecStart to use the new script path. Finally, edit the preload-dispvm script to only start qubes with with the netvm attribute before exec_args lines. This is going to be an unsupported configuration.

I think systemctl disable might suit your needs.

[Minimalist73]

Thanks for the answer @ben-grande and good job for this feature!

Using systemctl disable qubes-preload-dispvm will prevent preloading at boot. However, I'll still need to manually create a disposable qube for each disposable template I want preloaded for the current session, right?
If this is correct, then I'll have to get a long disposable qube start for every session and for every disposable template, which kind of defeats the purpose, at least initially.

I suppose the current implementation assumes that users are using sys-firewall as their main networking qube. However, as seen in the Qubes forum, many users use VPNs or other services with probably different disposable templates linked to them, which could lead to them all being brought up by mistake if preloading is enabled for them. A warning about this behavior should be included somewhere. When I installed r4.3, my first move was to set a few of my most-used disposables to preload.

[ben-grande]

However, I'll still need to manually create a disposable qube for each disposable template I want preloaded for the current session, right?

Disabling the script doesn't prevent from running it manually:

systemctl start qubes-preload-dispvm

I suppose the current implementation assumes that users are using sys-firewall as their main networking qube.

It makes no assumptions about that.

However, as seen in the Qubes forum, many users use VPNs or other services with probably different disposable templates linked to them, which could lead to them all being brought up by mistake if preloading is enabled for them. A warning about this behavior should be included somewhere. When I installed r4.3, my first move was to set a few of my most-used disposables to preload.

Please share your concern's on the qubes-devel mailing list and give more details, I am not sure I understood the issue.

[Minimalist73]

I just checked the contents of the qubes-preload-dispvm service and realized it's a oneshot script. I thought it was used to keep preloading disposable qubes, but it's only used during startup. Is it supposed to be enabled or disabled by default?

If I understand the preloading system correctly, if a user decides to disable the service, they will need to manually start at least one disposable for the preload feature to start preloading new disposable?

[ben-grande]

I just checked the contents of the qubes-preload-dispvm service and realized it's a oneshot script. I thought it was used to keep preloading disposable qubes, but it's only used during startup. Is it supposed to be enabled or disabled by default?

Supposed to be enabled by default:

• Preloaded disposables don't automatically start on r4.3-rc1 #10146

If I understand the preloading system correctly, if a user decides to disable the service, they will need to manually start at least one disposable for the preload feature to start preloading new disposable?

However, I'll still need to manually create a disposable qube for each disposable template I want preloaded for the current session, right?

Disabling the script doesn't prevent from running it manually:

systemctl start qubes-preload-dispvm

[marmarek]

The use case presented feels like it's simply a bad idea to enable preloading disposables that are connected to a netvm that is not supposed to be running at some times. Note it's not only about the initial start - if you have preloaded disposables, it will also cause issues when you want to shutdown that netvm (or maybe switch to another - see #10173). The idea of preloading disposables is to have it available (almost) instantly when the feature is enabled for given disposable template. It is not "have it available (almost) instantly, but only if several extra conditions are met". So, automatically starting relevant netvms for reloaded disposables is intentional, and if you want to avoid that, simply don't enable preloading for those disposables.

And if you really want to combine the two, you can enable preloading after you start your netvm (and disable it later), it's a single command call, you can make a key shortcut for that or something.

[github-actions]

This issue has been closed as "declined." This means that the issue describes a legitimate bug (in the case of bug reports) or proposal (in the case of enhancements and tasks), and it is actionable, at least in principle. Nonetheless, it has been decided that no action will be taken on this issue. Here are some examples of reasons why an issue may be declined:

• No solution can be found.
• The proposed action is not possible.
• The proposed action would weaken security to an unacceptable degree.
• The proposed action would be too costly (in time, money, or other resources) relative to the benefits it would provide.
• The proposed action would make some things better while making other things worse, and the trade-off is not worthwhile.

These are just general examples. If the specific reason for this particular issue being declined has not already been provided, please feel free to leave a comment below asking for an explanation.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "declined" is not accurate, please leave a comment below saying so, and the Qubes team will review this issue again. For more information, see How issues get closed.