Are you running a 'live' system from USB?
Is the only user 'live'?
Does this problem happen also if you choose Xfce rather than LXDE?
Does it NOT happen with 'autologin'?

> I believe user live should have been set in [group] "nopasswdlogin"

CC'ing Martin.

CC: (none) => lewyssmith, mageia

Select the desktop environment to use before selecting the user.

CC: (none) => davidwhodgins

> Select the desktop environment to use before selecting the user.

That is what i do.

> Are you running a 'live' system from USB?

Yes. With persistence.

> Is the only user 'live'?

Yes

> Does this problem happen also if you choose Xfce rather than LXDE?

No, xfce log in correctly

> Does it NOT happen with 'autologin'?

No.

And now after i tried that and set it backl to no autologin and reboot, i can at the log in select lxde and log in OK.
So something that was not correct before got fixed by that manouver...


One strange settings detail:
In the MCC -> Start -> Autologin: at top there is a checkbox for starting graphical interface at start.
Originally it was not checked, but system started anyway.  I checked it when i disabled the autologin.  I now tested to uncheck it, and now it boots to text terminal and i logged in and startx.


So it seem some settings need be flipped back and forth for things to go right.


Maybe related bug, which I also experience:
In LXDE, clicking MCC icon do nothing, launching mcc from terminal i see 
"polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie"
= Bug 27574 - Authentication problem in lxde.
Difference is that in that bug my user do have a password.

I have reproduced this. The

lightdm[pid]: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "live"

message is a red herring - you get that with any DE. The real problem comes later:

kernel: lxsession[pid]: segfault at 0 ip 0000000000432726 sp 00007fffecd68ec0 error 4 in lxsession[40e000+26000]

Now the strange bit. Having failed to log in via the GUI, use Ctrl-Alt-F2 to switch to a virtual console, then Ctrl-Alt-F1 to switch back to the LightDM greeter. Wait a few seconds and log in to a LXDE session again. The error no longer occurs. And once you have successfully logged in, the error never occurs again, even after a reboot.

The only messages I get in the journal as a result of switching to and from the virtual console are:

systemd[1]: Started Getty on tty2.
kernel: ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM
kernel: nouveau 0000:01:00.0: Enabling HDA controller
kernel: ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM
systemd[1]: systemd-hostnamed.service: Succeeded.

The ACPI and nouveau messages are normal on my laptop.

@Morgan, can you confirm this behaviour?

Thank you Morgan for your clarifications; and Martin for experimenting.

This is really weird. I try to summarise:
* Does it only apply from a 'live' USB with persistence?
* Does it only happen with lightdm?
* It only happens with LXDE.
* Does it happen for any user with no password? [I might try]
* It does not happen with autoLogin.
* Once circumnavigated, it does not happen again for that user.
 !
Await further comment before assigning. But it may be good for Errata.

(In reply to Martin Whitaker from comment #4)

> lightdm[pid]: pam_succeed_if(lightdm:auth): requirement "user ingroup
> nopasswdlogin" not met by user "live"

This complain from lightdm is that his process try to check if user does have a password and it is in "nopasswdlogin" group.

In facts, this is looking for 2 conditions to be meet:
1) user has a valid password.
2) user is member of nopasswdlogin group.

If 1 and 2 are true (as stated above): lightdm ask for password but will accept the good password and a "blank" one and it permits login.
If 1 is false (no password) and 2 is true: lightdm will always permit login.
If 1 is true and 2 false, lightdm will always require the good password to permit login.
If 1 and 2 are false (no password and user not member of nopasswdlogin group), lightdm will refuse login.

> kernel: lxsession[pid]: segfault at 0 ip 0000000000432726 sp
> 00007fffecd68ec0 error 4 in lxsession[40e000+26000]

This is weird.

CC: (none) => ouaurelien

@Lewis,

Further testing:
1. The bug occurs with a netinstall of Xfce + LXDE, using LightDM
2. The bug also occurs with a netinstall of LXDE only, using LXDM
3. The bug occurs with any arbitrary user.
4. The bug also occurs if the user has a password.
5. Xfce and IceWM are not affected. Given that the bug is a segfault in the LXDE session manager (lxsession), we can safely assume it won't affect any other DE.

@Aurelian,

> If 1 and 2 are false (no password and user not member of nopasswdlogin group), lightdm will refuse login.

That is not correct.

(In reply to Martin Whitaker from comment #7)
> 
> @Aurelian,
> 
> > If 1 and 2 are false (no password and user not member of nopasswdlogin group), lightdm will refuse login.
> 
> That is not correct.

Ah?
/etc/pam.d/lightdm
#%PAM-1.0
 	auth       required    pam_env.so
 	auth       sufficient  pam_succeed_if.so quiet_fail user ingroup nopasswdlogin    <= Second LINE
 	auth       substack    system-auth
 	-auth       optional    pam_gnome_keyring.so
 	-auth       optional    pam_kwallet5.so
 	-auth       optional    pam_kwallet.so
 	auth       include     postlogin
 	account    required    pam_nologin.so
 	account    include     system-auth
 	password   include     system-auth
 	session    required    pam_loginuid.so
 	session    optional    pam_keyinit.so force revoke
 	session    required    pam_namespace.so
 	session    include     system-auth
 	-session    optional    pam_gnome_keyring.so auto_start
 	-session    optional    pam_kwallet5.so auto_start
 	-session    optional    pam_kwallet.so auto_start
 	session    optional    pam_lastlog.so silent
 	session    include     postlogin


Normally second line above: this prevents user with no password to login if not member of nopasswdlogin as a valid-password is required on all my M7 systems.

Verified on a M7 Plasma WM after install, the nopasswdlogin group does not exist. Login with a password-less usr is permit. This is inconsistent with MSEC Standard profile and ENABLE_PASSWORD variable which by default is set to YES.

Normally a password-less user should become member of nopasswdlogin and this is accepted by PAM with above file. A same password-less user which is not member of nopasswdlogin group should not be able to login on Console nor on GUI login manager. This behavior is the same in Linux Mint for ages and Debian. I don't know it is not the case with Mageia.

I will retest this tomorrow 13/11/2020.

Great testing!  I leave it with you guys :)

Can we run gdb on lxsession?

Yes if not solved before release, we need to write something in errata.

Status comment: (none) => Affected? try workaround in comment 4
See Also: https://bugs.mageia.org/show_bug.cgi?id=27574 => (none)
Summary: Live user (who per default have no password) can not log in to LXDE because lightdm(?) expect a password => LXDE first login fail - lxsession segfault

Here is a backtrace for the lxsession segfault:

Core was generated by `/usr/bin/lxsession -s LXDE -e LXDE'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000432726 in load_settings (kf=kf@entry=0x1d4b040) at lxsettings-daemon/settings-daemon.c:204
204						for( i = 0; managers[i]; ++i )
[Current thread is 1 (Thread 0x7f43f059a8c0 (LWP 3313))]
(gdb) bt
#0  0x0000000000432726 in load_settings (kf=kf@entry=0x1d4b040) at lxsettings-daemon/settings-daemon.c:204
#1  0x0000000000432cea in settings_daemon_reload (kf=kf@entry=0x1d4b040) at lxsettings-daemon/settings-daemon.c:315
#2  0x000000000042aaab in lxsession_xsettings_option_reload (self=<optimized out>) at lxsession/options.c:867
#3  0x000000000042b798 in lxsession_lxsession_config_key_file_reload_xsettings (self=<optimized out>) at lxsession/settings.c:1912
#4  lxsession_lxsession_config_key_file_on_desktop_file_change (self=<optimized out>) at lxsession/settings.c:1922
#5  _lxsession_lxsession_config_key_file_on_desktop_file_change_g_file_monitor_changed (_sender=<optimized out>, file=<optimized out>, 
    other_file=<optimized out>, event_type=<optimized out>, self=<optimized out>) at lxsession/settings.c:1733
#6  0x00007f43f1ae5ac7 in _g_cclosure_marshal_VOID__OBJECT_OBJECT_ENUMv (closure=0x1d5cdd0, return_value=<optimized out>, instance=<optimized out>, 
    args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x1d5c380) at ../gio/gmarshal-internal.c:1380
#7  0x00007f43f1a220be in _g_closure_invoke_va (closure=closure@entry=0x1d5cdd0, return_value=return_value@entry=0x0, 
    instance=instance@entry=0x1d5dc10, args=args@entry=0x7ffd5e8fd408, n_params=3, param_types=0x1d5c380) at ../gobject/gclosure.c:873
#8  0x00007f43f1a399ba in g_signal_emit_valist (instance=0x1d5dc10, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffd5e8fd408)
    at ../gobject/gsignal.c:3403
#9  0x00007f43f1a39e52 in g_signal_emit (instance=instance@entry=0x1d5dc10, signal_id=<optimized out>, detail=detail@entry=0)
    at ../gobject/gsignal.c:3550
#10 0x00007f43f1ad71cb in g_file_monitor_emit_event (monitor=monitor@entry=0x1d5dc10, child=<optimized out>, other_file=<optimized out>, 
    event_type=<optimized out>) at ../gio/gfilemonitor.c:294
#11 0x00007f43f1b98863 in g_file_monitor_source_dispatch (source=source@entry=0x1d5e250, callback=<optimized out>, user_data=<optimized out>)
    at ../gio/glocalfilemonitor.c:567
#12 0x00007f43f1c8c647 in g_main_dispatch (context=0x1cae5f0) at ../glib/gmain.c:3325
#13 g_main_context_dispatch (context=0x1cae5f0) at ../glib/gmain.c:4016
#14 0x00007f43f1c8c998 in g_main_context_iterate (context=0x1cae5f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib/gmain.c:4092
#15 0x00007f43f1c8cc7b in g_main_loop_run (loop=loop@entry=0x1d78cb0) at ../glib/gmain.c:4290
#16 0x000000000040fe7f in lxsession_main_main (args=<optimized out>, args_length1=<optimized out>) at lxsession/main.c:2038
#17 0x00007f43f12b6d1a in __libc_start_main (main=0x40f1c0 <main>, argc=5, argv=0x7ffd5e8fd7b8, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7ffd5e8fd7a8) at ../csu/libc-start.c:308
#18 0x000000000040f1fa in _start ()

Downgrading the lxsession package to the version on the beta1 ISO (lxsession-0.5.5-2.mga8.x86_64.rpm) appears to fix this bug. This also required installing the lib64appindicator2_1 and lib64indicator7 packages, which have since been removed from cauldron, so is not a usable fix, but does point to where the problem lies.

Fedora have a patch that looks like it would fix this bug too:

https://src.fedoraproject.org/rpms/lxsession/blob/master/f/lxsession-0.5.4-load-settings-nullcheck.patch

Assigning to Nicolas, who is the registered maintainer for lxsession.

Assignee: bugsquad => nicolas.salguero
Source RPM: (none) => lxsession-0.5.5-4.mga8.src.rpm

Fantastic sleuthing, Martin. And for doing the assignment, and pointing up the fix.
For info, please can you say how you downgraded lxsession (+ disappeared libs) back to the beta ISO? I have that on disc; it is useful to know.

If you have it on disc, insert the disc and let your DE auto-mount it in the usual place (for me that would be in /run/media/martin/Mageia-8-beta1-x86_64). Then, as root:

  urpmi --use-distrib /run/media/martin/Mageia-8-beta1-x86_64/x86_64 --downgrade lxsession

If you just have the ISO file, you can mount it as a loopback device, e.g. as root

  mount Mageia-8-beta1-x86_64.iso /mnt

then

  urpmi --use-distrib /mnt/x86_64 --downgrade lxsession

Hi,

lxsession-0.5.5-5.mga8 contains the patch given in Comment 12.

Best regards,

Nico.

Thanks Nico, that fixes it for me. Let's see if Morgan can confirm it.

Great, this got solved quickly!
I confirm it is fixed on same setup as where it failed before :)

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

I wonder if we ought to test on mga7 ?

Don't look for trouble!
Anyway, the fact that the issued M8 beta version worked suggests it would on M7.