Description of problem:
A freshly installed mga8alpha1 system boots fine but fails to launch X on an attempt to login via the default gdm display manager. It simply presents the login prompt again.
Version-Release number of selected component (if applicable):
Not known yet but experiments with gdm indicate that it affects Cauldron also.
A workaround is to start sddm in console mode. That may work for other display managers. No faults reported in the journal or dmesg - they would be right near the end of the files.
Steps to Reproduce:
1. Install Mageia8 from the latest mga8a1 iso
2. Boot to the login screen
3. Observe the screen blanking for a few seconds and then reverting to login
Does this just occur with the default GNOME session, or also with GNOME on Xorg and IceWM?
If you can uncomment the line "#Enable=true" in the "[debug]" section of /etc/X11/gdm/custom.conf and restart gdm (or just reboot), you should find a lot more messages in the journal, which may help to pinpoint the problem.
My guess is this will be a graphics driver issue, as I didn't see the bug in my tests. Please attach the /root/drakx/report.bug.xz file so we can see your exact setup.
"My guess is this will be a graphics driver issue" crossed my mind also.
Attaching the bug report. Shall try the config test later.
Created attachment 11714 [details]
Installation bug report from CI mga8alpha1 installation
Created attachment 11715 [details]
boot journal for gdm test
Obtained from system after logging in via sddm.
Initially /etc/X11/gdm/custom.conf looked like this:
Added the debug section for the gdm login:
Going after dmesg now.
Created attachment 11716 [details]
dmesg immediately after logging in via sddm after gdm failure.
Having burned my fingers with 'round 1' installed for 'round 2' (implied) reports, I shall install Classic alpha1 round 2; then play around the start of comment 2:
> Does this just occur with the default GNOME session, or also with GNOME
> on Xorg and IceWM?
ISO 'rounds' have always been problematic re knowing what one is playing with. The ISO names are already so long, including e.g. "Mageia-8-alpha1", would it not be easy to make that "alpha1a" etc for successive rounds? Thus one would know that ISOs have advanced.
Which round is used should always be included using the DATE.txt file contents.
For the Mageia-8-alpha1-x86_64.iso, this is currently
Mon 22 Jun 2020 10:21:34 AM CEST
@Martin, comment 1.
Sorry, I did not answer this question. I have tried several DEs already, but with sddm. I shall need to rerun the logins, each with gdm. I have had serious personal problems today which have slowed me down.
Meanwhile the test of gdm with Mate and the modesettings driver recommended at the QA meeting today does not show any change in behaviour. After switching to sddm to complete login, checked xorg.conf to make sure that the modesettings driver was loaded.
Time for one DE test tonight.
For the record, these tests are for the 2020-06-22 iso.
Just rebooted under the modesettings driver and tried gdm login with
@Len, sorry to hear you've had problems, and hope things improve.
Note that adding xdriver=modesetting on the boot command line only works when booting the Live ISOs. For an installed system, you have to select it using MCC/drakx11. This would also force a switch from the nvidia to the nouveau kernel driver.
To get the extra debug output from gdm, we need the output from journalctl, run as root.
Thanks Martin. Yes, in fact I used drakx11 in a graphical session to set the modesettings driver and the switch to nouveau succeeded. I have already looked at the journal and extracted the gdm references but had not modified the gdm config file. Shall re-run those tomorrow and post the journal file. And yes I was aware that journal diagnostics need to be obtained under root.
[OT] You have done a marvellous job of all this, and so quickly. And now you are joining the kernel support group! You deserve a vote of thanks.
# cd /etc/X11/gdm
│ └── Default
│ └── Default
│ └── Default
Modified custom.conf and rebooted.
Logged in under sddm.
$ dmesg > dmesg.2020-06-26
As root in user directory recorded latest journal.
# chown lcl:lcl journal.2020-06-26
Attaching both files.
Created attachment 11717 [details]
Latest journal for gdm test
Attachment 11715 is obsolete:
Created attachment 11718 [details]
Attachment 11716 is obsolete:
From the journal, it looks to be a problem with starting the X server. It's odd that it works for sddm but not for gdm. What we need is the X server log, but IIRC, gdm hides that. I'll have to do some digging to see if I can find how to get it.
Whilst you have the nouveau driver enabled, you could try changing "WaylandEnable=false" to "WaylandEnable=true" in /etc/X11/gdm/custom.conf, to see if it works with Wayland even if it doesn't work with X.
Len, before any experiments with WaylandEnable=true, could you attach /var/log/gdm/greeter.log if it exists. That seems to be where gdm stashes the X server log.
Thanks for these suggestions Martin. No time just now but before the end of the day.
Created attachment 11722 [details]
greeter log for current login attempt under gdm
nouveau driver in operation - no changes to gdm.custom.conf.
All the old greeter logs are retained in /var/log/gdm numbered from oldest to youngest. Have copies.
Enabled Wayland and rebooted and Bingo! Logged in to a fully functional GNOME session.
Attaching the greeter log just now. Shall look for any Wayland logs.
Created attachment 11723 [details]
greeter log for gdm login to GNOME with Wayland enabled
Well, I'm baffled! Looking at that first greeter.log, everything seems to be working. There are some error messages, but I see the same thing on my test system with an old NVIDIA graphics card configured to use nouveau + modesetting.
At least we have one workaround with nouveau + Wayland.
All iso testing here so far has been on one workstation. Although there is no logical reason to suspect hardware I shall at some point try out other machines, all nvidia graphics unfortunately.
Just tested M8a1r2 Classic x64 (without updates as yet), 6 desktops, defaults to gdm/Gnome.
Login worked normally to working desktop:
Plasma, Gnome Wayland, Gnome Xorg, Cinammon, LXDE, Mate
Showed the problem: login to black screen, back to login: Xfce
Work that out! Can I provide a log? This needs to be assigned somewhere...
Installed the classic iso on another workstation and booted using the nvidia390 graphics driver. All desktops but no updates yet.
Tried gdm logins on GNOME, GNOME Classic, Plasma, Mate, Xfce and all succeeded.
So, if this bug is related to use of specific hardware what can we do?
Detect the null login and switch to sddm in the background? There was a note recently about this depending on a known problem - cannot remember the specifics or if anybody is trying to fix that.
@Lewis, I've seen a problem with Xfce and GDM since Mageia 7. For me it works if I haven't logged into another DE first (rebooting resets whatever causes the problem). As nobody else complained, I never investigated further.
@Len, I think we put it in the errata and wait to see if it gets fixed as GNOME gets closer to release. I think the note about it depending on a known problem was a misunderstanding - confusing it with the issue Bill is seeing with the latest Intel GPUs.
(In reply to Martin Whitaker from comment #27)
> I've seen a problem with Xfce and GDM since Mageia 7
> As nobody else complained, I never investigated further.
Too true! Let sleeping dogs lie. For the first point, I used to (pre M7 ?) test every display manager with every desktop, so am surprised I did not find it. I will try it specifically as you describe when next back there.
Assigning to Gnome group anyway.
(In reply to Martin Whitaker from comment #27)
> @Lewis, I've seen a problem with Xfce and GDM since Mageia 7. For me it
> works if I haven't logged into another DE first
I have specifically tried Mageia 7, GDM, logging in first to a desktop !Xfce, logging out, then in again to Xfce. It always works OK.
Off topic again: I notice that, at least from GDM, logging in to Xfce no longer shows briefly the famous garbled screen, but a real black one until the proper desktop shows. Has that bug 'gone'?
(In reply to Len Lawrence from comment #26)
> So, if this bug is related to use of specific hardware what can we do?
There's magic in GNOME (IIRC GDM) to automatically shut off Wayland for certain hardware. If it doesn't work for some hardware we can file a bug upstream and let them deal with it. This as a quick response, I still have to read the various log files attached here.
The OP problem ws certainly something I'd commented on in qa-discuss with alpha1.
Have just done a x86_64 beta1 install and not seen it on a single machine. Regrettably don't recall which hardware platform I saw it on previously.