Worked when I did it that way.
Threw a python warning about buffering not being supported.
running the normal sudo qubes-dom0-update also works.
However, running the update from the qubes manager results in the above error.
Odd
Worked when I did it that way.
Threw a python warning about buffering not being supported.
running the normal sudo qubes-dom0-update also works.
However, running the update from the qubes manager results in the above error.
Odd
Try to run Qubes Update from dom0 terminal:
qubes-update-gui
And see if there are more errors.
I’m not sure if it did.
I forced a dom0 update and the details are:
Updating dom0
Local:
---------------
I don’t normally try and update when there is none available through this widget, so not sure if the above is expected?
No it should look like this:
# 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
Or are you talking about updating with Qubes Update GUI?
That was the output I got when I ran the command directly in the terminal.
was a result of the GUI widget being forced to update dom0. I never really use that, so am not sure of the expectation
That’s expected output:
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.
The menu vanishing could be unrelated.
I haven’t followed the rest of the conversation but I just realized I made a mistake in my reply:
The directory is NOT $HOME/.local/share/applications
and it should be changed to: $HOME/.config/autostart
.
So the path of the .desktop
file is:
$HOME/.config/autostart/xfce4_panel.desktop
I had this problem a few months ago and today it occurred to me again. Just delete everything in: .cache/sessions
rm .cache/sessions/*
Will get a message saying it cannot remove /thumbs-dom0:0 , you can ignore it.
Logout/login or reboot and done