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-r97fbcedb15b548a088e113886887083e.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:
4863
retcode:
1
stderr:
Running scope as unit: run-r97fbcedb15b548a088e113886887083e.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:
Different failure with Error rtncode 2
---------cut here-------------------------
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: 2
[ERROR ] stderr: Running scope as unit: run-r02e64eb07a094699878de6d2a57d4ce0.scope
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time…
Sending repository information to UpdateVM failed: code 2
[ERROR ] retcode: 2
Error running ‘pkg.upgrade’: Problem encountered upgrading packages. Additional info follows:
changes:
----------
result:
----------
pid:
48143
retcode:
2
stderr:
Running scope as unit: run-r02e64eb07a094699878de6d2a57d4ce0.scope
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time…
Sending repository information to UpdateVM failed: code 2
stdout:
@adw You need a title in your profile letting people know you are actually with the Qubes Team.
@BebeRebozo He is with the Qubes Team! The GUI does the commands in a graphical format, running the code in the terminal will do the same thing and potentially bypass a graphical error. Its good practice for troubleshooting.
I don’t think people should blindly trust what a forum account posts just because it says “Qubes Team” or some such next to it. This Discourse forum is hosted on third-party infrastructure, and posts here aren’t cryptographically signed. I endorse a healthy degree of skepticism.
(Also, mailing list users can’t see that stuff anyway.)
In this case, it’s actually not the same thing, and there are important security implications associated with this, as explained in the documentation:
The direct commands aren’t any less safe than they were before, though.
I use the command line if more than one or two qubes need updating. Why? Because there’s no obvious way to keep my machine from bogging down as it runs four updates at once. (Even my desktop, which is fairly powerful, will bog down trying to do four at once. My laptop turns into a brick for the duration.). I’ve got my VMs organized so that I can run a consecutive “block” of them from a script…which does them one at a time. If my base minimal template needs updating…well, all of my templates need updating. I run the script to do them all. If my firefox base template needs updating (but my overall base one does not), then I only update the firefox templates. (I clone these base templates, and leave the clone [named Update-Canary-…] running with minimal memory so I will see when updates are needed.)
Yes, I know there’s a setting somewhere to reduce concurrency, but it’s not in any gui I am aware of, which means I have to go look it up every time I want to change it. It should be settable right there on the update tool.
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-rac935628e44940778283b16c5324885b.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:
35051
retcode:
1
stderr:
Running scope as unit: run-rac935628e44940778283b16c5324885b.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:
You are doing stuff that I am not even contemplating.
Unless you can decipher the latest error condition and explain the solution to me like I am five years old, you are coming off like lookie at me show-off hotdog.
One more comment while I am looking at things.
There’s a “terminal” named “Terminal Emulator” and when you open it you get, is it, your installation user ID.
There’s a terminal in the Qubes (because heaven forbid I say VM) that when you open it you get the user “user”.
In Qubes Manager (via Open Qubes Manager), if I right click sys-firewall there is “Open console in Qube” that will open a terminal in sys-firewall; it requires root login without a password.
In your solution ideas, please, take the effort and consideration and exactly itemize the mouse clicks; and where.
Thanks for replying and I look forward to getting this resolved.
PS The how to fix missing appblahblahblah.desktop application on your menu was spot on! The first solution worked great and was easy to follow; I just had to copy the .desktop from /Desktop to /usr/share/application and run that synch command followed by doing the application refresh mouse click in spite of it already showing up. Thx!
I dont think that in your many posts you have ever said what you are
using as the updateVM, and what template that qube is based on.
Nor have you checked the free space on the updateVM.
When you run sudo qubes-dom0-update from dom0, a second window should
open and you will see the download process on the UpdateVM.
What happens there?
I do not understand your questions about backup and restore: perhaps I
miss context.
If you want to test a backup you can do this from the Restore window
with the “Test” restore option.
If you restore a backup and the qube already exists, then the restored
qube will be renamed : NAME->NAME-1
Why would you want to do this?
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Thanks for the reply and I’ve opted to divide my response into the now two components.
I do not understand your questions about backup and restore: perhaps I
miss context.
If you want to test a backup you can do this from the Restore window
with the “Test” restore option.
I need to re-read that, probably two more times, as it just I glanced at the backup documentation yesterday. More to come.
If you restore a backup and the qube already exists, then the restored
qube will be renamed : NAME->NAME-1
I definitely didn’t see that in the documentation and yes I will re-read it again but that is good news. More to come.
Why would you want to do this?
A back up is only as good as the restore and until you actually complete the backup circle with a restore then you have only done half the process. And no I don’t mean test EVERY backup with a restore but I also suggest to complete the circle more often than certainly I do now.
With hindsight most companies I’ve been associated with almost never ever tested their backups with restores until something failed they were forced to because of the system failure. As if having successful backups is all good.
I dont think that in your many posts you have ever said what you are
using as the updateVM, and what template that qube is based on.
Please review the first two posts of this thread. The update to Dom0 failed for two different reasons with no indication that disk space is an issue.
Also the error messages from the two unsuccessful attempts seem to point to sys-firewall.
Repeating myself, the failure were for two different reasons - so there is that.
Nor have you checked the free space on the updateVM.
I’ll give this a whirl.
Dom0 template is greyed out AdminVM.
Dom0’s DefaultDispVM is default(debian-11-dvm).
The other …fugg… I dont know where to look. :- / …for disk space issues…after all the other qubes updates work…
When you run sudo qubes-dom0-update from dom0, a second window should
open and you will see the download process on the UpdateVM.
What happens there?
The Qubes Team themselves are, IMHO, divided on this with one side saying, “you should use the GUI for updates” and the other camp advocating “do the sudo.”
I’m in the GUI camp.
However, after a successful backup with its corresponding test restore would be willing to try the terminal window update but I’d rather not.
Currnet state is the GUI update method just spun for 30 minutes before I unsuccessfully was not able to cancel it so I rebooted the system - making the backup/restore even more important.
As an observation from having had to deploy software AND write error messages.
The very first task is to check for disk space for both the payload and for the results and if too little then do not proceed with the deployment.
Error messages really ought to mean something to ideally the recipient, that would be me because I have to report the condition, and to the support team that has to deal with me reporting the error condition and finally to the person(s) who crafted the message that has to deal with, or dodge, the error condition.
Finally, while I am getting more accustomed to Qubes, this is no way my first rodeo.
@adw suggested that you use the command line. So did I.
The team are not divided on the use of the GUI - it is recommended in
most cases, and definitely in ordinary use.
For troubleshooting purposes, the GUI is lacking in 4.1. (This is why it
is rewritten for 4.2.) So in your case you should use the command line.
You will be able to see errors/warning from dom0 and from your updateVM.
If you continue to ignore advice, no one will be able to help you. It’s
not a question of being in any “camp”.
I completely agree that testing the backup/restore process is essential.
I had not understood that this was your aim.
You can use the test process to confirm the validity of the archive, and
performing an actual restore operation is also good.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
