Created attachment 558184 [details] Settings/System screenshot Following Sakaki's - brilliant - methodology and after installing gnome-wayland on a Macbook Air user PC, the user PC screen turns out black when gdm is started from the helper PC (through ssh). The command is: systemctl start gdm Invoking "systemctl status gdm" shows gdm is running. However, as soon ans this starting command is run, the user PC screen becomes black and unresponsive. Commands like ALT-F2 + R or Fn-ALT-F2 + R on the user PC do not appear to do anything. It requires a reboot. Reinstalling gnome-base/gdm did not solve the problem but exhibited the same messages as reported in bug 585976. The log file "emerge.log" did not show any error. My user .xinitrc is: export XDG_MENU_PREFIX=gnome- exec gnome-session On the user PC, after logging in as user and invoking "startx", the gnome window shows up fine and looks the same as a "regular" gnome-wayland, with the same functionality. A screenshot of the Settings/System is attached and looks fine. So, the issue appears to be related to gdm, somehow. Also attaching config and 'emerge --info gdm'.
Created attachment 558186 [details] emerge_info_gdm
Created attachment 558188 [details] .config
Do not have a user .xinitrc. What you have is vastly incomplete for what GNOME needs, and by having it, you shortcircuit much of the stuff that would get run. That said, I have no idea if this is of relevance to your problems, especially with wayland.
I followed "Sakaki's EFI Install Guide/Setting up the GNOME 3 Desktop". Here is the section of interest: .... some text deleted ..... Delete the current contents of .xinitrc (you can use Ctrlk inside nano to delete a line at a time), and replace with the following text: FILE ~/.xinitrc Replace existing text with the below to start GNOME export XDG_MENU_PREFIX=gnome- exec gnome-session Save and exit nano. ..... some text deleted ...... So, I do have a user .xinitrc: jplx-airgn2 ~ # su --login jplx jplx@jplx-airgn2 ~ $ ls -al total 108 drwxr-xr-x 18 jplx jplx 4096 Dec 20 10:45 . drwxr-xr-x 4 root root 4096 Dec 14 23:43 .. -rw------- 1 jplx jplx 2716 Dec 20 10:34 .ICEauthority -rw------- 1 jplx jplx 56 Dec 20 10:34 .Xauthority -rw------- 1 jplx jplx 875 Dec 20 10:29 .bash_history -rw-r--r-- 1 jplx jplx 127 Dec 6 22:07 .bash_logout -rw-r--r-- 1 jplx jplx 204 Dec 6 22:07 .bash_profile -rw-r--r-- 1 jplx jplx 551 Dec 6 22:07 .bashrc drwxr-xr-x 14 jplx jplx 4096 Dec 20 10:42 .cache drwxr-xr-x 13 jplx jplx 4096 Dec 20 10:44 .config drwx------ 3 jplx jplx 4096 Dec 19 10:28 .dbus drwx------ 2 jplx jplx 4096 Dec 19 10:29 .gnupg -rw------- 1 jplx jplx 45 Dec 19 11:32 .lesshst drwxr-xr-x 3 jplx jplx 4096 Dec 15 17:11 .local drwx------ 5 jplx jplx 4096 Dec 20 08:14 .mozilla drwx------ 3 jplx jplx 4096 Dec 20 10:42 .pki -rw------- 1 jplx jplx 56 Dec 20 10:34 .serverauth.2339 drwx------ 2 jplx jplx 4096 Dec 4 16:04 .ssh -rw-r--r-- 1 jplx jplx 49 Dec 19 10:25 .xinitrc drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Desktop drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Documents drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Downloads drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Music drwxr-xr-x 2 jplx jplx 4096 Dec 19 13:07 Pictures drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Public drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Templates drwxr-xr-x 2 jplx jplx 4096 Dec 19 10:28 Videos jplx@jplx-airgn2 ~ $ cat ~/.xinitrc export XDG_MENU_PREFIX=gnome- exec gnome-session jplx@jplx-airgn2 ~ $ whoami jplx So, I do have .xinitrc for user "jplx"
.xinitrc should not be used. Delete .xinitrc and use XSESSION=Gnome startx - or simply set up XSESSION to Gnome via /etc/env.d as instructed in official pages and just use startx. This is for command line launching of a X11 GNOME session and of course won't help any for the wayland conundrum. Personally I am targeting properly working wayland and defaulting to it once we have GNOME 3.30, due to various issues with it on 3.24 due to the underlying graphics system moving forward, while unfortunately gnome upgrades have been delayed, triggering some new issues (wayland used to be rather stable for me 1-1.5 years ago with 3.24, but now had lots of trouble with old gnome). I'm pretty sure with that given .xinitrc you'll miss various things, like a user dbus session bus, leading to even gnome-terminal not launching. Though maybe with systemd, it'll autostart anyways, but was just an example of the trouble it can cause, if not much longer (replicating what XSESSION without an .xinitrc would do). My personal suggestion would be to use X11, if that works, and retry wayland with 3.26, 3.28 and 3.30 - seeing if things are better then. That doesn't mean you would have to remove the USE flag - you can instruct gdm to always use only X11 with a configuration file and occasionally try to flip it back to allow wayland too, to test. Once we do have 3.30 (or 3.32), and wayland still has trouble, then I'd be interested to get to the bottom of it. As-is, it might just be bugs that are long fixed in 3.30, and I'd like to concentrate getting us to 3.30 faster instead of trying to find what to backport to 3.24 or 3.26.
I installed sddm. When starting it with "systemctl start saddm", it shows a login window and I am able to log into Wayland-Classic or Gnome but not Gnome-on-Wayland. It is a practical solution for me at this point. However, when attempting to use gdm with "systemctl start gdm" the login window never comes up. Looking at dmesg and "journalctl -b" shows that gdm had a segmentation fault. The crash occurs before performing any login and therefore does not appear to be related to Wayland but rather to gdm itself. Is there a way to get gnome 3.26 or 3.28 now? When I run "emerge --search gnome", I do not see it. THank you for your advice and help.
The majority of 3.26 is available in ~arch - but a few non-core things are missing and most of the meta packages (including gnome-base/gnome); but by deep upgrading an ~arch system has 3.26. If your gnome-wayland crashes, then a wayland-enabled gdm will crash as well. GDM itself has absolutely no GUI - the login greeter it uses is gnome-shell itself; so if gnome-shell in wayland doesn't work, then gdm in wayland will not either. That said, if wayland gnome-shell crashes, then GDM is supposed to be trying Xorg gnome-shell as a fallback after the crash - and it does for me. To force GDM to NOT try wayland, you can either look into /etc/gdm/custom.conf and do the necessary deed in there (remembering to undo it once wayland does work for you, or you can't get wayland sessions launched via GDM - unlike SDDM, gdm requires to be using wayland itself to start wayland DE sessions), or reinstall gdm without USE=wayland (again, later adding it back, once it works). If either of that helps for GDM, then somehow the intended fallback seems to not work for you for some reason after a wayland issue. Please let me know here in a comment how that works out for GDM.
Created attachment 558382 [details] dmesg
Created attachment 558384 [details] journalctl -b
In /etc/gdm/custom.com, I uncommented the line "#WaylandEnable=false" and started gdm but it failed again. So, I left it commented out for now. I started gdm and then stopped it after about 30 seconds. I am enclosing the dmesg and 'journalctl-b' as a reference: It may help you. dmesg shows quite a few segmentation faults after gdm was started. journalctl shows that gdm was started at 17:26:59. The failure occurred at 17:27:03 "Failed to apply DRM plane transform 0: Invalid argument" Then gnome-shell reported a segfault right away.
Can you check if gdm-3.30.3-r2 for bug 613222 happens to help for your case too?
I am not familiar about getting this new gdm-3.30.3-r2 file. Here is what I did, following sakaki methodology: 1) I created a gentoo-git file in etc/portage/repos.conf directory: [gentoo-git] location = /usr/local/portage/gentoo-git sync-type = git sync-uri = https://anongit.gentoo.org/git/repo/gentoo.git priority = 50 auto-sync = yes 2) I activated this new repository: emaint sync --repo gentoo-git 3) In /etc/portage/package.mask, I masked all files in a new gentoo-git-repo file: */*::gentoo-git 4) in /etc/portage/package.unmask, I unmasked gdm in a new gdm file: gnome-base/gdm::gentoo-git 5) When I tried to emerge gdm with your new revision, I got the installed file only: jplx-airgn2 /etc/portage/package.unmask # emerge --pretend gdm !!! Section 'gentoo-git' in repos.conf has name different from repository name 'gentoo' set inside repository These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] gnome-base/gdm-3.24.3-r1 jplx-airgn2 /etc/portage/package.unmask # emerge --pretend =gdm-3.30.3-r2 !!! Section 'gentoo-git' in repos.conf has name different from repository name 'gentoo' set inside repository These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy "=gdm-3.30.3-r2". Not sure what I did wrong. Not sure either about the error messaage:!!! Section 'gentoo-git' etc... Please help.
You don't need to do anything with an extra repository. You can get rid of that, and just make gdm from main tree visible via package.accept_keywords https://wiki.gentoo.org/wiki//etc/portage/package.accept_keywords
Created attachment 571686 [details] journal after invoking "systemctl start gdm"
Thank you for the info. I got rid of the extra repo and related files. In /etc/portage/package.accept_keywords/ I created a gdm file: gnome-base/gdm ~amd64 (I also tried without ~amd64 but it does not seem to make a difference) I tried: emerge --ask --verbose =gnome-base/gdm-3.30.3-r2 but it did not find anything. Then I did: emerge --ask --verbose =gnome-base/gdm-3.30.3 which did install gdm-3.30.3 Then I attempted to start gdm: systemctl start gdm It failed with a coredump. I added the pertinent part of the journal (comment 14) I could not add the coredump attachement because it is ~2.6MB, which is larger than 1MB allowed on this site.
There is no gdm-3.30.3 in tree; I specifically need you to try with 3.30.3-r2. Your gentoo package tree is probably out of date over a week or more. Sync up. Don't worry about attaching core dumps - they aren't useful to me without your gdm binaries and more. However a backtrace may prove useful, if it still happens with 3.30.3-r2. You can get a basic one with "coredump info <crashed EXE>", and more detailed one via "coredump gdb <crashed EXE>" and then doing appropriate gdb commands. But lets first see how it goes with 3.30.3-r2 and if it crashes, what the log and basic backtrace report is then.
Created attachment 571884 [details] gdm crash coredump info I synced up the system and verified gdm...r2 is used. attached is the coredumpctl info (I use systemd). It seems to show that gnome-shell is crashing. However, remember, the gnome-shell works fine when invoked with sddm. I am in the process of modifying the system to add support for gdb: I installed sys-devel/gdb In make.conf: added -0g -ggdb to the CFLAGS (and removed -pipe because this mackbook air has only 2GB) added splitdebug to the FEATURES
Created attachment 571892 [details] journalctl -b (pertinent part) log file at failure
Just as a quick note, if you go via enabling better gdb support via make.conf (instead of per-package), don't forget about it and upgrade your whole system with it due to its performance impact.
(In reply to jplx from comment #17) > Created attachment 571884 [details] > gdm crash coredump info This is not giving a backtrace for some reason. Get it with gdb if you can: coredumpctl gdb 22143 <wait for gdb to load up with it> bt full
Created attachment 572014 [details] coredump-2465 info with gdb I kept '-pipe' CFLAG in make.conf, as a second thought, to try to update faster and it did work out. I also recompiled the kernel to make sure. The backtrace is attached.
Created attachment 572358 [details] coredump-27408 with gdb and "nostrip" I restored CFLAGS="-march=native -pipe -O2" and FEATURES="split-elog buildpkg" in make.conf. From previous coredump-2465 analysis, the failure appears to be related to x11-wm/mutter and/or gnome-base/gnome-shell So, I created an environment file in /etc/portage/env/debug-cflags: jplx-airgn2 /etc/portage/env # cat debug-cflags CFLAGS="${CFLAGS} -ggdb" FEATURES="nostrip" and activated it for gnome-shell and mutter in /etc/portage/package.env/gnome-shell: jplx-airgn2 /etc/portage/package.env # cat gnome-shell gnome-base/gnome-shell debug-cflags x11-wm/mutter debug-cflags After updating the system, I started gdm to create a new coredump: systemctl start gdm The gdb "bt full" is attached as coredump-27408 It provides additional information.
With recent versions of gdm, there is no failure and gdm appears to be running fine and is successfully launching gnome-wayland on my Macbook Air. So, as far as I am concerned, this bug could be closed. Current version of gdm is 3.30.3-r3
Thanks for feedback
