Updating offline standalone qube

I have a F36 standalone Qube which is not connected to any net qube and I’d like to update to F37. I’m not convinced this is entirely necessary (the qube is, again, not net enabled and it’s only used for writing/editing text documents). Nevertheless…

I found this guide from '13 (which I think may be depreciated) and this recent thread for updating an offline standalone.

When running

sudo qubesctl --show-output --skip-dom0 --target=MYWRITVM state.sls update.qubes-vm

it exits with:

returned non-zero exit status 20.
MYWRITVM:
------------
_error:
       Failed to return clean data
retcode:
       126
stderr:
        Request refused
stdout:

which I presume is because of its disconnection from the Qubes proxy somehow? I’ve tried enabling, separately and together, qubes-update-check, qubes-update-proxy and updates-proxy-setup in settings>services, but those don’t seem to relate to the problem.

Is there a way to keep these up-to-date, and to upgrade-in-place, or is that largely unnecessary?

Thanks in advance,
-ken

How did you create that standalone qube?
qubes-update-check is a service to notify dom0 of available updates.
qubes-update-proxy is a service that provides the tinyproxy service,
so that other qubes can use it.
updates-proxy-setup configures the template/qube to enable updates
accessing the update proxy on another qube over qrexec.

My guess would be that you haven’t created a rule in
/etc/qubes/policy.d/30-user.policy to allow that qrexec call to work.
Look at the relevant lines in 90-default.policy and create your own
policy in 30-user.policy for MYWRITVM

Hmm, it’s easier to setup an F37 qube and making it standalone, isn’t it?
Doing this all the time, because it’s always hard to do an in-place-upgrade for a qube. Means:

  • setting up a new qube for F37 by downloading the F37 template
  • making a qube standalone from that template
  • installing the needed software packs
  • cutting it from the available networks

If you have salted the creation of the original, then you can simply
change two entries - the source template, and the name of the
standalone - before creating the new standalone.
Once the new standalone is created you can qvm-move any data from
the old to the new, before deleting the old.
If you adopt this, then you might like to consider a naming scheme such
as “builder-36”, “builder-37”.

I’m not convinced that is easier than running an in-place upgrade, which
is a common thing to do outwith Qubes.
The important things are to make sure that a full update is run before
all repositories are changed from the old (e.g fed36) to new, before
running the upgrade procedure.
Any specific issues should be covered in the documentation.

I think I have addressed the specific problem that @kenosen reported.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

@unman I don’t suppose qvm-move can clone an entire filesystem, directories and all, to mimic the old standalone? More details below.

The original was created through Create Qube VM as a Standalone, so there’s no template associated with it, but it was based on F36. For all my appVM templates I upgraded in place, no problem.

Creating a new standalone off the F37 template that I do have would be perhaps the easiest, but the files/programs I’d need to move are large and I’m worried about corrupting the software/program in doing so.

I suppose the easiest thing would be to expose the standalone to my VPN qube, upgrade-in-place, disconnect from any netvm and call it a day. I had hoped to never let this one qube (think of it like a standalone vault) touch the net. Alternatively, I’m not certain an upgrade is necessary if it’s running the software/program just fine and it remains disconnected from the web.

Thank you both for the much-appreciated input.

I don’t understand what you mean here.
If you have a Fedora37, you wont want to move *everything under / * -
what would be the point?

As it was created from a F36 template, then you should be able to set it
up to use the normal proxy - no need to expose to the internet at all.
You would need to have the updates-proxy-setup enabled, and (as I
said) create a rule to allow updates over qrexec - the existing rule
only applies to templates. That is standard and works well.

Do you need to update at all? I think so, particularly if you are
working with material from outside. There may be bugs in your software
that expose you , and have been fixed in later versions.
Similarly if you share the documents you produce here with other people.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

I’ll give this a shot. Is this the right direction for the /30-user.policy:

qubes.UpdatesProxy    *     @MYWRITVM         @default    allow

qubes.UpdatesProxy * MYWRITVM @default allow target=UPDATE_QUBE
replace UPDATE_QUBE with the name of the qube running the proxy

Thank you @unman
works as expected

Great - well done.

The important thing on these updates is to make sure that the system is
up to date, and then change all the repositories,including the Qubes
repository, to the new version., Then run an upgrade.
If there are any issues, these should be high lighted in the docs, or in
release announcement.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.