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

TheMailman · February 15, 2026, 9:34am

I’ve read this thread, though not the github posts. Anyway I am having a problem that might be related. I installed 4.3, and restored all of my templates to 4.3 (from 4.2). Everything was fine, until the other day when I upgraded dom0. I am speculating there’s a connection. Now I can not upgrade my templates, and when I run qvm-run -u root <template> xterm I get a user terminal in that template.

I had not heard about qubes-dist-upgrade. Why would I? I installed 4.3 fresh, and restored my old qubes, like I have done every time since 3.0. (I never back up and restore dom0). And it worked fine, until the dom0 upgrade.

So now I installed qubes-dist-upgrade, and I ran sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade but for every qube, I get the following error:

----> Upgrading debian-12-xfce...
ERROR: This script must be run with root permissions
* [( 1000 -ne 0 ]]
* echo 'ERROR: This script must be run with root permissions'
* exit 1

Can you help me troubleshoot?

I can imagine that I will have to somehow get a new signing key, and update the qubes file in /etc/apt/sources.list.d. And if I have to do this manually, I will. But some of the templates that qubes-dist-upgrade fails on are templates that still do have sudo access working (ex: debian-42-xfce) so the error is very confusing. The whole thing is confusing, from why it only started three weeks into my upgrade, when I upgraded som0 last week, etc.

Anyway, any help is appreciated.

Yeah, that’s when this problem started for me, although @unman in another thread seemed to want to ignore the possibility that the problems were related. I actually think that probably indicates a bigger problem: why did the old qubes update fine, if they shouldn’t have, and why did they stop?

Then the third problem: why does qubes-dist-upgrade give me the error above?

I’m very confused.

For several years, github has essentially required its users to dox themselves to access the site. It’s not something that security/privacy minded people such as myself will conform to. Of course you have to follow your own morals but I encourage you to stop using it as well. (Or at leaset to post your debugging steps here).

TheMailman · February 15, 2026, 9:38am

This i where I am stuck also. Have you had any movement from this since 29 days ago? (For me it started weeks after I restored to 4.3, and immeiately after last week’s dom0 upgrade.)

ephile · February 15, 2026, 2:04pm

The github issue has been bumped to critical and pinned as a highest priority issue, so I suspect we’ll see a resolution sooner rather than later. It was undoubtedly triggered by the same dom0 update being moved from testing to stable.

parulin · February 20, 2026, 5:59pm

Ouch, I forgot about this issue and in-place upgraded my main driver

parulin · February 20, 2026, 7:32pm

So, qvm-run -u root doesn’t work on minimal templates from 4.2. to work around this:

I ran STEP 4, letting the minimal templates fail.
I changed line #506, like qu-mf says on github but to run qvm-console-dispvm "$vm" instead. Then I ran STEP 4 again, and in each console, I manually logged in as root and ran the script.

parulin · February 21, 2026, 9:00am

If anyone can follow @marmarek PR, edit the appropriate line and report back the outcome, that would be great.

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: critical C: Debian/Ubuntu needs diagnosis C: dist upgrade affects-4.3

**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.

It wasn’t working for me, see my comment:

github.com/QubesOS/qubes-core-admin-client

tools: fix qvm-run -u root on template imported from R4.2

main ← marmarek:fix-qvm-run-root

opened 02:59AM - 21 Feb 26 UTC

marmarek

+6 -1

Template imported from R4.2 already has qubes.VMRootShell service, but it isn't …really running as root by default. It's only R4.3+ when both qubes.VMRootShell and qubes.VMRootExec got also force-user=root setting. Since the check for VMRootExec is already needed anyway, use the same to check if using qubes.VMRootShell makes sense, as both changes were introduced at the same time in core-agent-linux: 1c538af2 Use rpc-config for running qubes.VMRoot* services as root 563a9cfa Add qubes.VMRootExec service This is more flexible method than hardcoding version check. Fixes QubesOS/qubes-issues#10590

ephile · February 21, 2026, 2:33pm

Since he has already pushed modifications based on your feedback, is this request for testing still relevant?