Description of problem: After a multi DE installation of the 64-bit classic iso logging in fails when gdm is used. Version-Release number of selected component (if applicable): Mageia9-beta-1 How reproducible: It happened with the alphas and is reproducible when GNOME is installed as part of a multiple DE system. Not yet tested exhaustively to narrow down the circumstances. It does appear that if GNOME is present then gdm is the default for login control. The situation can be remedied by installing sddm, running drakdm to choose sddm and rebooting. More testing is required. Steps to Reproduce: 1. Install the 64-bit classic iso from a USB device 2. Choose several DEs, including GNOME 3. At first login choose Mate for instance and enter credentials 4. Observe the screen clearing, a pause then the reappearance of the login dialogue. 5. Try again - it loops back endlessly.
just tried this on an intel machine. does not occur here :( does issue occur with nouveau driver?
CC: (none) => westel
Don't know yet. My file server is Intel and there is a machine wih Radeon graphics. Shall check in due course. The issue happens with all DEs and it is not the first time it has occurred here but nobody else has ever reported it so as you imply it may be specific to my setup.
Thanks Ben. After installing GNOME/Plasma/Mate/Xfce/Cinnamon on AMD Ryzen system gdm functioned normally. Third check will be an Intel graphics system.
Tried the nouveau driver on the original (faulty gdm) machine and the problem reappeared. This makes it more likely that the hardware is the problem.
can you add report.bug.xz (found under (as root) /home/drakx/ cheers
maybe also inxi -Fxxz. RAM check ok?
_Fxxxz fingers!
-Fxxxz fingers!
Created attachment 13566 [details] Output of the command `inxi -Fxxxz`
Created attachment 13567 [details] Bug report from Dec 8 installation of beta-1 x86_64 iso
@Ben. Files attached. I don't care to check 32 GB RAM - it would take at least two hours and this is my production machine.
Thanks for your interest, Ben. I just tried this on my Cauldron system; like you - GDM OK. This is clearly a machine-specific problem. NVIDIA GP102 [GeForce GTX 1080 Ti]? No reason here to suspect memory. The install log looks OK. If you (Len) can access a virtual console once GDM has looped, perhaps this might show something: $ dmesg > afile.txt $ xz afile.txt attach the result afile.txt.xz
CC: (none) => lewyssmith
Created attachment 13569 [details] dmesg immediately after the first loop back to login Dropped down to a console after first attempt to login with gdm. Dumped dmesg to a text file. Restored sddm and then rebooted to desktop.
Nothing relevant in the dmesg output. Please repeat the procedure but get the output of "journalctl -b --no-h" instead of dmesg.
CC: (none) => davidwhodgins
Created attachment 13574 [details] Boot journal after failure to login with gdm Obtained journal initially as user then ran the same command with sudo. No idea if there would be any significant differences.
Thanks for the journal. (In reply to Len Lawrence from comment #4) > Tried the nouveau driver on the original (faulty gdm) machine and the > problem reappeared. This makes it more likely that the hardware is the > problem. The journal relates to Nouveau, but it looks as if you first saw the problem using native Nvidia for the graphics: NVIDIA GP102 [GeForce GTX 1080 Ti] Please confirm this. Assigning to tv who mostly updates GDM.
Summary: gdm login after installation of beta1 iso loops forever => gdm login loops forever with NVIDIA GP102 [GeForce GTX 1080 Ti] graphicsCC: lewyssmith => (none)Assignee: bugsquad => thierry.vignaud
> The journal relates to Nouveau, but it looks as if you first saw the problem > using native Nvidia for the graphics: > NVIDIA GP102 [GeForce GTX 1080 Ti] > Please confirm this. Yes, as far as I can recall.
Latest Mageia9 beta1 iso - GNOME installation from GNOME Live session. GNOME on Xorg fails at login but it works for Wayland. NVIDIA GP102 [GeForce GTX 1080 Ti]. On a Ryzen system GNOME and gdm work fine so this is beginning to look like an issue with specific hardware.
Testing and some hints by a user in https://forums.mageia.org/en/viewtopic.php?t=14850
CC: (none) => fri
Sorry folks, the route outlined in the link from comment 19 does not exist. mgauser recommends "Installing Mageia-9(Cauldron) without X from the network (Mageia-Cauldron-netinstall-nonfree-x86_64.iso)". I spent three hours preparing for this and could not find any way to start installing from the network without X. The screens he shows do not correspond with anything I can find in the wiki. His installation seems to be from an iso in a desktop session also whereas mine is booted from an iso on a USB device. Have I missed something?
The checkboxes for installation without X can be found as described in the doc: https://doc.mageia.org/installer/8/en/content/software.html#minimal-install
Also from the forum thread, the issue seems to be caused on affected hardware by an interaction from gnome session with gstreamer1.0-vaapi (or maybe vaapi itself) and removal should make it work where it was reproducible before.
CC: (none) => doktor5000
Thanks guys. Have never needed to know about minimal install so never knew about that page. Always do individual selection. Later.
Followed the prescription for a minimal install of GNOME, removed gstreamer1.0-vaapi, rebooted to the console and tried startx, which failed. startx does not exist. In fact, as this is a minimal install, there seems to be very few system tools available so there is no way to establish an X session and try out gdm.
Does it really need to be a very minimal install to test this? What if you urpmi task-gnome-minimal? (to get startx and whatever is needed) (Um, do it pull deps for wayland or X11?)
Yes I wondered about that and tried the simplest possible test on my production system. Removed gstreamer1.0-vaapi, switched to gdm and rebooted. No improvement. Shall check the minimal system. Shall try installing task-gnome. Thanks.
Installing task-gnome certainly revived X. startx from the initial console takes the user into GNOME classic. Graphical startup does not seem possible - aka I don't know how to implement it at this stage. There are several Wayland libraries and Wayland X-server. gdm is set but never shows up. I had to remove gstreamer1.0-vaapi again - must have sneaked in with task-gnome (765 packages). Cannot see mlocate anywhere.
Graphical startup implemented by installing the proprietary nvidia driver using drakx11. Should have used that in the first place. Does not seem to help but need to check that again.
Rebooted the netinstalled system again and hit the loop problem with GDM so switched to sddm and selected GNOME Wayland. That failed (looped) as well. Selected GNOME on Xorg and that worked fine. So that would narrow down the problem to some issue between Wayland and NVIDIA/X11. No more I can do.
I see you report it is still valid per https://pad.riseup.net/p/mageia9-RC (In reply to Len Lawrence from comment #29) > problem to some issue between Wayland and NVIDIA/X11. So edited header. Leaving thierry assigned as he seem to be for wayland CC kernel and drivers because of Nvidia
CC: (none) => kernelSummary: gdm login loops forever with NVIDIA GP102 [GeForce GTX 1080 Ti] graphics => Wayland login loops forever with NVIDIA GP102 [GeForce GTX 1080 Ti] graphics