MATE session fails to initialise in fully patched 20.04 #297
Comments
|
That looks like X is crashing. Note that Ubuntu MATE 20.04 uses MATE 1.20 (EDIT 1.24, we are now on 1.26 which is the supported version) -which is now three major versions old and not
supported by our very small team. If it worked when Ubuntu-MATE 20.04 came out it should work now unless something
else broke. From your logs it looks like X (aka xorg) is crashing as no MATE component is connecting to it successfully.
My guess is you got a bad xorg update somewhere, or perhaps a bad file for one of those packages
|
Is there a PPA I can use on LTS to keep MATE updated or do you recommend avoiding LTS with MATE? |
|
@lukefromdc Ubuntu 20.04 has 1.24 AFAICT. It's not latest, but nowhere near as bad as 1.20 would be :) This said, it indeed looks like it's X terminating, so that could be 2 components I guess: the session scripts, or X itself. If it's X, it can be drivers or so as well. Does your desktop start with any other environment? fluxbox or something else very tiny? And does this happen with a freshly created user as well? |
Working fine with gnome shell, X only crashes in MATE and is perfectly stable in gnome. Nothing in the logs is pretty annoying. I did a clean install of all MATE packages but nothing works. I'm using Nvidia 470 and moving to 510 soon. |
|
Note that gnome-shell uses Wayland by default now, and runs X requiring apps under xwayland. You might have a problem with your xorg install
|
|
I don't know enough about Ubuntu anymore to answer Ubuntu-specific questions about PPAs etc
|
I am not using the Wayland session but the classic xorg one. |
|
Are you starting MATE from GDM by any chance? GDM now defaults to Wayland at least when system is initially installed as a GNOME session if not all the time. This may be creating issues for older DE's on Xorg I notice you are getting If I open xterm from terminal and kill it with the force-quit applet I get This implies that something (possibly GDM if you are using it) is trying to open what appears to be a second instance of Xorg or open it on a different TTY (not sure which) and that is not working. Maybe GNOME has code to adapt to this behavior from GDM? I do not know as I do not use GDM or GNOME. If |
I am using lightdm, in both MATE and Gnome3. Disabling compositing fixes the issue. Using the nvidia 510 driver and gaming on that fine but looks like Marco cannot use this. Others with same problem on both Nvidia 495 and Nvidia 510 drivers: https://forums.linuxmint.com/viewtopic.php?f=59&t=367590 Looks to be duplicate of mate-desktop/marco#720 |
|
I am also using Lightdm with no problems whatsoever, but I am not on Ubuntu. Two users have now reported this, I am all but certain this is distro-specific and has something to do with how Xorg is being managed. Cannot reproduce it myself though. With no landline I cannot download DVD images for testing so I cannot duplicate your setup for testing with my resources. Also I do all testing on my real system and have no experience running VM's, entirely ruling out cross distro testing on my end.
Thus, someone who can duplicate your exact setup has the best chance of debugging this. If you have the bandwidth to pull an installer image and either VM experience or a spare drive to put it on, consider trying the last Ubuntu release and seeing if this occurs. Also if this problem did not begin until AFTER a round of Ubuntu updates, than Ubuntu distributed a bad update of something related to Xorg.
At any rate, we might not be able to fix this if it is an Xorg bug that GNOME's Xort session simply doesn't hit or has patched around. Ubuntu will have to deal with it and needs to look for the probably bad update
|
Nvidia 510 or 495 driver is the cause. |
|
If the Nvidia driver is to blame, that might be triggeres by the xpresent issue with that driver and marco. Try getting to dconf-editor in another session/DE and turning compositing off in Marco and see what happens. If you can then start a MATE session, xpresent is crashing X as well as marco with that driver.
Also you could try the Nouveau driver just to see if your MATE session then starts.
I cannot test this as I do not use proprietary drivers and thus have no nvidis cards new enough to be supported.
|
Yes, as I wrote in the linked issue I am able to run Marco with compositing disabled. Gnome3 has no problems however. |
|
That confirms this is another Xpresent issue
|
Yes, same as mate-desktop/marco#548 - as newer Nvidia drivers are released this is going to be seen on more systems. Marco needs to implement a fix on their side. |
|
One option would be simply to revert the commits that enabled xpresent in the first place.Note that marco can be built with or without xpresent support.
If nobody on the team has an Nvidia GPU supporting recent drivers, than we would not be able to troubleshoot this directly, only to disable xpresent. If Metacity has a fix, we could try that and ask Nvidia users to test it.
If not, best fix might be to check for the driver being nvidia at runtime and disable xpresent if ir is found.Remember that closed drivers are harder for open source devs to work around due to the noncooperation of the vendor
|
Sure, I'd be happy with a flag to disable xpresent until the feature is better understood. |
|
I myself will have to leave that to the folks on the team who have been working on marco and know there way around it. Most of my experience has been on the panel, its applets, and caja and in particular dealing with issues that related to the GTK2->GTK3 transition.
|
|
Commit @vkareh and others writing code for marco, do you want to put some kind of runtime detection on Xpresent support, revert it entirely, find a fix Metacity already implemented, or something else? I know distros can disable this, but many are not going to do that over a broken proprietary driver. If nobody on the team has recent Nvidia hardware we will have to fix this by blacklisting the xpresent/nvidia combination, turning off xpresent unconditionally, or waiting for nvidia to fix their broken driver. I certainly cannot afford to buy hardware for testing this and cannot buy GPUs at all now due to Micro Center demanding ID to do so. |
|
I don't have modern nvidia hardware, but maybe we can add a gsettings to allow toggling this on and off? Metacity does not support XPresent, so we cannot rely on a backport for this. xfwm4 uses xpresent and they have a conditional load based on the video card, but it relies on GLX rendering so it means a huge set of changes to the marco compositor. I think the only option at the moment is to provide a gsettings toggle or just disable it entirely (this will bring up regressions) |
|
A gsettings toggle would at least allow Nvidia users to enable composition again. Sorry to hear that the team doesn't have access to this hardware. Is there any testing I could assist with here? |
|
I have NVIDIA RTX 3090 and 3080Ti. I am running MATE Desktop 1.26 on Ubuntu MATE 21.10 with Composited Marco as the default windows manager on two workstations. Everything is working. However, I am currently running the NVIDIA 470 drivers because I've experienced a regression with the newer 495 and 510 drivers that seems similar to what is being reported here. |
|
I am confirming the issue I have upgraded to the NVIDIA 510 drivers. I had to create a schema override to disable Marco's compositing-manager system-wide in order for LightDM to correctly initialise. Create [org.mate.Marco.general]
compositing-manager=falseThen compile the schemas with: sudo glib-compile-schemas /usr/share/glib-2.0/schemas/And also disable the compositing-manager for your session: gsettings set org.mate.Marco.general compositing-manager falseWith the compositing-manager completely disabled you will at least be able to bring up X11 and your desktop session. Coincidently I have recently created a wrapper for Marco which uses picom as the compositor. And that is what I am using as a workaround right now. Here's my marco-picom wrapper. Put that script in gsettings set org.mate.session.required-components windowmanager marco-picom@vkareh Are you proposing a gsettings toggle just to sidestep Xpresent entirely but retain compositing using Marco? I am also testing building Marco without Xpresent support. |
Looks like Xpresent support was added to Metacity in 2020. |
|
I have built Metacity 3.42 with Xpresent support, which is behind a gsettings option that defaults to xrender. When metacity is set as the required window manager in MATE with Xpresent set as the compositor the same failure to bring up a desktop session is encountered. Tagging @muktupavels as an FYI. I have also built Marco without Xpresent and as expected it falls back to Xrender which works with the new NVIDIA drivers and also preserves compositor support. |
Please open new issue for |
|
Closing this as it is a bug in xorg-xserver: Anyone using Ubuntu MATE affected by this issue can get a build of Marco with Xpresent disabled here: |
Expected behaviour
MATE session starts
Actual behaviour
Session crashes and returns to greeter instantly.
Crashes started occuring after an update. Created fresh user with no profile and errors still occur. Gnome-shell works fine.
Errors in .xsession-errors:
Steps to reproduce the behaviour
Login
MATE general version
Latest Ubuntu MATE 20.04 packages
Package version
Latest Ubuntu MATE 20.04 packages
Linux Distribution
Ubuntu MATE
Link to bugreport of your Distribution (requirement)
The text was updated successfully, but these errors were encountered: