MX problem with X session saving and/or Xfce

Yesterday I did a routine update of MX
Today when I boot MX, I can login, but I get a screen with all the X terminals from 4 workspaces crammed into the one screen, I can get a menu from the menu button, but not from clicking on background, and the Xfce terminals are incomplete ( no clicks at upper right)

Not my usual background image either, and the theme is not mine.
The 4 workspaces do not work
I can use the terminal windows, and I can start apps with the menu button…
the package installer works, firefox works ( except I cant move the firefox window)

So it has affected mostly the items that are session saved?
I installed another kernel, just to be sure it was not a kernel issue, and it made no difference.

What do you think has happened ?
What steps would you take to debug it. ?

2 Likes

Hi Neville, :wave:

I´m a bit baffled by what you experienced.

Off the top of my head I canot guess what the issue might be.
Clearly it was triggered by the update.

Do you by any chance have a recent timeshift snapshot available :question:
Of course that wouldn´t get things right again as far as any future updates are concerned.

Just a thought.

Many greetings from Rosika :slightly_smiling_face:

3 Likes

Hi Neville, :wave:

Due to the fact that I have xfce on my Linux Lite system as well your problem seems to be of some greater interest to me as well.
But, as I already mentioned, I have no clue what might be amiss.

So I asked ChatGPT about it. I hope you don´t mind. :blush:
Perhaps there´s something in it for you:

It sounds like your friend’s MX Linux system is facing issues with the Xfce desktop environment, particularly with the window manager or session settings after a routine update.
Here’s a breakdown of the possible causes and the steps your friend can take to debug and resolve the issue:

What Might Have Happened:

  1. Corrupted Xfce Session or Configuration: The issues with missing window borders, incorrect workspaces, and themes indicate that something might have gone wrong with the saved session or Xfce’s configuration files.

  1. Window Manager (Xfwm4) Not Running Properly: Xfce relies on Xfwm4 as its window manager. If it’s not running or misbehaving, the windows won’t have decorations (borders, buttons to close/minimize), and window management (moving, resizing) won’t work properly.

  1. Theme/Display Settings Reset: The default theme and missing background might suggest that some configuration files were either reset or corrupted during the update process.

Steps to Debug and Fix the Issue:

1. Restart Xfce Window Manager (Xfwm4):

Since it sounds like the window manager isn’t functioning correctly, you can ask your friend to try restarting it manually. He can do this using the terminal:

xfwm4 --replace &

This command restarts the window manager. If it works, the window borders and other elements should be restored, and he should be able to move and resize windows again.

2. Check Session Settings:

It’s possible that the Xfce session saved some corrupted state. Ask your friend to delete the saved session so that a fresh one can be generated. This can be done by removing the session cache files:

rm -rf ~/.cache/sessions/

After removing these files, have him log out and back in again. This should start a clean session.

3. Check Display Settings:

Sometimes display settings can cause the desktop to behave unexpectedly. Have your friend open the display settings and make sure the correct resolution and monitor setup are selected. He can open it using the terminal if the graphical tool isn’t responding:

xfce4-display-settings

4. Reset Xfce Configuration:

If the issue persists, he can try resetting the Xfce desktop settings to the defaults. This will revert any user-made changes to the desktop environment but might fix the issue:

mv ~/.config/xfce4 ~/.config/xfce4_backup

After running this command, log out and log back in to see if the issue is resolved. If the problem is fixed, but he wants his old settings back, he can copy specific files back from ~/.config/xfce4_backup.

5. Check for Xfce-Specific Errors in Logs:

To get more clues, your friend can check system logs for any errors related to Xfce, Xfwm4, or display settings. He can look at the following logs:

  • ~/.xsession-errors: This file logs errors that occur during the X session. He can check it for clues:
cat ~/.xsession-errors | grep xfce

/var/log/syslog or /var/log/Xorg.0.log: These files might also contain error messages related to the graphical environment or window manager.

6. Create a New User to Test:

To see if the issue is related to his user configuration or system-wide, he could create a new user and log in with that account. If the new user account works fine, then the issue is specific to his user configuration:

sudo adduser testuser

He can then log out and log in as “testuser” to see if the desktop works properly.

Possible Root Cause:

Since this issue started after an update, it’s possible that:

  • The update may have corrupted or reset certain Xfce configuration files.
  • There could be a conflict with one of the updated packages.
  • There might have been a glitch in how Xfce loaded after the update.

Summary of Actions:

  1. Restart the window manager with xfwm4 --replace &.
  2. Remove the saved session (rm -rf ~/.cache/sessions/).
  3. Reset Xfce configuration (mv ~/.config/xfce4 ~/.config/xfce4_backup).
  4. Check the logs for clues.
  5. Test with a new user.

I hope at least some parts of it may help.

Many greetings from Rosika :slightly_smiling_face:

4 Likes

Hi Rosika,
Thank you, now I have some idea where to start.

I do have a very recent rsync of the MX home directory, so I could revert any of the personal dot files.
and I have an older clonezilla dump of the MX root partition

I think the idea of making another user i important… it will help resolve whether the issue is with personal settings or is a system issue.
I could also try logging in as root.

Regards
Neville

2 Likes

Thanks for the feedback, Neville. :wave:

You´re welcome.
I´m also interested to see how it works out.

That´s great. Such backups can of course be of immense value.

Yes, I think that´s a good idea, as well.

Many greetings from Rosika :slightly_smiling_face:

2 Likes

Logging in as root made no difference

Tried restarting the xfce4 window manager

nevj@trinity:~
$ xfwm4 --replace
libGL error: did not find extension DRI_Mesa version 1
libGL error: failed to load driver: swrast

(xfwm4:6905): xfwm4-WARNING **: 20:27:55.415: Could not create GLX context.

(xfwm4:6905): Gdk-WARNING **: 20:27:55.416: The program 'xfwm4' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 2456 error_code 2 request_code 151 (GLX) minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
nevj@trinity:~

So it dies with an error message.
Befor it did it did something
My screen now looks like this


That is my background, but
no panels, can get a menu by clicking background, Xfce terminals still have no upper right buttons, there are no saved session items.

Looked for packages mentioned

nevj@trinity:~
$ dpkg -l | grep libGL
nevj@trinity:~
$ dpkg -l | grep xfwm4
ii  xfwm4                                    4.18.0-1                               amd64        window manager of the Xfce project

look harder

nevj@trinity:~
$ dpkg -l | grep libgl
ii  libgl1:amd64                             1.6.0-1                                amd64        Vendor neutral GL dispatch library -- legacy GL support
ii  libgl1-mesa-dri:amd64                    24.2.2-1~mx23ahs                       amd64        free implementation of the OpenGL API -- DRI modules

So libgl1-mesa-dri:amd64 is the ahs version
That may be the issue…
I have moved from kernel vmlinuz-6.5.0-1mx-ahs-amd64 to kernel vmlinuz-6.9.12-amd64
but
if I boot kernel vmlinuz-6.5.0-1mx-ahs-amd64 I still have the problem???

I tried an update/upgrade in case there were some fixes… it had no effect

There are some errors in .xsession-errors

/usr/bin/startxfce4: X server already running on display :0

(xfce4-session:3985): dbind-WARNING **: 20:16:49.102: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/108/at-spi/bus_0: Permission denied
/usr/bin/iceauth:  creating new authority file /run/user/1000/ICEauthority
xfce4-session-Message: 20:16:49.116: SSH authentication agent is already running

(xfwm4:4136): dbind-WARNING **: 20:16:49.171: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/108/at-spi/bus_0: Permission denied
libGL error: did not find extension DRI_Mesa version 1
libGL error: failed to load driver: swrast

(xfwm4:4136): xfwm4-WARNING **: 20:16:49.262: Could not create GLX context.
(xfwm4:4136): Gdk-WARNING **: 20:16:49.263: The program 'xfwm4' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 2452 error_code 2 request_code 151 (GLX) minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

It is obvious that the xfce display manager is not working
properly.
I am leaning towards the conclusion that my problem is self-inflicted, because I installed MX-ahs., then switched to a normal MX kernel. There seem to be non-kernel mx-ahs packages present? There are no bug reports so it must be my personal issue.
I have no idea how MX separates ahs versions from normal versions in its repos. I naively thought that only the kernel was involved in ahs… but this seems not to be so.
Therefore, I think a fresh install is called for. This time I will use the normal non-ahs MX version, I dont need ahs any more.
Before reinstalling I will move control of grub from MX to Void. That should ensure I retain control of booting.
My /home is a separate partition so I can easily preserve data and settings.

5 Likes

Hi Neville, :wave:

thanks for your detailed feedback.

I´m sorry you couldn´t get rid of the problem.

O.K., that could be it then.

Great. That´s how I do it as well on my main system.

I hope a fresh install - this time the non-ahs version - will give you a fresh start, devoid of any problems.
Good luck with it.

Cheers from Rosika :slightly_smiling_face:

2 Likes

Well I copied the current MX ( root and home) to another disk, then reformatted the partitions, and did a fresh Mx23 install.
All seemed to go well, except I have issues with UUID’s. and with kernel boot parameters.
The window manager is now working without any problems.

2 Likes

Hi Neville, :wave:

seems you made quite some progress. :+1:

But I don´t quite understand.

I get the part of copying the root and home partitions to another disk.
But if you reformat them, then all their content will be lost, right?

Cheers from Rosika :slightly_smiling_face:

1 Like

I reformatted the original, not the copy. I use reformat to clear the old partitions before doing a new install.

Sorry, I worded that badly.

2 Likes

Hi Neville, :wave:

Ah, I see. Thanks for explaining, Neville :heart: .

Yes, reformatting the old partiton seems like a good idea.

Many greetings from Rosika :slightly_smiling_face:

1 Like

I was only able to boot MX by typing ‘e’ at the grub menu and editing the linux line to change /dev/sdb3 to a UUID and adding a kernel boot parameter. Not very convenient.

So, I went into MX, edited /etc/default/grub, adding the line

GRUB_CMDLINE_LINUX="intel_iommu=off"

and I checked /etc/fstab

#Entry for /dev/sdb3 :  /
UUID=f364e70b-5563-4ef4-8c0b-3a3b873ca123 / ext4 discard,noatime 1 1
#Entry for /dev/sdb1 :  ESP
UUID=F536-33BF /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0
#Entry for /dev/sdb4 :  /home
UUID=e4ab1c55-d8aa-4448-b5ff-305bb8c3649c /home ext4 noatime 1 2
#Entry for /dev/sda3 :
UUID=23785d73-fcac-40f2-bcd6-e2a77432bdf7	none	swap	sw	0	0

That seems OK, it has a UUID for the root filesystem

So I did

update-grub

then checked to see it changed the /boot/grub/grub.cfg file… it did
Then rebooted … and exactly the same problem ???
My stupid fault.
I have Void in charge of grub, so I should first go into Void and do

update-grub

So that the /boot/grub/grub.cfg file in Void is updated to reflect the changes I made in MX

Then reboot, and … it works… MX boots perfectly without me having to intervene. … and it can see the external disk that required “intel_iommu=off”

Great , now I can configure things.
First, Xfce has no bottom panel, only the system tray at the side.
Found out I need the package

xfce4-panel-profiles

and then I could use Setting → Panel Profiles to change to the Xfce16 layout, which allows a bottom panel.
Then I could add my CPU Graph and Network Monitor to the bottom panel.
I also increased the Workspaces to 4 , and put the first Panel ( system tray) at the top.
Now it looks exactly like my Void Desktop

Still lots to do

  • import browser files
  • import email files
  • install packages ( R, Latex, …)
  • install printer drivers and configure printers.
  • install scanner drivers.
  • other

A fresh install may fix a problem, but it puts you on a long road to recovery

5 Likes

Hi Neville, :wave:

congratulations on your success. :+1:
You did a great job.

Many greetings from Rosika :slightly_smiling_face:

2 Likes

We’ve all done something similar. :slight_smile:

3 Likes

That took more than a week.
Latex is easy enough to install.
but
R required compiling from source code, because I need R with OpenMP ( for parallel processing) , and the R binary in the Debian(MX) package system is not compiled with OpenMP.
The worst part of compiling R is finding all the libraries it needs and installing them. There is a configure script, and when you run it , it stops and says it cant find some library or some .h file… so you guess which package supplies that, install it, then run configure again, and it stops on the next missing item . I had about 50 rounds of that spread over a week. Tonight, success… I have a working R binary and it uses OpenMP.

One of the reasons I like Void is that its R binaries are up to date and are compiled with OpenMP. … why cant Debian do that. ?

In Gentoo, R compiles by default with OpenMP.

I cant imagine why Debian would think that anyone would not want to use parallel processing in a modern computer.
It is important in R , because most most scientific calculations involve matrix arithmetic.

3 Likes