Ok, I have already upgraded to Beta 2, I also ran the same command echo ‘n’ | sudo tee /sys/kernel/mm/lru_gen/enabled, but nothing happened, the applications continue to have problems starting or do not run. I add the diagnosis after the update.
eos-diagnostic-240427_151152_UTC-0300.txt (1,2 MB)
I think there are 2 problems that have been occurring for you.
- Apps were getting killed when there was too much memory pressure. I don’t see that in the latest diagnostics file.
- Wayland isn’t working properly all the time. In the latest diagnostics file, a Wayland session is attempted and there are problems, so it falls back to using a regular X11 session. I’m not sure why that’s happening. When you run LibreWolf are you not seeing any window at all? Might be useful to try running
flatpak run --env=MOZ_ENABLE_WAYLAND=0 io.gitlab.librewolf-community.
Well, when I try to open a browser like LibreWolf, nothing happens, the application does not start (it does not run and no window opens), only after several attempts to open it, it runs in safe mode and finally a window opens; This happens with all the browsers I use. Something similar happens with other applications like Libreoffice that, only after several attempts, run in safe mode. Now, I have executed the command flatpak run --env=MOZ_ENABLE_WAYLAND=0 io.gitlab.librewolf-community, and librewolf has started without any problem (a normal window has opened quickly); Is it possible that the same could happen with the rest of the applications? The following image shows the response of the command executed in the terminal
Yeah, I think that’s the issue you’re facing now. Your session is setup as if Wayland is available but it really isn’t. When programs start, they think they should use Wayland and nothing happens.
Can you run the command env | sort from a terminal and paste the text here? Please review the text to make sure there’s nothing sensitive in there like a password.
OK, there is the information:
james@janad:~$ env | sort
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
DESKTOP_SESSION=endless-wayland
DISPLAY=:0
ENDLESS_KEY_USE_SYSTEM_INSTANCE=yes
GDM_LANG=es_CO.UTF-8
GDMSESSION=endless-wayland
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
GNOME_SETUP_DISPLAY=:1
GNOME_SHELL_SESSION_MODE=endless
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/c746c765_de69_4fa7_9303_00a037d6eaed
GNOME_TERMINAL_SERVICE=:1.128
GTK_MODULES=gail:atk-bridge
HOME=/sysroot/home/james
KOLIBRI_USE_SYSTEM_INSTANCE=yes
LANG=es_CO.UTF-8
LOGNAME=james
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/session.slice/org.gnome.Shell@wayland.service/memory.pressure
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/sysroot/home/james/.local/share/flatpak/exports/bin:/var/lib/flatpak/exports/bin
PWD=/sysroot/home/james
QT_ACCESSIBILITY=1
QT_IM_MODULE=ibus
SESSION_MANAGER=local/janad:@/tmp/.ICE-unix/1580,unix/janad:/tmp/.ICE-unix/1580
SHELL=/bin/bash
SHLVL=1
SSH_AGENT_LAUNCHER=openssh
SSH_AUTH_SOCK=/run/user/1001/keyring/ssh
SYSTEMD_EXEC_PID=1623
TERM=xterm-256color
USER=james
USERNAME=james
_=/usr/bin/env
VTE_VERSION=7006
WAYLAND_DISPLAY=wayland-0
XAUTHORITY=/run/user/1001/.mutter-Xwaylandauth.ZNNIN2
XDG_CURRENT_DESKTOP=Endless:GNOME
XDG_DATA_DIRS=/usr/share/gnome:/var/lib/kolibri/data/content/xdg/share:/sysroot/home/james/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/
XDG_MENU_PREFIX=gnome-
XDG_RUNTIME_DIR=/run/user/1001
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=endless-wayland
XDG_SESSION_TYPE=wayland
XMODIFIERS=@im=ibus
I’m having trouble figuring out how to debug this remotely, but it seems that gnome-shell crashed pretty early in the last diagnostics file.
abr 27 15:05:08 janad org.gnome.Shell.desktop[1724]: (EE) could not connect to wayland server
abr 27 15:05:08 janad gnome-session[1611]: gnome-session-binary[1611]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
abr 27 15:05:08 janad gnome-session-binary[1611]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
abr 27 15:05:08 janad polkitd[1219]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.43, object path /org/freedesktop/PolicyKit1/Aut
henticationAgent, locale es_CO.UTF-8) (disconnected from bus)
abr 27 15:05:08 janad gnome-session-binary[1611]: Unrecoverable failure in required component org.gnome.Shell.desktop
If you run coredumpctl does it show anything? If you see /usr/bin/gnome-shell in the EXE column, can you run coredumpctl info /usr/bin/gnome-shell > crash.txt and then attach crash.txt here?
Another experiment that would be useful: Can you create another user account and see if the same app startup issue exists on the new account?
Another check:
Open a terminal, become root with sudo -i then run:
ostree fsck
This will check system files for any possible corruption
Well, I have already created a new user on my PC, I have tested opening those applications that have some error and open without any problem, I am going to attach the diagnosis in case it is useful with that new user.
eos-diagnostic-240506_143218_UTC-0300.txt (344,8 KB)
This is what appears after executing the command:
james@janad:~$ sudo -i then run:
ostree fsck
[sudo] contraseña para james:
-bash: -c: línea 1: error sintáctico cerca del elemento inesperado then' -bash: -c: línea 1: then run:’
Validating refs…
Validating refs in collections…
Enumerating commits…
Verifying content integrity of 2 commit objects…
fsck objects (736/109197) [ ] 0%
error: In commits 8fe6cde4febf42b7103c9620a1d0e58f43a3d865a27007f05769405709f82a38: fsck content object 5f9b7e8a1e7951d6eda73f10a2010a2f634674feedbd4d346016fe565e732457: Opening content object 5f9b7e8a1e7951d6eda73f10a2010a2f634674feedbd4d346016fe565e732457: openat: Permiso denegado
Sorry I was not clear with those instructions. Please run it as:
sudo ostree fsck
This is what appears after executing the command:
james@janad:~$ coredumpctl
No coredumps found.
This is what appears after executing the command:
james@janad:~$ sudo ostree fsck
Validating refs…
Validating refs in collections…
Enumerating commits…
Verifying content integrity of 2 commit objects…
fsck objects (109197/109197) [=============] 100%
object fsck of 2 commits completed successfully - no errors found.
If i run coredumpctl info /usr/bin/gnome-shell > crash.txt, thats hapend:
james@janad:~$ coredumpctl info /usr/bin/gnome-shell > crash.txt
No coredumps found.
And appear and crash.txt empty that i can´t upload here.
Hello, is there still something that can be done? The same application execution problems continue and have begun to greatly hinder my academic work. Could you tell me if it is possible to return to the previous version? or if the problem is with my user, how can I format it without losing my information? I will be attentive to any response.
I think the simplest thing for now is to force Xorg to be used. In a terminal, run sudoedit /etc/gdm3/daemon.conf. Make 2 changes to the file:
- Uncomment the line
#WaylandEnable=falseby removing the#character at the beginning of the line. - Uncomment the line
#Enable=trueat the bottom of the file by removing the#character at the beginning of the line.
Save the file after making the changes. You’ll have to reboot for the changes to take effect.
If things are working, then opening a terminal after rebooting and running echo $XDG_SESSION_TYPE should show x11. If it still says wayland, then the changes haven’t taken effect.
I have done each of the steps, and this is what resulted in the terminal;
Don’t spawn anywhere “wyland”, now what should I do, or what should I expect to happen? I will be attentive to send any information.
Try running any apps you were having problems with before like LibreOffice and see if they display correctly.
I have carried out new tests with different applications, but the problem persists randomly; Sometimes, applications open without any problem, but more often they do not open, or they only run, after several attempts, in safe mode.
That is very strange. Can you upload a diagnostics file after that happens?