Description of problem: I installed Mageia 64 bit using the mini CD. I installed just the console (no GUI) and then I added KDE with urpmi task-kde-minimal. After rebooting, KDM appears and when I try to login it tells me that I must install some packages. I do that and then the 3D effects dialog appears. No matter what I select, a new dialog pops up telling me that I have to logout for the changes to take effect or something like that. After I logout, the 3D effects dialog reappears, then the logout dialog reappears and so on. Then I realized that to desktop environment was selected by default. After I select KDE then all is good. Shouldn't be one of the desktop environments be selected by default? Maybe it is worth mentioning that I kept the /home partition from alpha 1 when I installed alpha 2. Anyone else experienced this stuff? Reproducible: Steps to Reproduce:
typo: "Then I realized that to desktop environment was selected by default" should read "Then I realized that no desktop environment was selected by default"
issue still present ? ( yes the answer is late :/ )
Hey Manuel, It's never too late even if that bug was for Cauldron 1. I am now using Cauldron 2 with a screwed up fglrx (my other bug 2426 has been there for at least two weeks). So having nothing to lose, I decided to reinstall Mageia 2 using boot.iso. I performed the minimal install (no GUI) then I installed KDM. I noticed that it pulled some kde dependencies including kde runtime and kdebase so I thought I didn't have to install anything else in order to have KDE. Then I rebooted and the login screen offered two buttons: One like "edit" and one like "power on/off". The Edit button offers 4 options: Default, Custom, drake3D and Failsafe. None of them work. No matter what you choose, the login screen disappears for two seconds then reappears. So no KDE there. Then I went to the other button which gives the option to go console mode. When I chose that option the screen blackened and nothing else happened. I rebooted using Ctrl+Alt+Del and went with the failsafe in GRUB. I wanted to install task-kde-minimal. Doesn't work. Curl fails with error code 6. At this point I gave up. Mageia wins :) Any ideas? Cheers, Corneliu
OK, I reinstalled Mageia using boot.iso. I performed the same minimal install (no GUI) only this time I installed task-kde-minimal and I can confirm that no session is selected by default in the login screen. Because nothing is selected, login fails even if the user name and the password are good. Once I select KDE it's all OK. So yes, the problem has not been fixed. The other issue with the 3D dialog does not occur anymore because by default 3D effects are turned off when using the crappy default radeon driver. Not that fglrx works better, in fact it doesn't work at all.
"OK, I reinstalled Mageia using boot.iso. I performed the same minimal install (no GUI) only this time I installed task-kde-minimal and I can confirm that no session is selected by default in the login screen." What is your dm ? cat /etc/sysconfig/desktop if I am not wrong
I don't have such a file (/etc/sysconfig/desktop) task-kde-minimal has installed KDM as a dependency
see comment 7
Assignee: bugsquad => balcaen.john
Seems I have again forget this one. :/ (In reply to comment #4) > OK, I reinstalled Mageia using boot.iso. I performed the same minimal install > (no GUI) only this time I installed task-kde-minimal and I can confirm that no > session is selected by default in the login screen. Because nothing is > selected, login fails even if the user name and the password are good. Once I > select KDE it's all OK. So yes, the problem has not been fixed. Mikala, something for you ?
Source RPM: (none) => kdm
Nop,rather the installer i would say since no kde session was selected. I guess somewhere the session was set up to lxde & since it is not available it's log in /log out automatically ( lxde is the default DE for the dual arch iso & probably boot.iso too )
CC: (none) => balcaen.johnAssignee: balcaen.john => bugsquad
Source RPM: kdm => (none)
(In reply to comment #9) > Nop,rather the installer i would say since no kde session was selected. > I guess somewhere the session was set up to lxde & since it is not available > it's log in /log out automatically ( lxde is the default DE for the dual arch > iso & probably boot.iso too ) Thx, John :) @ Corneliu Can you please try a Mageia 2 Alpha 2 (or 3) network install, too, and report whether the problem is still there? @ Thierry assigning to you, despite not yet knowing the answer, to avoid this bug being forgotten again
Source RPM: (none) => drakx-installerKeywords: (none) => NEEDINFOCC: (none) => marja11Assignee: bugsquad => thierry.vignaudSummary: Endless loop when trying to login => Login fails after network install
This is a KDM issue. It should work by default.
I tried to do a network install during the Christmas/New Year break but I couldn't. After installing, I rebooted and Mageia refuses to start. I didn't file a bug because I have no time to follow it. I work full-time and I am full-time student as well. There are some weird error messages, I don't remember. It seems that Mageia cooker is way too unstable for me to use on a daily basis. Mandriva cooker used to be more stable two years ago. So I am currently using Fedora because the packages are updated faster.
Mageia doesn't have cooker. If you're using cooker, you're using Mandriva.
OK, it's cauldron. The name doesn't matter.
Hum i'm able to reproduce with alpha3 : - install minimal cauldron (with the -documentation option) - urpmi task-kde4-minimal --nosuggests In that case it's not possible to start kde without choosing kde session. however it seems the problem also affects gnome : After removing kde & installing task-gnome-minimal (i need to check why it's pulling glibc-devel btw) & gdm with --no-suggests i'm not able to log in gnome or gnome-classic. i'm going to check with xdm as display manager but we do have some problems at least for our both major dm.
ok i did more check using the task-kde4-minimal : it does not work with gdm or kdm the error is the same according to auth.log : ==> auth.log <== Jan 13 06:36:23 localhost gdm-password][7841]: pam_succeed_if(gdm-password:auth): requirement "user ingroup nopasswdlogin" not met by user "mikala" Jan 13 06:36:27 localhost gdm-password][7841]: pam_tcb(gdm-password:auth): Authentication failed for mikala from (uid=0) ==> auth.log <== Jan 13 06:39:25 localhost kdm: :0[8787]: pam_succeed_if(kdm:auth): requirement "user ingroup nopasswdlogin" not met by user "mikala" Jan 13 06:39:25 localhost kdm: :0[8787]: pam_tcb(kdm:auth): Authentication failed for mikala from (uid=0) Switching to xdm allow to log in. for task-gnome-minimal i have this : with gdm : ==> auth.log <== Jan 13 06:53:17 localhost gdm-password][9282]: pam_succeed_if(gdm-password:auth): requirement "user ingroup nopasswdlogin" not met by user "mikala" ==> gdm/:0-slave.log <== gdm-password][9282]: pam_tcb(gdm-password:auth): Authentication failed for mikala from (uid=0) ==> auth.log <== Jan 13 06:53:23 localhost gdm-password][9282]: pam_tcb(gdm-password:auth): Authentication failed for mikala from (uid=0) ==> gdm/:0-slave.log <== gdm-simple-slave[9204]: WARNING: Could not run helper: L'exécution du processus fils « /usr/lib/ck-get-x11-display-device » a échoué (Aucun fichier ou dossier de ce type) ==> messages <== Jan 13 06:53:25 localhost gdm-simple-slave[9204]: WARNING: Could not run helper: L'exécution du processus fils « /usr/lib/ck-get-x11-display-device » a échoué (Aucun fichier ou dossier de ce type) ==> syslog <== Jan 13 06:53:25 localhost gdm-simple-slave[9204]: WARNING: Could not run helper: L'exécution du processus fils « /usr/lib/ck-get-x11-display-device » a échoué (Aucun fichier ou dossier de ce type) with kdm : ==> auth.log <== Jan 13 06:55:40 localhost kdm: :0[9359]: pam_succeed_if(kdm:auth): requirement "user ingroup nopasswdlogin" not met by user "mikala" Jan 13 06:55:40 localhost kdm: :0[9359]: pam_tcb(kdm:auth): Authentication failed for mikala from (uid=0) with xdm : i'm able to log in ==> auth.log <== Jan 13 06:56:22 localhost xdm[9440]: pam_tcb(xdm:auth): Authentication passed for mikala from (uid=0) ==> messages <== Jan 13 06:56:22 localhost systemd-logind[1061]: New session c7 of user mikala. Jan 13 06:56:22 localhost systemd-logind[1061]: Linked /tmp/.X11-unix/X0 to /run/user/mikala/X11/display. ==> syslog <== Jan 13 06:56:22 localhost systemd-logind[1061]: New session c7 of user mikala. Jan 13 06:56:22 localhost systemd-logind[1061]: Linked /tmp/.X11-unix/X0 to /run/user/mikala/X11/display. ==> auth.log <== Jan 13 06:56:22 localhost xdm[9440]: pam_tcb(xdm:session): Session opened for mikala by (uid=0) Any idea thierry ? could it be related to some missing pieces with consolekit or systemd ?
CC: (none) => mageia
interesting, bug 3936 can also be related (about lxdm) (and bug 3714)
well in all case it does not explain why it's working with a « default » install :/
when you log in with xdm, what does ck-list-sessions and loginctl output? The authentication error you get all seem to be related to tcb stuff. I wonder if the latest pam package which intended to fix systemd related login migration on upgrades somehow messed up some tcb related stuff (tho' as you can login with xdm, I can't see how that would be a problem - I presume console logins are also fine?) Are there any rpmnew files in /etc/pam.d/ ? (there shouldn't be on a fresh install of course, but worth checking all the same). Other than that I'm a bit stumped... maybe check all the things listed in the system-auth and gdm files and make sure all the .so files mentioned in there are actually installed?
This is in no way related to the installer but to some package
CC: (none) => thierry.vignaudComponent: Installer => RPM PackagesAssignee: thierry.vignaud => bugsquadSource RPM: drakx-installer => (none)
(In reply to comment #19) > when you log in with xdm, what does ck-list-sessions and loginctl output? > > The authentication error you get all seem to be related to tcb stuff. I wonder > if the latest pam package which intended to fix systemd related login migration > on upgrades somehow messed up some tcb related stuff (tho' as you can login > with xdm, I can't see how that would be a problem - I presume console logins > are also fine?) > > Are there any rpmnew files in /etc/pam.d/ ? (there shouldn't be on a fresh > install of course, but worth checking all the same). > > Other than that I'm a bit stumped... maybe check all the things listed in the > system-auth and gdm files and make sure all the .so files mentioned in there > are actually installed? @ Corneliu @ mikala can you please give your feedback / reply to Colin's comment?
Have you checked your ~/.xsession-errors ?
Oups sorry for the delay so here are the answers (In reply to comment #19) > when you log in with xdm, what does ck-list-sessions and loginctl output? ck-list-sessions Session3: unix-user = '500' realname = 'Balcaen John' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2012-01-28T12:23:02.296035Z' login-session-id = '4294967295' You mean probably systemd-loginctl ? SESSION UID USER SEAT 1 500 mikala seat0 c2 500 mikala seat0 2 sessions listed. > The authentication error you get all seem to be related to tcb stuff. I wonder > if the latest pam package which intended to fix systemd related login migration > on upgrades somehow messed up some tcb related stuff (tho' as you can login > with xdm, I can't see how that would be a problem - I presume console logins > are also fine?) They are. > Are there any rpmnew files in /etc/pam.d/ ? (there shouldn't be on a fresh > install of course, but worth checking all the same). no there's no .rpmnew files. There's also no /etc/sysconfig/desktop file but i doubt it's useful here. > > Other than that I'm a bit stumped... maybe check all the things listed in the > system-auth and gdm files and make sure all the .so files mentioned in there > are actually installed? They are. (In reply to comment #22) > Have you checked your ~/.xsession-errors ? There's no .xsession-errors since gdm/kdm does not permit login. You want the ~/.xsession-errors with xdm ?
@ Colin @ Thierry Can you look at John's replies to your questions, please (comment 23) Removing the NEEDINFO keyword, please put it back when asking for information again
Keywords: NEEDINFO => (none)
That's a kdm issue, I really can't do much... It really is for Colin or Mikala (John) now
(In reply to comment #25) > That's a kdm issue, I really can't do much... > It really is for Colin or Mikala (John) now It's not a kdm issue alone here since i'm able to reproduce with gdm too.
Yes but what's important to me is that this is not an installer bug :-)
Can you post the contents of /etc/pam.d/gdm*? Also can you maybe attach the logs from /var/log/gdm/ Namely the -greeter, -slave and the plain log files? As the files there tend to build up, I'd just nuke them all, do a reboot and then try and login with gdm, then grab the files. Hopefully this will give some clues as to why the login failed.
(In reply to comment #27) > Yes but what's important to me is that this is not an installer bug :-) ;o) (In reply to comment #28) > Can you post the contents of /etc/pam.d/gdm*? > > Also can you maybe attach the logs from /var/log/gdm/ Namely the -greeter, > -slave and the plain log files? As the files there tend to build up, I'd just > nuke them all, do a reboot and then try and login with gdm, then grab the > files. > > Hopefully this will give some clues as to why the login failed. I won't be able to post that until probably one week (workstation is currently broken :/ )
Since John is unavailable for a while, cc'ing some minimal install lovers, in the hope one of them can reproduce the issue (see comment 15) and supply the information Colin asked for in comment 28
CC: (none) => alien, n54, paiiou
Keywords: (none) => NEEDINFO
It was a while since I noticed that to install Xfce, the optimal solution is to choose a personalized desk, to delete all the groups of packages, then to choose "With X server". To contribute to the resolution of bug 395, I tried a minimal installation, without X server. During the installation, I configured the network, but not the X server. In the restart, I observed the bootsplash, then return in console. The restart remains blocked on the line: "Restoring numlock (via systemctl). I restarted with "Ctrl + Alt + Del". This time, bloquage in the line "Started Display Manager". I stop the tests.
@ Georges Thanks for the feedback :) @ Corneliu or John (if you have cauldron again) or whoever: Is there anybody who can provide the information Colin asked for in comment #28 ? > Can you post the contents of /etc/pam.d/gdm*? > > Also can you maybe attach the logs from /var/log/gdm/ Namely the -greeter, > -slave and the plain log files? As the files there tend to build up, I'd just > nuke them all, do a reboot and then try and login with gdm, then grab the > files. > > Hopefully this will give some clues as to why the login failed.
Ping! Any updates here?
Ping again? I did about 20 network installs over the last few days. Logins always worked. Depending on whether you have elected to install some old sysvinit scripts without LSB headers, there could be some kind of deadlock that stopped prefdm from starting but it should still let you log in on tty2 etc. That bug is being dealt with, so if there are no other specifical problems here, can we close this bug please?
OK resolving as OLD due to lack of response. Feel free to reopen with more info.
Status: NEW => RESOLVEDResolution: (none) => OLD