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.

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

"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:

[daemon]
WaylandEnable=false

Added the debug section for the gdm login:
[daemon]
WaylandEnable=false
[debug]
Enable=true

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?
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

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
GNOME
GNOME Classic
IceWM
IceWM Session
Openbox
WindowMaker

No change.

@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
# 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.

Created attachment 11717 [details]
Latest journal for gdm test

Attachment 11715 is obsolete: 0 => 1

Created attachment 11718 [details]
Todays news

Attachment 11716 is obsolete: 0 => 1

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.

Assignee: bugsquad => gnome

(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.

CC: (none) => olav

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.
Tony

CC: (none) => tablackwell

Hi,

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.

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

Also, mesa and nvidia drivers were updated since...

This is about 8 beta 1.
Beta 2 iso are out. I don't see any new bug on this.

Closing as OLD.

Status: NEW => RESOLVED
Resolution: (none) => OLD