Error:
Problem: cannot install the best update candidate for package breeze-icon-theme-5.108.0-2.fc37.noarch
- problem with installed package breeze-icon-theme-5.108.0-2.fc37.noarch
- both package breeze-icon-theme-6.18.0-1.fc41.noarch and breeze-icon-theme-fedora-6.18.0-1.fc41.noarch obsolete breeze-icon-theme < 6.13.0-2
- package breeze-icon-theme-fedora-6.18.0-1.fc41.noarch requires fedora-release-common, but none of the providers can be installed
- package qubes-release-4.3-1.fc41.noarch obsoletes fedora-release-common <= 41 provided by fedora-release-common-41-25.noarch
- package qubes-release-4.3-1.fc41.noarch obsoletes fedora-release-common <= 41 provided by fedora-release-common-41-33.noarch
- problem with installed package qubes-release-4.3-1.fc37.noarch
- cannot install the best update candidate for package qubes-release-4.3-1.fc37.noarch
- qubes-release-4.3-1.fc37.noarch does not belong to a distupgrade repository
- breeze-icon-theme-5.108.0-2.fc37.noarch does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)
What should I do?
giving command sudo qubes-dist-upgrade --release-upgrade --skip-broken does not work, it does not accept --skip-broken. So where to provide this?
Furthermore the documentation said to use this command: sudo qubes-dist-upgrade --all-pre-reboot
But the system doesnāt accept this command without --releasever so it should be updated in the documentation
Crap!
The --all-pre-reboot completed without any error.
But after restart now nothing is working. No VM is running, Qubes Menu is not running. Canāt use anything. Not even Qubes Manager icon is there.
When I gave the --all-post-reboot command a list of errors displayed.
I am manually typing them here:
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
Ok now what should I do? Do a clean install and restore backup there? Or there is still some hope here?
This is a known annoying issue. By default, on r4.3, sys-usb has a minimal-usbvm service enabled. Which prevents it from opening the external USB drive in backup or restore dialog. I personally disagree with that design. But it is my personal opinion.
you have many options to restore your backup:
Attach the external drive containing your backups to a regular AppVM and then restore from it.
You could disable the minimal-usbvm service of sys-usb, restart it and then you will be able to restore directly from it. But you should give it a couple hundred megabytes of additional RAM in its settings.
You could mount the drive within sys-usb terminal in some directory and assure user has read access to it. Then you will be able to restore from that directory.
In my opinion, that is a regeneration which should be fixed. We made sure sys-usb is the default in backup/restore dialog. But then the minimal-usbvm could not open the drive. This is misleading. I wonder what @marmarek thinks about this.
I also got these errors when trying to upgrade from 4.2.4 to 4.3.0, and I was about to reinstall Qubes OS. @alimirjamali Should I do it now, or is it better to wait for the bug fixes? Itās important to me that the system works.
I strongly believe r4.3.0 is the right version for new installations. The issue with restore, in-place upgrade or backup/restore is minimal unfortunate.
Yes. You are right. Specially if user does not have backups. My apologies. Yet the r4.2.x depends on very old version of Fedora for dom0 which made barely sustainable. For in-place upgrades, I was not able to test/help that much. Since I was on r4.3 development branch for its beginning. Many details were lost in my case and everything was gradual upgrades.
No, it should be possible. The problem is in-place upgrades has many corner cases to cover. For example people who had another DE (KDE or i3wm). Or people who had specific configuration and/or different versions of templates. Testing everything is hard. For people working on in-place upgrade, access to many hardware and/or virtual machines with different settings is/was essential.
p.s.: For example one bug was when specific version of Whonix or Debian was used as updatevm. Which made some issues with in-place upgrade. I did not experience it since I always used Fedora.
