Root access fails on templates, causing qubes-dist-upgrade error

ephile · January 17, 2026, 12:43am

A few, but not all, of my debian templates failed to update in the Qubes Update manager, each with the following error message:

Updating <debian-13-template> ERROR (exception Command 'cat > /run/qubes-update/agent.tar.gz' returned non-zero exit status 1.)

I’ve also lost terminal root access to (only) these templates. Since qvm-run -u root <debian-13-template> xterm opens the terminal as user and not root, but works fine on the templates that are still behaving normally! Trying qvm-console-dispvm --autostart <debian-13-template> however works fine as root.

Interestingly, restoring one of the affected templates from backup results in the same behavior.

Not sure where to go from here since I was able to open xterm as user (and the console as root) in the affected templates. Seems to be correlated with a dom0 update yesterday.

ephile · January 17, 2026, 1:55am

Progress…

sudo qubes-dist-ugrade --releasever=4.3 --template-standalone-upgrade

tried to upgrade exactly the templates that are having update issues. So failure to run this script is probably the root cause of the problem (been awhile, so I forget if I ever ran this step). Except that my .bash_history shows that I did run the script (r4.3-rc4 at the time).

New problem however is that this process now fails to upgrade these templates because the script requires root permissions.

parulin · January 17, 2026, 8:27am

I can reproduce that with a template cloned from debian-12-minimal and restored from Qubes 4.2. I don’t remember if I ranqubes-dist-upgradeafter restoring it (you need to do that after restoring a template from a previous version), but this is what I get:

----> Upgrading debian-12-disks-minimal...
ERROR: This script must be run with root permissions
+ [[ 1000 -ne 0 ]]
+ echo 'ERROR: This script must be run with root permissions'
+ exit 1
ERROR: A general error occurred while upgrading debian-12-disks-minimal (exit code 1).

ephile · January 17, 2026, 1:01pm

I was able to reproduce the same error on a freshly restored, from r4.1, debian-12-minimal clone as well.

I also installed a new debian-12-minimal with qvm-templates and ran qubes-dist-upgrade again, which recognized the template as “already upgraded to r4.3”. I also have access to the root terminal.

ephile · January 17, 2026, 2:33pm

I couldn’t find a related issue in qubes-issues. Since I’m not on github, I’m posting the issue here (in the hope that someone will kindly repost to github, feel free to modify). Adding @adw and @unman, since they’re always helpful

Root access fails on debian-12-minimal templates created in r4.2 and restored in r4.3, causing qubes-dist-upgrade error

##Qubes OS version:

r4.3

##Affected component(s) or functionality:
For debian-12-minimal templates restored from r4.2.x or 4.1.x:
qvm-run -u root debian-12-minimal xterm opens the terminal as user, not root,
and qubes-dist-upgrade fails with the following error message:

----> Upgrading debian-12-minimal...
ERROR: This script must be run with root permissions
+  1000 -ne 0 
+ echo 'ERROR: This script must be run with root permissions'
+ exit 1
ERROR: A general error occurred while upgrading debian-12-minimal (exit code 1).

##Steps to reproduce the behavior:
Migrate debian-12-minimal template from a r4.2.4 machine to r4.3. Once restored, run

sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade

##Expected or desired behavior:
All supported templates migrated from any r4.x should maintain root terminal access and be upgradeable with qubes-dist-upgrade.

##Actual behavior:
The upgrade process fails and attempts to access the root terminal open the user terminal instead.
qvm-console-dispvm --autostart debian-12-minimal works as expected, so root access is available via this method.

##General notes:
debian-12-minimal templates installed to r4.3 with qvm-templates behave as expected.

parulin · January 17, 2026, 2:49pm

github.com/QubesOS/qubes-issues

Root access fails on debian-12-minimal templates created in r4.2 and restored in r4.3, causing qubes-dist-upgrade error

opened 02:48PM - 17 Jan 26 UTC

parulin

P: default

**Note:** this bug report comes from [ephile on the forum](https://forum.qubes-o…s.org/t/root-access-fails-on-templates-causing-qubes-dist-upgrade-error/38695/5) but I can reproduce. ## Qubes OS version: r4.3 ## Affected component(s) or functionality: For debian-12-minimal templates restored from r4.2.x or 4.1.x: qvm-run -u root debian-12-minimal xterm opens the terminal as user, not root, and qubes-dist-upgrade fails with the following error message: ``` ----> Upgrading debian-12-minimal... ERROR: This script must be run with root permissions + 1000 -ne 0 + echo 'ERROR: This script must be run with root permissions' + exit 1 ERROR: A general error occurred while upgrading debian-12-minimal (exit code 1). ``` ## Steps to reproduce the behavior: Migrate debian-12-minimal template from a r4.2.4 machine to r4.3. Once restored, run ``` sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade ``` ## Expected or desired behavior: All supported templates migrated from any r4.x should maintain root terminal access and be upgradeable with qubes-dist-upgrade. ## Actual behavior: The upgrade process fails and attempts to access the root terminal open the user terminal instead. qvm-console-dispvm --autostart debian-12-minimal works as expected, so root access is available via this method. ## General notes: debian-12-minimal templates installed to r4.3 with qvm-templates behave as expected.

I thought that we were trying to debug this here, next time feel free to ask me to open an issue

ephile · January 17, 2026, 2:55pm

Thanks! I didn’t want to presume that you were available to post the issue. Being unable to update these templates I thought the issue should be escalated, but you’re right, I could have asked you first before pushing the thread onto other busy people.

ephile · January 22, 2026, 5:15pm

Global Config > Updates was set to “Enable all testing updates” on this device. I had no issues with r4.3 debian-12-minimal updates before my last dom0 update, so it seems likely that I created a system instability with that update. I should have reverted this selection to “Enable stable updates only” when r4.3 was declared stable, better late then never I guess.

I could try rolling back the last update, but I’m not sure if this is a good idea or how best to go about it. It would be interesting to know if that solves the problem.

Here is a list of the packages that were updated:

dom0 update details with `dnf history info 12`

Transaction ID : 12
Begin time : 2026-01-16 03:25:19
Begin rpmdb : cabd73b184325115a5de7fd8151452ea29f End time : 2026-01-16 03:28:36
End rpmdb : 4192d7854a9d11a51becc787d97510b2d5d User : 1000
Status : Okdnf
Releasever : 4.3
Description : dnf upgrade --exclude=qubes-template-* Comment :
Packages altered:
Action Package Install kernel-qubes-vm-1000:6.12.64-1.qubes.fc41.x86_64 Install kernel-devel-1000:6.12.64-1.qubes.fc41.x86_64 Install kernel-modules-1000:6.12.64-1.qubes.fc41.x86_64 Install kernel-1000:6.12.64-1.qubes.fc41.x86_64 Upgrade qubes-core-dom0-0:4.3.40-1.fc41.noarch Upgrade amd-gpu-firmware-1:20260110-1.fc41.noarch Upgrade amd-ucode-firmware-1:20260110-1.fc41.noarch Upgrade cirrus-audio-firmware-1:20260110-1.fc41.noarch Upgrade intel-audio-firmware-1:20260110-1.fc41.noarch Upgrade intel-gpu-firmware-1:20260110-1.fc41.noarch Upgrade linux-firmware-whence-1:20260110-1.fc41.noarch Upgrade nvidia-gpu-firmware-1:20260110-1.fc41.noarch Upgrade python3-qubesadmin-0:4.3.27-1.fc41.noarch Upgrade python3-qubesdb-0:4.3.2-1.fc41.x86_64 Upgrade python3-qubesimgconverter-0:4.3.15-1.fc41.x86_64 Upgrade qubes-core-admin-addon-kicksecure-0:4.3.1-1.fc41.noarch Upgrade qubes-core-admin-client-0:4.3.27-1.fc41.noarch Upgrade qubes-db-0:4.3.2-1.fc41.x86_64 Upgrade qubes-db-dom0-0:4.3.2-1.fc41.x86_64 Upgrade qubes-db-libs-0:4.3.2-1.fc41.x86_64 Upgrade qubes-kernel-vm-support-0:4.3.15-1.fc41.x86_64 Upgrade qubes-manager-0:4.3.20-1.fc41.noarch Upgrade qubes-utils-0:4.3.15-1.fc41.x86_64 Upgrade qubes-utils-libs-0:4.3.15-1.fc41.x86_64 Upgrade qubes-utils-selinux-0:4.3.15-1.fc41.x86_64 Remove kernel-1000:6.12.54-1.qubes.fc41.x86_64 Remove kernel-devel-1000:6.12.54-1.qubes.fc41.x86_64 Remove kernel-modules-1000:6.12.54-1.qubes.fc41.x86_64 Remove kernel-qubes-vm-1000:6.12.54-1.qubes.fc41.x86_64 Replaced amd-gpu-firmware-1:20251125-2.fc41.noarch Replaced amd-ucode-firmware-1:20251125-2.fc41.noarch Replaced cirrus-audio-firmware-1:20251125-2.fc41.noarch Replaced intel-audio-firmware-1:20251125-2.fc41.noarch Replaced intel-gpu-firmware-1:20251125-2.fc41.noarch Replaced linux-firmware-whence-1:20251125-2.fc41.noarch Replaced nvidia-gpu-firmware-1:20251125-2.fc41.noarch Replaced python3-qubesadmin-0:4.3.25-1.fc41.noarch Replaced python3-qubesdb-0:4.3.1-1.fc41.x86_64 Replaced python3-qubesimgconverter-0:4.3.14-1.fc41.x86_64 Replaced qubes-core-admin-addon-kicksecure-0:4.3.0-1.fc41.noarch Replaced qubes-core-admin-client-0:4.3.25-1.fc41.noarch Replaced qubes-core-dom0-0:4.3.38-1.fc41.noarch Replaced qubes-db-0:4.3.1-1.fc41.x86_64 Replaced qubes-db-dom0-0:4.3.1-1.fc41.x86_64 Replaced qubes-db-libs-0:4.3.1-1.fc41.x86_64 Replaced qubes-kernel-vm-support-0:4.3.14-1.fc41.x86_64 Replaced qubes-manager-0:4.3.19-1.fc41.noarch Replaced qubes-utils-0:4.3.14-1.fc41.x86_64 Replaced qubes-utils-libs-0:4.3.14-1.fc41.x86_64 Replaced qubes-utils-selinux-0:4.3.14-1.fc41.x86_64 a885c0f51c0eb986cf3484b01a246
51e8ccfc1c1eface94070e1108e6e
-y
Reason Repository
User qubes-dom0-cached
User qubes-dom0-cached
User qubes-dom0-cached
User qubes-dom0-cached
Group qubes-dom0-cached
Group qubes-dom0-cached
Group qubes-dom0-cached
Group qubes-dom0-cached
Group qubes-dom0-cached
Group qubes-dom0-cached
Dependency qubes-dom0-cached
Group qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Weak Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Group qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
Dependency qubes-dom0-cached
User @System
User @System
User @System
User @System
Group @System
Group @System
Group @System
Group @System
Group @System
Dependency @System
Group @System
Dependency @System
Dependency @System
Dependency @System
Weak Dependency @System
Dependency @System
Group @System
Dependency @System
Dependency @System
Dependency @System
Dependency @System
Group @System
Dependency @System
Dependency @System
Dependency @System

ephile · January 31, 2026, 2:19pm

I just received the same error on a debian-13-xfce clone, which I had backed up on a r4.2 machine and restored on r4.3. So it’s not confined to debian-12-minimal templates.

dhimh · February 13, 2026, 10:34am

I had always enabled “stable updates only” on r4.3 but since the dom0 update yesterday (at least I didn’t notice it before) I get the same error.

This is the list of packages that were updated:

Output of `dnf history info 3`

$ dnf history info 3
Transaction ID : 3
Begin time : 2026-02-12 11:49:49
Begin rpmdb : a543278ed71a264dc7f407df9d81cf904baec518e904bb70ed3e2ff42e346ed4
End time : 2026-02-12 11:50:01
End rpmdb : 31d2db4393c1d3417e4f9a7e8210a1f4fa34f061d2ddbe996d6be59a3aee5466
User : 1000
Status : Ok
Releasever : 4.3
Description : dnf upgrade --exclude=qubes-template-* -y
Comment :
Packages altered:
Action Package Reason Repository
Upgrade python3-qubesadmin-0:4.3.27-1.fc41.noarch Dependency qubes-dom0-cached
Upgrade qubes-core-admin-client-0:4.3.27-1.fc41.noarch Dependency qubes-dom0-cached
Upgrade qubes-core-dom0-0:4.3.42-1.fc41.noarch Group qubes-dom0-cached
Upgrade qubes-core-dom0-linux-0:4.3.21-1.fc41.x86_64 Dependency qubes-dom0-cached
Upgrade qubes-core-dom0-linux-kernel-install-0:4.3.21-1.fc41.x86_64 Dependency qubes-dom0-cached
Replaced python3-qubesadmin-0:4.3.25-1.fc41.noarch Dependency @System
Replaced qubes-core-admin-client-0:4.3.25-1.fc41.noarch Dependency @System
Replaced qubes-core-dom0-0:4.3.38-1.fc41.noarch Group @System
Replaced qubes-core-dom0-linux-0:4.3.20-1.fc41.x86_64 Dependency @System
Replaced qubes-core-dom0-linux-kernel-install-0:4.3.20-1.fc41.x86_64 Dependency @System

Edit: the affected templates are debian-12 templates (minimal and xfce) restored from r4.2.

Edit2: I didn’t run qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade for these qubes before the dom0 update yesterday (had it on my todo list but didn’t find the time). All my other templates are recreated on r4.3 and the problem doesn’t occur there.

ben-grande · February 13, 2026, 4:40pm

For anyone facing this issue, I provided debugging steps on github, please report there. If you don’t have a github account, having a proxy/middleman/someone else interacting for you slow things down.

ephile · February 13, 2026, 5:24pm

SInce I’m not on github I’ll report this here, anyone is welcome to repost to github…

user@dom0:~$ grep -E 'qubes.VM(Root|Shell|Exec)' /etc/qubes/policy.d/*.policy

/etc/qubes/policy.d/90-default.policy:qubes.VMShell  *  @anyvm  @dispvm  allow
/etc/qubes/policy.d/90-default.policy:qubes.VMShell  *  @anyvm  @anyvm  deny

/etc/qubes/policy.d/90-default.policy:qubes.VMRootShell  *  @anyvm  @anyvm  deny

/etc/qubes/policy.d/90-default.policy:qubes.VMExec  *  @anyvm  @dispvm  allow
/etc/qubes/policy.d/90-default.policy:qubes.VMExec  *  @anyvm  @anyvm  deny

/etc/qubes/policy.d/90-default.policy:qubes.VMExecGUI  *  @anyvm  @dispvm  allow
/etc/qubes/policy.d/90-default.policy:qubes.VMExecGUI  *  @anyvm  @anyvm  deny


user@dom0:~$ qvm-run -p sys-net 'grep . /etc/qubes/rpc-config/qubes.VM*'

/etc/qubes/rpc-config/qubes.VMExecGUI:wait-for-session=1
/etc/qubes/rpc-config/qubes.VMRootExec:force-user='root'
/etc/qubes/rpc-config/qubes.VMRootShell:force-user='root'
/etc/qubes/rpc-config/qubes.VMShell+WaitForSession:wait-for-session=1

dhimh · February 13, 2026, 6:05pm

I’m not on github either (tried to create an account, but failed). Hopefully someone else can repost it.

This is the output of the 2 commands on my computer:

user@dom0:~$ grep -E 'qubes.VM(Root|Shell|Exec)' /etc/qubes/policy.d/*.policy
/etc/qubes/policy.d/90-default.policy:qubes.VMShell           *           @anyvm          @dispvm     allow
/etc/qubes/policy.d/90-default.policy:qubes.VMShell           *           @anyvm          @anyvm      deny
/etc/qubes/policy.d/90-default.policy:qubes.VMRootShell       *           @anyvm          @anyvm      deny
/etc/qubes/policy.d/90-default.policy:qubes.VMExec            *           @anyvm          @dispvm     allow
/etc/qubes/policy.d/90-default.policy:qubes.VMExec            *           @anyvm          @anyvm      deny
/etc/qubes/policy.d/90-default.policy:qubes.VMExecGUI         *           @anyvm          @dispvm     allow
/etc/qubes/policy.d/90-default.policy:qubes.VMExecGUI         *           @anyvm          @anyvm      deny
user@dom0:~$ qvm-run -p sys-net 'grep . /etc/qubes/rpc-config/qubes.VM*'
/etc/qubes/rpc-config/qubes.VMExecGUI:wait-for-session=1
/etc/qubes/rpc-config/qubes.VMRootExec:force-user='root'
/etc/qubes/rpc-config/qubes.VMRootShell:force-user='root'
/etc/qubes/rpc-config/qubes.VMShell+WaitForSession:wait-for-session=1