[4.1] Xfce menu vanished

Perhaps some potential leads:

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

Is that your network controller attached to sys-net or USB controller attached to sys-usb?
Try to add no strict reset option to it to make it work:

I was able to get the panel to show up by adding the command xfce4-panel to the startup and sessions tool.

The PCI trick also seems to have solved the qubes-usb not starting.

However, I am still getting the error on Dom0 update attempts. SHould that be a new thread?

Does the network work for you in qubes?

Yes - that is working also, and the gui icon is back.

Then what’s the error that you’re getting when you try to update dom0?

(zenity:1288): Gdk-Critical **: 0 [a time stamp] gdk_atom_intern: assertion ‘atom_name != NULL’ failed

[Same as above] /gdk/x11/gdkproperty-x11.c:224 invalid X atom:611158387

What if you run update from dom0 terminal?
sudo qubesctl --show-output state.sls update.qubes-dom0
How to update | Qubes OS

UPD:
Or try to run Qubes Update from dom0 terminal:
qubes-update-gui
And see if there are more errors.

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.

The
Updating dom0
Local:

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 :wink: