Error on updating dom0: Command '['sudo', 'qubesctl', '--dom0-only', '--no-color', 'pkg.upgrade', 'refresh=True']' returned non-zero exit status 1

Building on my personal theme of “Why does Qubes OS hate me specifically so much” I recieved the following error while updating Dom0 today:

Updating dom0

Error on updating dom0: Command '['sudo', 'qubesctl', '--dom0-only', '--no-color', 'pkg.upgrade', 'refresh=True']' returned non-zero exit status 1.
[ERROR   ] Command 'systemd-run' failed with return code: 1
[ERROR   ] stderr: Running scope as unit: run-rb426c1a2c062406987ac00afd070b37f.scope
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Running '/usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui '--exclude=qubes-template-*' '--quiet' '-y' '--clean' '--action=upgrade'' on sys-firewall
sys-firewall: command failed with code: 1
[ERROR   ] retcode: 1
Error running 'pkg.upgrade': Problem encountered upgrading packages. Additional info follows:

changes:
    ----------
result:
    ----------
    pid:
        8175
    retcode:
        1
    stderr:
        Running scope as unit: run-rb426c1a2c062406987ac00afd070b37f.scope
        Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
        Running '/usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui '--exclude=qubes-template-*' '--quiet' '-y' '--clean' '--action=upgrade'' on sys-firewall
        sys-firewall: command failed with code: 1
    stdout:

I’d love to tell you specifically what update that was and assign some kind of version number to it, but I have no idea where to find that information, so the best I can tell you is it was definitely released this week, as I’m pretty punctual with dom0 updates.

Since the definition of insanity is doing the same thing over and over again and expecting a different result, and i’m rapidly getting there, I decided to try the Dom0 update again and… Success! … I think?

Updating dom0

local:
    ----------
    kernel:
        ----------
        new:
            1000:5.15.103-1.qubes.fc32,1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
        old:
            1000:5.15.81-1.fc32.qubes,1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
    kernel-devel:
        ----------
        new:
            1000:5.15.103-1.qubes.fc32,1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
        old:
            1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
    kernel-modules:
        ----------
        new:
            1000:5.15.103-1.qubes.fc32,1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
        old:
            1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
    kernel-qubes-vm:
        ----------
        new:
            1000:5.15.103-1.qubes.fc32,1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
        old:
            1000:5.15.81-1.fc32.qubes,1000:5.15.89-1.fc32.qubes,1000:5.15.94-1.qubes.fc32
    python3-qubesdb:
        ----------
        new:
            4.1.16-1.fc32
        old:
            4.1.15-1.fc32
    qubes-db:
        ----------
        new:
            4.1.16-1.fc32
        old:
            4.1.15-1.fc32
    qubes-db-dom0:
        ----------
        new:
            4.1.16-1.fc32
        old:
            4.1.15-1.fc32
    qubes-db-libs:
        ----------
        new:
            4.1.16-1.fc32
        old:
            4.1.15-1.fc32
    qubes-mgmt-salt-base:
        ----------
        new:
            4.1.5-1.fc32
        old:
            4.1.4-1.fc32 

As you can see the update message just sort of abruptly stops, rather then ending with any kind of reassuring conclusion like i’m used to seeing from fedora updates. So i’m not 100% sure if attempt number 2 was a complete success or not. And I can’t remember if that’s normal. After all any subsequent updates just receive this:

Updating dom0

local:
    ----------

Which my stressed mind was sure wasn’t normal, but it’s actually a completely normal response to no updates being available.

Anyway, sorry for rambling. Basically I just want a second opinion on if my systems “probably ok” or not. It looks like the update went through the second time and the system rebooted fine, but this the first time a dom0 update has ever failed for me so i’d love some reassurance that I should just carry on like normal.

This is a success.
Indeed, at the moment, when the dom0 update succeeds, it looks like this, without summary.

There is a work in progress.

2 Likes

Thanks szz9pza! A delayed response my side but I just wanted to emphasize how much I appreciate your reply. My seemingly constant battle with glitches and “quirks” has really worn down my confidence in Qubes OS recently. I know I’m not owed any responses and people like you taking the time helps restore my faith that I haven’t made a terrible decision.

Sorry if it’s wrong to revive this older thread. But the OP’s error message is just the same (except the PID and the “scope” part) with the one I got trying to update dom0.
Relevant information is:

  1. I have Debian template as default. Debian-based DVM is the template of sys-firewall.
  2. I recently upgraded to Debian 12: installed the official template, substituted 11 with 12 for all qubes and their templates. Everything had been fine. As far as I remember, I updated all qubes, including dom0, afterwards. It’s just today that I got the error. Even though I didn’t use the system much after the upgrade. The old Debian 11 template was deleted, by the way
  3. The problem with updating dom0 persists. It can be solved with sys-whonix being set for dom0 updates (instead of sys-firewall). I did manage to update dom0 this way. Reverting the setting back to sys-firewall reproduces the error.

Any ideas where to dig next? In order to make the update work with sys-firewall?
Perhaps, I can create some disposable templates based on Fedora and use them as templates for sys-firewall, and this may fix it. Haven’t tried.

Other qubes got updated just fine.

This looks to my recent issue?

1 Like

Got it. Thank you!
All I did to the DVM template was supposed to be replacing Debian 11 with Debian 12 as its template. Now I assume there could be something else altered in its configuration.
Would you please share the configuration of your DVM (which is the base of your sys-firewall)?

So I have it partly fixed. The quirk was debian-12-dvm. Why? It is yet to find out. That’s the matter. What I did was restoring my backup of debian-11 template, debian-11-dvm. Refreshed the apps. Then I assigned the template in sys-firewall settings to debian-11-dvm. And it fixed dom0 updates via sys-firewall.

So now I wonder:

  1. Did I make mistakes while converting my debian-11-dvm to 12?
  2. Is the error related to Debian 12?

In this regard, does anyone use Debian as default distro and upgraded everything to 12? No error of this kind has appeared so far?

It’s a partial fix, because I didn’t intend to keep updating the old stable Debian template, and I still haven’t found out the reason behind the error.

Are you using the cacher?

If so you will indeed run into a problem with Debian 12 once you start using a debian 12 cacher, but it’s fixable.

Apt-cacher-ng and debian-12 testing - User Support / General - Qubes OS Forum (qubes-os.org)

If you’re not using the cacher…well, it’s something else then, and I’ve not run across your issue.

One thing I did do differently was to rebuild all of my templates from scratch starting with debian-12-minimal, rather than trying to upgrade debian-11 based stuff in place.

1 Like

Thank you for your reply!
I checked whether my Debian 12 template qube had apt-cacher-ng-service. It didn’t. Didn’t check the DVM based on it. But it should follow the same pattern that is set in its template, which is Debian 12, right?

All I can say is, I did a clean installation of Debian 12 template from the stable repo “as-is”. I neither added nor enabled any services. Then I set it as the new template in all qubes (including system qubes) that had previously been based on Debian 11 template. That’s it.

So I didn’t manage to figure out what had gone wrong with the replacement of templates. I compared the settings of both debian-11 vs debian-12 as well as debian-11-dvm vs debian-12-dvm. They are the same. I didn’t install any software other than that in Debian 11. Neither did I add and enable any services on my own. So I rather think this could be related to differences between the two releases. At least the Qubes templates of the two differ significantly.