@alimirjamali While restoring 4.2 backup on 4.3 should I restore dom0 or not?
If I don’t restore dom0 I’ll have to rewrite sys-audio policies
1 Like
btw if this minimal-usbvm is going to stay, atleast this error message should be helping and user readable. Current error message doesn’t tell the actual issue at all.
Atleast leave it to “Not authorized to perform operation” That would be less confusing.
2 Likes
As far as i know, policies are not included in dom0 backups at first place? (but I might be wrong) I can provide a link to original stock sys-audio policy settings.
dom0 backup might include other settings such as DE (XFCE) settings and customization.
I agree.
2 Likes
dom0 backup only contains your home user directory, which only has settings for the desktop environments, dom0 editor, bash history (not as root) etc… And it does not overwrite the files in the dom0 where it’s restored, it’s in a sub directory and you need to manually move the files to the right place.
3 Likes
Just to confirm: I successfully did an in-place upgrade from 4.2 to 4.3.0-rc4.
2 Likes
I think the issue in my case was that I was using both XFCE and KDE and KDE packages were giving error on upgrade. I though removing KDE will resolve the issue but it seems that made things worse.
1 Like
To whom it may concern: I too encountered repeated errors when trying to execute an in-place update from v4.2.4, when trying to use the built-in commands to run the pre-reboot stages all at once:
sudo qubes-dist-upgrade --all-pre-reboot --releasever=4.3
I had much more success by running each stage individually:
- Stage 1:
sudo qubes-dist-upgrade --releasever=4.3 -t - Stage 2:
sudo qubes-dist-upgrade --releasever=4.3 -r - Stage 3:
sudo qubes-dist-upgrade --releasever=4.3 -s
I was then able to reboot and execute the remaining three stages in bulk:
sudo qubes-dist-upgrade --all-post-reboot --releasever=4.3
Edit: now looking at the script for qubes-dist-upgrade, it makes no sense that these two procedures should make any difference at all, as the exact same code is executed
4 Likes
I did a successful update from 4.2 to 4.3 a few hours ago too.
3 Likes
Ok now I’ve tried In-place upgrade on a different system.
First three stages went well but after system restart sys-usb is showing all usb related devices as ?*****: unknown vendor unknown usb device
I use usb wifi and now I can’t connect to the internet to start the 4th, 5th and 6th stage on this system.
Any clue or work around?
1 Like
What is the output of qvm-pci list | grep PCI_USB in dom0? Do you get anything? Are they listed as sys-usb (attached) in the 3rd column of qvm-pci` output?
2 Likes
I connected the internet and after --all-post-reboot upgrade and restart sys-usb came back to normal.
2 Likes
Interesting I’m getting the same error here I’ve tried with --skip-standalone-upgrade (as I have some strage standalones) as well as --only-update (a traditional qube). I’ve also checked that /usr/lib/python3.13/site-packages/qubesadmin/app.py exists in Dom0 defaulr permissions on the file look reasonable -rw-r–r-- as well as drwxr-xr-x on the directory.
Any suggestions how I might dig deeper. I have a backup and could just do the same as @marcoos-morar just in the Christmas mood to do some debugging.
Happy holidays and upgrading to you all
‘’’
> File "/usr/lib/python3.13/site-packages/qubesadmin/app.py", line 861, in qubesd_call
> client_socket.connect(qubesadmin.config.QUBES_SOCKET)
>
> FileNotFoundError: [Error 2] No such file or directory
>
> File "/usr/bin/qvm-appmenus", line 33, in <module>
> sys.exit(load_entry_point('qubesdesktop==4.3.1', 'console_scripts', 'qvm-appmenus')())
>
> File "/usr/lib/pythong3.13/site-packages/qubesappmenus/__init__.py", line 813, in main for vm in domains:
>
> File "/usr/lib/python3.13/site-packages/qubesadmin/app.py, line 73, in refresh_cache
> vm_list_data = self.app.qubesd_call("dom0", "admin.vm.List")
> File "/usr/lib/python3.13/site-packages/qubesadmin/app.py", line 863, in qubesd_call\
> raise qubesadmin.exc.QubesDaemonCommunicationError(
> "Failed to connect to qubesd service: %s", str(e)
> )
> qubesadmin.exc.QubesDaemonCommunicationError: Failed to connect to qubesd service: [Errno2] No such file or directory
Reading these user reports makes me nervous about updating. I just installed Qubes recently and I don’t have much experience beyond stacking vpns on one another and customizing templates. Do I understand correctly that the easiest option is to backup my files and reinstall Qubes from scratch?
1 Like
I’ve upgraded five systems to version 4.3 so far. Only one system encountered issues during the in-place upgrade and required a fresh installation, the other four upgraded in-place without any problems.
From my observations, issues during an in-place upgrade are more likely if you’ve installed extra applications in dom0. If dom0 remains untouched, the chance of problems is very low.
Another common cause is the presence of standalone VMs or non-updatable qubes, these can block the in-place upgrade. In such cases, use --skip-standalone-upgrade parameter, if even that doesn’t work, simply back up those qubes, delete them before upgrading, and then restore them afterward. The upgrade process should then proceed without issues.
2 Likes
I will do a fresh install then. Thank you
1 Like
In place upgrade broken for me, running script produces an error related to incorrect characters (.,-,"_) in the script title for a handful of parts, but otherwise appears to finish. Upon reboot lightpdd (this is not the real service name just my poor memory of the error) will not start.
An this point I might have attempted to access the remainder of the script/steps from CLI, but since I had backups I decided on clean install.
As others have reported, these issues may have to do with non updateable VMs, I had both alpine and arch and should have deleted them after backing up but before running in place upgrade script.
Now I have a real problem: there is an error trying to restore qubes.
One qube restoration produces error “can’t set default_dispvm to non existing qube” and restoration has stalled now for 10+ hrs. Pressing cancel has produced no effect except a greyed out button.
If anybody has some ideas you will save my day.
As a stop gap try restoring pice by pice starting with the most important data or something small 10Gb that should at least get you more immediate feedback regarding the backup.
Can also try ingnore template mismatch but I would suggest having a read of the man page for that feature as I can’t quite remeber its exact effect