Description of problem: Mageia Cauldron GDM won't start, a sad face will appears & sometime not even the sad face will start. Sometimes mageia does log in if autologin is enabled, but it won't work if autologin is disabled. If KDM is istalled, Mageia works just fine., Version-Release number of selected component (if applicable): gdm-3.2.1.1-1.mga2.i586 How reproducible: Steps to Reproduce: 1. Proceed with normal installation using Mageia 1 final CD with 32bit Mageia with GNOME 2. 2. Updated Mageia 1 with Gnome2 to the latest updates using " urpmi --auto-update -v " 3. Changed the repository to http://mageia.webconquest.com/distrib/cauldron/i586 updated to the lates cauldron using " urpmi --auto-update -v " Once everything is updated restart. Sometimes mageia does log in if autologin is enabled, but it won't work if autologin is disabled.
CC: (none) => boklmComponent: Bugzilla => RPM PackagesVersion: unspecified => CauldronAssignee: sysadmin-bugs => bugsquadProduct: Infrastructure => Mageia
CC: mageia-webteam, sysadmin-bugs => (none)
Are you using systemd ? there was some thread about gdm on the mageia-dev mailing list.
Hello Manuel, Yes, I am using systemd?.. Is there a way to remove it?.. I tried but I get a message that it will damage my system.. I also looked at mageia-dev mailing list and I did find some problems reported but no solution yet.. Does anyone have a solution?.. Yesterday it worked fine using gnome-classic since gnome-shell was damaged but once I reinstalled the packaged I got the error again, I just cannot login. Regards
Hi, I installed another computer using the network installation for cauldron. I installed KDE4 since the GNOME options seems not to be configured to download GNOME3 since it didn't install anything. Well, once I installed Cauldron KDE4 from network installation, I installed gnome3 and removed KDE4, GDM works great in gnome-classic mode, I never get any errors at all. It seems to me that the problem is when upgrading from GNOME2 to GNOME3 cauldron. IT would be a good idea to track this problem and avoid getting it in future updrades when Mageia 2 is released. Regards,
(In reply to comment #3) > errors at all. > > It seems to me that the problem is when upgrading from GNOME2 to GNOME3 > cauldron. > > IT would be a good idea to track this problem and avoid getting it in future > updrades when Mageia 2 is released. > @ Olav This happened over two months ago. If this can be an issue, I suppose this bug should be assigned to you. WDYT?
CC: (none) => marja11, olav
Is this bug still valid?
Keywords: (none) => NEEDINFO
Yeah, we need to check that upgrades work
Target Milestone: --- => Mageia 2
(In reply to comment #5) > Is this bug still valid? (In reply to comment #6) > Yeah, we need to check that upgrades work cc'ing more gdm committers Whoever wants to work on this: Please assign this bug to yourself and set status to ASSIGNED
CC: (none) => dmorganec, fundawang, jani.valimaa, mageia, mageia, mageia, tmbSummary: gdm fails to start in 32 bit Mageia on old Pentium 4 PCs (Cauldron Mageia 2) => After updating from 1 to cauldron: gdm fails to start in 32 bit Mageia on old Pentium 4 PCs (Cauldron Mageia 2)
OK, so my first guess would be related to the pam files for gdm in /etc/pam.d/ folder. Make sure there are no .rpmnew files in there.
CC: (none) => djmarian4uSummary: After updating from 1 to cauldron: gdm fails to start in 32 bit Mageia on old Pentium 4 PCs (Cauldron Mageia 2) => after updating from 1 to cauldron: gdm fails to start in 32 bit Mageia on old Pentium 4 PCs (Cauldron Mageia 2)
Keywords: NEEDINFO => (none)
Is this still problematic?
CC: jani.valimaa => (none)
In testing an upgrade using the pre-release rc dual cd, /etc/pam.d ends up with -rw-r--r-- 1 root shadow 730 Apr 27 13:53 system-auth -rw-r--r-- 1 root shadow 660 Feb 18 23:57 system-auth.rpmnew so I expect the problem is still there.
CC: (none) => davidwhodgins
(In reply to comment #10) > In testing an upgrade using the pre-release rc dual cd, /etc/pam.d ends up with > -rw-r--r-- 1 root shadow 730 Apr 27 13:53 system-auth > -rw-r--r-- 1 root shadow 660 Feb 18 23:57 system-auth.rpmnew > so I expect the problem is still there. But what does system-auth contain? I'm pretty sure that it should contain pam_systemd as I did ensure that %post scripts take care of adding it in. Just the fact that an .rpmnew file exists does not, in itself, mean there is a problem. Have you checked if it's actually problematic?
(In reply to comment #11) > (In reply to comment #10) > > In testing an upgrade using the pre-release rc dual cd, /etc/pam.d ends up with > > -rw-r--r-- 1 root shadow 730 Apr 27 13:53 system-auth > > -rw-r--r-- 1 root shadow 660 Feb 18 23:57 system-auth.rpmnew > > so I expect the problem is still there. > > But what does system-auth contain? I'm pretty sure that it should contain > pam_systemd as I did ensure that %post scripts take care of adding it in. Just > the fact that an .rpmnew file exists does not, in itself, mean there is a > problem. > > Have you checked if it's actually problematic? grep systemd system-auth -session optional pam_systemd.so No I haven't seen any problem due to this, so it looks like it is ok. Sorry for the false alarm.
(In reply to comment #12) > (In reply to comment #11) > > Have you checked if it's actually problematic? > > grep systemd system-auth > -session optional pam_systemd.so > > No I haven't seen any problem due to this, so it looks like it is ok. > Sorry for the false alarm. No need to apologise! False alarm is much nicer than a real alarm :D OK, I think we can close this one too then :)
Status: NEW => RESOLVEDResolution: (none) => FIXED
CC: boklm => (none)