Description of problem: The following issue appeared when I upgraded from Mandriva 2010.2 to Mageia 1. The mgaapplet periodically shows the 'invalid password / try it again" dialog even when I haven't entered any. When I click on the 'Close' button, the dialog is displayed again (4 or 5 times) and then it stops bothering me for some time period (probably till the next software check ???). I see no mgaapplet icon in the notification area and the mgaapplet simply doesn't work. I remember I experienced the same issue with Mandriva 2010.x (don't remember the version exactly), but the system has been reinstalled and the issue disappeared. Version-Release number of selected component (if applicable): 2.77.29-1.mga1 How reproducible: always in my case Steps to Reproduce: I don't have a reproduction scenario
Hi, thanks for reporting this bug. Thierry, do you know how to debug that ?
CC: (none) => thierry.vignaudBlocks: (none) => 3342
Is it still available ? mga1 => mga2 ?
CC: (none) => ennael1
Anyway it's usermode which is showing this. Didn't someone fixed some post script recently?
Source RPM: mgaonline-2.77.29-1.mga1.src.rpm => usermode
Hi Anne & Thierry. I'm not sure if I can upgrade the system to mga2. It's a production system and we haven't tested mga2 enough to consider it stable. But I could install the latest mga1 updates this week. Please, let me know if this is sufficient. Thanks, Jaromir.
(In reply to comment #3) > Anyway it's usermode which is showing this. > Didn't someone fixed some post script recently? It was about pam configuration and xguest that just overwrote existing file
*** Bug 5307 has been marked as a duplicate of this bug. ***
CC: (none) => am2605
Version: 1 => Cauldron
Version: Cauldron => 1
Blocks: 3342 => (none)Summary: mgaapplet still displays 'invalid password' dialog even when I haven't entered any password => mgaapplet still displays 'invalid password' dialog even when I haven't entered any password (upgrade)
I'm using Mageia 2 installed from the Gnome Live CD and I still experience this issue.
CC: (none) => philippe.l
*** Bug 5831 has been marked as a duplicate of this bug. ***
CC: (none) => inster.css
and it is in Cauldron, too
CC: (none) => marja11Version: 1 => CauldronSummary: mgaapplet still displays 'invalid password' dialog even when I haven't entered any password (upgrade) => mgaapplet still displays 'invalid password' dialog even when I haven't entered any passwordWhiteboard: (none) => MGA1TOO MGA2TOO
I install a new comuputer with DVD Mageia2 32b. I confirm that. computer : amd Athon with graphic Nvidia GEFORCE7025 into CM ASROCK N68-VS3FX .
CC: (none) => christian-maryse.fischer
Hardware: x86_64 => All
*** Bug 7789 has been marked as a duplicate of this bug. ***
CC: (none) => yves.brungard_mageia
Priority: Normal => release_blocker
I have MGA 2 uptodate. I experience this problem on session deported with XDMCP. The problem does not occur on a session on the main system. Can this help to understand where the problem is? The message pop-up 7 times exactly.
Is it still valid in cauldron ?
I do not have this bug in mageia3 Cauldron
Priority: release_blocker => HighVersion: Cauldron => 2
CC: (none) => bruno
Hi Anne. I'm not going to update production systems to cauldron just because of this test, but I guess the problem is still present, because nobody tried to fix that yet, right? papoteur mentioned probably a very important thing ... and that's the XDMCP access. I do experience this issue ONLY when connected via VNC. So, I guess it has something to do with remote desktop sessions ... Regards, Jaromir.
(In reply to JaromÃr CápÃk from comment #16) > Hi Anne. > > I'm not going to update production systems to cauldron just because of this > test, but I guess the problem is still present, because nobody tried to fix > that yet, right? Did I ask such thing ? :) > papoteur mentioned probably a very important thing ... and that's the XDMCP > access. I do experience this issue ONLY when connected via VNC. So, I guess > it has something to do with remote desktop sessions ... Well it's nice to have this information now as it may help debug
(In reply to Anne Nicolas from comment #17) > (In reply to JaromÃr CápÃk from comment #16) > > Hi Anne. > > > > I'm not going to update production systems to cauldron just because of this > > test, but I guess the problem is still present, because nobody tried to fix > > that yet, right? > > Did I ask such thing ? :) Yes, you did :] ... Your question was : "Is it still valid in cauldron ?" I experience these problems on my production systems only ... that means I would have to update them in order to test that ;] But that was just an explanation why I can't do that right now. I want to prevent anyone from closing this bug, since Christian confirmed he can't reproduce it in Cauldron. That could be understood by someone like a reason for closing the bug. I still believe the problem is present in all available Mageia versions, but can't confirm that. > > papoteur mentioned probably a very important thing ... and that's the XDMCP > > access. I do experience this issue ONLY when connected via VNC. So, I guess > > it has something to do with remote desktop sessions ... > > Well it's nice to have this information now as it may help debug Hopefully ...
Hello, I did the test by a new installation of Mageia 3 beta 3. I configured kdm to enable XDMCP connections. I created another user to have simulaneous sessions. I started a remote session with the new account. I got also the pop-up windows telling that the password is missing. Thus, the bug is still valid. It's only test configuration, thus I can do other tests if needed. Papoteur
The bug is still current in Mageia3. I've a x86_64 installation (done with dual arch cd) and on lxde there's this message, appearing randomly when I log in. It happens more often when working remotely (e.g. I use nomachine NX because there's no freenx package in 3), but it happens locally too. I feel like it has something to do with console permissions... but I cannot pinpoint it.
CC: (none) => g.merigo
Driving me crazy upgraded from Mageia 2 to Mageia 3 online. I get multiple notifications on the desktop. I have no idea what is causing this. I am considering downloading a new dvd and formatting the existing. Everything else works fine and it's a nice distribution. Anyone have any ideas before doing the drastic?
CC: (none) => mbrace700
@moshe brace Don't do it. I have the same problem on a new install.
Version: 2 => 3
*** Bug 10284 has been marked as a duplicate of this bug. ***
I pinpointed and it comes from mgaapplet. These are the processes when the dialog box appears (pstree -p): mgaapplet(21352)âââmgaapplet(21666)âââconsolehelper-g(21667)ââ¬â{consolehelper-g}(21669) â ââ{consolehelper-g}(21670) The process which runs is: gmerigo 21667 21666 0 13:56 ? 00:00:00 urpmi.update --update When I click on the dialog boxes (more than one appear), only mgaapplet is running: gmerigo 21352 1 0 13:51 ? 00:00:01 /usr/bin/perl /usr/bin/mgaapplet I think here the culprit is some sort of authorization missing because the desktop is not running locally (I use nomachine's NX server), and mgaapplet cannot send the right permissions to urpmi.
I started having this problem a few weeks ago, and finally tracked it down to mgaapplet too, and ended up here... However, based on other things going on at the time, I'm suspecting this has something to do with the user's root password containing certain characters which may not be escaped and are being misinterpreted or mangled... such as one of !@#$%^&* etc... HTH
CC: (none) => pf
@Pierre I definitely do not have any non alphanumerical characters in my root password; I have them in my user's one. I can try to change that tomorrow and see what happens.
Created attachment 4131 [details] dialog This is the dialog that appears once for each entry in /var/log/messages: Jun 11 16:27:10 hg mgaapplet[7240]: running: urpmi.update Core Backports Jun 11 16:27:25 hg mgaapplet[7240]: running: urpmi.update Core Backports Testing Jun 11 16:27:25 hg mgaapplet[7240]: running: urpmi.update Nonfree Backports Jun 11 16:27:26 hg mgaapplet[7240]: running: urpmi.update Nonfree Backports Testing Jun 11 16:27:27 hg mgaapplet[7240]: running: urpmi.update Tainted Backports Jun 11 16:27:28 hg mgaapplet[7240]: running: urpmi.update Tainted Backports Testing Jun 11 16:27:29 hg mgaapplet[7240]: running: urpmi.update Core 32bit Backports Jun 11 16:27:30 hg mgaapplet[7240]: running: urpmi.update Core 32bit Backports Testing Jun 11 16:27:30 hg mgaapplet[7240]: running: urpmi.update Nonfree 32bit Backports Jun 11 16:27:31 hg mgaapplet[7240]: running: urpmi.update Nonfree 32bit Backports Testing Jun 11 16:27:32 hg mgaapplet[7240]: running: urpmi.update Tainted 32bit Backports Jun 11 16:27:33 hg mgaapplet[7240]: running: urpmi.update Tainted 32bit Backports Testing tail -f /var/log/messages confirms it when you click Close on each dialog...
@Giuseppe I have them in my root passwd; but not in my user... :)
Any chance this is affecting other stuff? Just tried to start drakroam from user account; it asks for my root password several times, then gives the same dialog I posted in comment 27...
@Pierre I change my user password to a simpler one without any kind of special characters, only plain alphanumeric and problem is still there. So I went back to my old password.
@Giuseppe ...but... did you re-enter your password into mgaapplet? If you just changed it via Linux passwd command, the wrong one may still in mgaapplet -- guessing... OK... tested this by changing my root passwd... when I try to start drakroam from my regular userid, it asks for the root passwd 3 times, then gives the dialog in comment 27; and all the subsequent urpmi requests fail. Looks like the code that asks for the root passwd is failing to authenticate properly, then all future mgaapplet events can't authenticate and give that dialog for every event... :P
@Pierre I never entered any password (see bug title and description). I changed the password from terminal as usual with passwd _and logged out completely from the remote session (lxde in my case)_ I think your issue is different from what is described in this bug report.
@Giuseppe Thanks for reminding me... actually, it likely is the same bug... it started happening on it's own from a restart after some updates. Almost forgot that because of the debugging I was doing since. The only difference is the "when"; mine started a few weeks ago -- didn't start looking into it until it got really aggravating. Also just noticed you reported this on mga3. Mine is on mga2 -- did some mgaapplet related packages/fixes get backported to mga2 recently? Checked my log files for updated packages; but the ones I need were rotated out... :( Sorry for any noise; but HTH somehow... Ciao!
As a workaround, I removed mgaapplet from the session startup. I think some control code should be added to ensure that the applet runs only if the session owns the console.
For the record, we've switched from usermode to polkit in incoming Mageia 4 and this bug should not happen there.
Can someone confirm that this bug is fixed in Mageia 4?
CC: (none) => remiWhiteboard: MGA1TOO MGA2TOO => (none)
For me ( 2 computers Mageia3 and 3 Mageia4 ) no problem .
This same problem started here (mageia 3) today after a (spontaneous) reboot. Local kde session started from kdm.
CC: (none) => luca
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD