Service file ‘/usr/share/dbus-1/services/org.xfce4-notifyd.Notifications.Service’ is not named after the D-Bus name ‘org.freedesktop.Notifications’
Service file ‘[…/]org.xfce4.Thunar.FileManager1.service’ is not named after the D-Bus ‘org.freedesktop.FileManager1’
pciback 0000:00:1d.0: xen_pciback: cannot enable memory-write-invalidate (-22)
pciback 0000:00:1d.0 cache line size of 64 is not supported.
Same for 14 and 1 (in place of 1d)
libvirtd[3266]: internal error: Unable to reset PCI device 0000:00:14: no FLR, PM reset or bus reset available
From /var/log
Lots of Gtk warnings about drawing a gadget with negative dimensions
Failed to terminate process 6271k, no such process
# sudo qubesctl --show-output state.sls update.qubes-dom0
[WARNING ] /usr/lib/python3.8/site-packages/salt/utils/files.py:396: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
f_handle = open(*args, **kwargs) # pylint: disable=resource-leakage
local:
----------
ID: /etc/yum.repos.d/qubes-dom0.repo
Function: file.replace
Result: True
Comment: No changes needed to be made
Started: 09:20:44.495878
Duration: 14.632 ms
Changes:
----------
ID: /etc/yum.repos.d/qubes-templates.repo
Function: file.replace
Result: True
Comment: No changes needed to be made
Started: 09:20:44.510676
Duration: 2.045 ms
Changes:
----------
ID: update
Function: cmd.run
Name: if qubes-dom0-update --quiet --assumeyes --clean --action=clean expire-cache >/dev/null 2>&1; then
echo "result=True comment='Cache cleaned'"
else
echo "result=False comment='Could not clean cache'"
fi
Result: True
Comment: Cache cleaned
Started: 09:20:44.514937
Duration: 3851.347 ms
Changes:
----------
ID: update
Function: pkg.uptodate
Result: True
Comment: System is already up-to-date
Started: 09:20:49.789651
Duration: 203855.47 ms
Changes:
Summary for local
------------
Succeeded: 4
Failed: 0
------------
Total states run: 4
Total run time: 207.723 s
So this is, perhaps, looking more like a Fedora35 issue, as the problems only arose after updates, and the fundamental processes which are being blocked seem to work when invoked through another means?
I don’t know how did you get all these issues in one go. But I’m not sure it was caused by fedora-35 template. Maybe some dom0 update went wrong for you.
The machine hasn’t had a dom0 update in a week or so. Odd that three issues spring up at once.
The reason I think it may be fedora35 is because the update of dom0 via qubes manager is done via the firewall appvm, which is fedora35 and the errors are in that appvm.