Bug 26855 - System installed from 64-bit mga8a1 iso fails to effect graphical login after accepting password
Summary: System installed from 64-bit mga8a1 iso fails to effect graphical login afte...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: Mageia 8
Assignee: GNOME maintainers
QA Contact:
Keywords: NEEDINFO
Depends on:
Reported: 2020-06-24 17:11 CEST by Len Lawrence
Modified: 2020-10-20 21:47 CEST (History)
5 users (show)

See Also:
Source RPM: gdm-3.38.1-1.mga8.src.rpm
Status comment:

Installation bug report from CI mga8alpha1 installation (481.11 KB, application/octet-stream)
2020-06-25 11:01 CEST, Len Lawrence
boot journal for gdm test (13.03 KB, application/octet-stream)
2020-06-25 11:33 CEST, Len Lawrence
dmesg immediately after logging in via sddm after gdm failure. (18.85 KB, application/octet-stream)
2020-06-25 11:40 CEST, Len Lawrence
Latest journal for gdm test (13.81 KB, application/octet-stream)
2020-06-26 07:18 CEST, Len Lawrence
Todays news (19.56 KB, application/octet-stream)
2020-06-26 07:20 CEST, Len Lawrence
greeter log for current login attempt under gdm (11.77 KB, application/octet-stream)
2020-06-27 11:52 CEST, Len Lawrence
greeter log for gdm login to GNOME with Wayland enabled (4.38 KB, application/octet-stream)
2020-06-27 12:29 CEST, Len Lawrence

Description Len Lawrence 2020-06-24 17:11:00 CEST
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):

How reproducible:
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
Comment 1 Martin Whitaker 2020-06-25 10:03:03 CEST
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.

Keywords: (none) => NEEDINFO
CC: (none) => mageia

Comment 2 Len Lawrence 2020-06-25 10:58:53 CEST
"My guess is this will be a graphics driver issue" crossed my mind also.
Attaching the bug report.    Shall try the config test later.
Comment 3 Len Lawrence 2020-06-25 11:01:21 CEST
Created attachment 11714 [details]
Installation bug report from CI mga8alpha1 installation
Comment 4 Len Lawrence 2020-06-25 11:33:06 CEST
Created attachment 11715 [details]
boot journal for gdm test

Obtained from system after logging in via sddm.
Comment 5 Len Lawrence 2020-06-25 11:37:21 CEST
Initially /etc/X11/gdm/custom.conf looked like this:


Added the debug section for the gdm login:

Going after dmesg now.
Comment 6 Len Lawrence 2020-06-25 11:40:48 CEST
Created attachment 11716 [details]
dmesg immediately after  logging in via sddm after gdm failure.
Comment 7 Lewis Smith 2020-06-25 18:05:03 CEST
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?
Off topic
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.

CC: (none) => lewyssmith

Dave Hodgins 2020-06-25 22:18:52 CEST

Keywords: (none) => 8alpha1
CC: (none) => davidwhodgins

Comment 8 Dave Hodgins 2020-06-25 22:24:45 CEST
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
Comment 9 Len Lawrence 2020-06-25 23:28:24 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.
Comment 10 Len Lawrence 2020-06-25 23:39:02 CEST
Just rebooted under the modesettings driver and tried gdm login with
GNOME Classic
IceWM Session

No change.
Comment 11 Martin Whitaker 2020-06-25 23:42:22 CEST
@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.
Comment 12 Len Lawrence 2020-06-26 00:01:52 CEST
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.
Comment 13 Len Lawrence 2020-06-26 07:14:04 CEST
# cd /etc/X11/gdm
# tree
├── custom.conf
├── Init
│   └── Default
├── PostLogin
├── PostSession
│   └── Default
├── PreSession
│   └── Default
└── Xsession

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.
Comment 14 Len Lawrence 2020-06-26 07:18:07 CEST
Created attachment 11717 [details]
Latest journal for gdm test

Attachment 11715 is obsolete: 0 => 1

Comment 15 Len Lawrence 2020-06-26 07:20:40 CEST
Created attachment 11718 [details]
Todays news

Attachment 11716 is obsolete: 0 => 1

Comment 16 Martin Whitaker 2020-06-26 16:23:14 CEST
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.
Comment 17 Martin Whitaker 2020-06-26 17:51:28 CEST
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.
Comment 18 Len Lawrence 2020-06-27 10:08:35 CEST
Thanks for these suggestions Martin.  No time just now but before the end of the day.
Comment 19 Len Lawrence 2020-06-27 11:52:13 CEST
Created attachment 11722 [details]
greeter log for current login attempt under gdm

nouveau driver in operation - no changes to gdm.custom.conf.
Comment 20 Len Lawrence 2020-06-27 11:58:10 CEST
All the old greeter logs are retained in /var/log/gdm numbered from oldest to youngest.  Have copies.
Comment 21 Len Lawrence 2020-06-27 12:21:41 CEST
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.
Comment 22 Len Lawrence 2020-06-27 12:29:19 CEST
Created attachment 11723 [details]
greeter log for gdm login to GNOME with Wayland enabled
Comment 23 Martin Whitaker 2020-06-27 16:05:50 CEST
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.
Comment 24 Len Lawrence 2020-06-27 16:27:02 CEST
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.
Comment 25 Lewis Smith 2020-06-27 16:49:15 CEST
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...
Comment 26 Len Lawrence 2020-06-27 18:26:52 CEST
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.
Comment 27 Martin Whitaker 2020-06-27 20:11:08 CEST
@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.
Comment 28 Lewis Smith 2020-06-29 21:40:36 CEST
(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.

Assignee: bugsquad => gnome

Comment 29 Lewis Smith 2020-07-05 21:53:30 CEST
(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'?
Comment 30 Olav Vitters 2020-07-07 11:22:20 CEST
(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.

CC: (none) => olav

Lewis Smith 2020-07-07 21:48:35 CEST

CC: lewyssmith => (none)

Olav Vitters 2020-07-21 11:20:07 CEST

Priority: Normal => release_blocker

Comment 31 Tony Blackwell 2020-07-21 19:32:54 CEST
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.

CC: (none) => tablackwell

Aurelien Oudelet 2020-09-19 17:51:34 CEST

Target Milestone: --- => Mageia 8
CC: (none) => ouaurelien

Comment 32 Aurelien Oudelet 2020-09-19 18:03:36 CEST

This is release_blocker for a reason.
Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please change the status to "Assigned" when you are working on this.

We will make a decision on the relevance of the release_blocker tag on 1st October 2020 QA meeting.
Comment 33 Aurelien Oudelet 2020-10-20 21:46:25 CEST
Status and relevance of this blocker_release tag.

One month, nothing new?

Testing on VM and on baremetal hardware:
Intel Core i5 6600K 3.5Ghz, 16 Go DDR4-Ram, Nvidia Geforce GTX 455.28-4.mga8 nonfree drivers. Kernel 5.8.14

Install from netinstall ISO 17-10-2020 from http://ftp.free.fr/mirrors/mageia.org/distrib/cauldron/x86_64/install/images/Mageia-Cauldron-netinstall-nonfree-x86_64.iso
Installed GNOME env.

GDM starts, default settings.
Choose default login which is GNOME Wayland after verification, after launching OK!
GNOME X11 => Launch OK.
XFCE => Launch OK.

Log out from all above desktop is OK.

Seems OP was against development version of GDM/GNOME stack (3.37 version). Since there, 3.38 is out, even 3.38.1.

Bug not reproduced.
Decreasing release_blocker

Please add your hardware info.

Keywords: 8alpha1 => (none)
Source RPM: gdm-3.37.1-2.mga8.src.rpm => gdm-3.38.1-1.mga8.src.rpm
Priority: release_blocker => Normal

Comment 34 Aurelien Oudelet 2020-10-20 21:47:16 CEST
Also, mesa and nvidia drivers were updated since...

Note You need to log in before you can comment on or make changes to this bug.