1] This happens with Gnome Classic desktop also.

2] From a terminal *if already root* graphical MCC *does* start and run OK (with a fistful of habitual error msgs on the console). So the problem really is down to the authentification dialogue.

Sounds like another polkit issue or polkit agent not started.
Adding some people in CC.

CC: (none) => ennael1, mageia
Whiteboard: Mag 4 Beta => 4beta2

So Gnome is my main test platform and it has always worked for me there. I guess I'll have to do a test install to double check seeing as I cannot replicate :s

Can anyone else confirm this problem firth tho' - this is quite a common setup for a lot of devs so kinda strange that it's only showing up as a problem now...

I'm doing a vbox install now from classic dvd to give it a go. I think devs tend to use cauldron rather than install the betas though colin which may hide bugs with initialising the system.

It's ok here in gnome shell.

Dec 19 11:50:48 localhost polkit-agent-helper-1[2700]: pam_tcb(polkit-1:auth): Authentication passed for root from user(uid=500)
Dec 19 11:50:48 localhost polkitd[802]: Operator of unix-session:1 successfully authenticated as unix-user:root to gain TEMPORARY authorization for action org.mageia.drakconf.pkexec.run for unix-process:2161:13692 [/usr/bin/gnome-shell] (owned by unix-user:user)
Dec 19 11:50:48 localhost pkexec[2693]: pam_systemd(polkit-1:session): pam_putenv: delete non-existent entry; XDG_RUNTIME_DIR
Dec 19 11:50:48 localhost pkexec[2693]: pam_tcb(polkit-1:session): Session opened for root by user(uid=500)
Dec 19 11:50:48 localhost pkexec[2693]: user: Executing command [USER=root] [TTY=unknown] [CWD=/home/user] [COMMAND=/usr/libexec/drakconf]
Dec 19 11:50:49 localhost drakconf[2693]: ### Program is starting ###


MCC does seem to randomly but quite frequently crash when starting though. No errors are reported in the journal when it does.

Starting from a terminal though it's a segfault..
# mcc
LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
"/usr/sbin/drakmenustyle" is not executable [Menus] at /usr/libexec/drakconf line 823.
"/usr/sbin/drakbackup" is not executable [Backups] at /usr/libexec/drakconf line 823.
"/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/libexec/drakconf line 823.
"/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/libexec/drakconf line 823.
java version "1.7.0_45"
OpenJDK Runtime Environment (mageia-2.4.3.2.mga4-i386 u45-b15)
OpenJDK Client VM (build 24.45-b08, mixed mode, sharing)
Segmentation fault


There are what looks to be some gtk errors in the journal and a huge number of repeating errors when adding medias in drakrpm-edit-media..

Dec 19 12:02:50 localhost drakconf[3802]: ### Program is starting ###
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:51 localhost gnome-session[2074]: LOG **: NP_Initialize succeeded at /usr/lib/libDrakX/mygtk2.pm line 589.
Dec 19 12:02:52 localhost gnome-session[2074]: "/usr/sbin/drakmenustyle" is not executable [Menus] at /usr/libexec/drakconf line 823.
Dec 19 12:02:52 localhost gnome-session[2074]: "/usr/sbin/drakbackup" is not executable [Backups] at /usr/libexec/drakconf line 823.
Dec 19 12:02:52 localhost gnome-session[2074]: "/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/libexec/drakconf line 823.
Dec 19 12:02:52 localhost gnome-session[2074]: "/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/libexec/drakconf line 823.
Dec 19 12:02:52 localhost gnome-session[2074]: java version "1.7.0_45"
Dec 19 12:02:52 localhost gnome-session[2074]: OpenJDK Runtime Environment (mageia-2.4.3.2.mga4-i386 u45-b15)
Dec 19 12:02:52 localhost gnome-session[2074]: OpenJDK Client VM (build 24.45-b08, mixed mode, sharing)
Dec 19 12:02:53 localhost gnome-session[2074]: GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_spawn_sync either directly or indirectly. at /usr/lib/perl5/vendor_perl/5.18.1/MDK/Common/Func.pm line 222.
Dec 19 12:03:11 localhost gnome-session[2074]: Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 304.
Dec 19 12:03:11 localhost drakrpm-editmedia[3844]: ### Program is starting ###
Dec 19 12:03:19 localhost gnome-session[2074]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x200004b specified for 0x200058e (Mirror cho).
Dec 19 12:03:21 localhost gnome-session[2074]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x200004b specified for 0x2000800 (Please wai).
Dec 19 12:03:21 localhost gnome-session[2074]: getting exclusive lock on urpmi

...


Dec 19 12:04:47 localhost gnome-session[2074]: retrieved $MIRRORLIST media/debug/tainted/backports_testing media_info/MD5SUM
Dec 19 12:04:47 localhost gnome-session[2074]: comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Backports Testing D
ebug (distrib30)/MD5SUM
Dec 19 12:04:47 localhost gnome-session[2074]: retrieving source synthesis of "Tainted Backports Testing Debug (distrib30)"...
Dec 19 12:04:48 localhost gnome-session[2074]: retrieved $MIRRORLIST media/debug/tainted/backports_testing media_info/20130518-182137-s
ynthesis.hdlist.cz
Dec 19 12:04:48 localhost gnome-session[2074]: computing md5sum of retrieved source synthesis
Dec 19 12:04:57 localhost gnome-session[2074]: (drakrpm-editmedia:3844): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos: assertion 'tre
e_view != NULL' failed
Dec 19 12:04:57 localhost gnome-session[2074]: (drakrpm-editmedia:3844): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos: assertion 'tre
e_view != NULL' failed
Dec 19 12:04:57 localhost gnome-session[2074]: (drakrpm-editmedia:3844): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos: assertion 'tree_view != NULL' failed
Dec 19 12:04:57 localhost gnome-session[2074]: (drakrpm-editmedia:3844): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos: assertion 'tree_view != NULL' failed
Dec 19 12:04:57 localhost gnome-session[2074]: (drakrpm-editmedia:3844): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos: assertion 'tree_view != NULL' failed
Dec 19 12:04:57 localhost gnome-session[2074]: (drakrpm-editmedia:3844): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos: assertion 'tree_view != NULL' failed

Pages and pages of these errors. Seems quite buggy at the moment.

After installing gnome-classic-session and logging into GNOMEClassic MCC seems to segfault every time. Displays the loading screen and then dies.

Confirmed in a terminal. It did ask for and seem o accept the password though. I'll attach the journal.

Created attachment 4642 [details]
journal.txt

Yeah the crashes are a known issue just now related to background threads/races in gtk3.

This does seem to be in contradiction to Lewis' finds tho' (although more along the lines of what I would expect) which is both good (no bug) and bad (where did Lewis' bug go?).

Lewis could you attach your journal please which will show the steps it takes during the authentication and any failure there.

# journalctl -a --no-pager > /home/lewis/journal.txt
# chown lewis /home/lewis/journal.txt

You should then be able to view it and attach it to the bug report.

(thos(In reply to claire robinson from comment #9)
> Lewis could you attach your journal please which will show the steps it
> takes during the authentication and any failure there.
> 
> # journalctl -a --no-pager > /home/lewis/journal.txt
> # chown lewis /home/lewis/journal.txt

For the avoidance of doubt, this should be done as root.

You probably also want the -b flag in there too in order to limit the output to the current boot only.

What a flurry! I am aware that it is just me that suffers this, and am always reluctant to raise a Bug in such circumstances. I may be doing/have done something silly. But this is an ongoing thing for me.

Claire: the problem of MCC crashing is known, another thing already Bugged.

Re my 'athentification' probelm, re comments 9 & 10, I shall attach the output requested. For its understanding, I did:
- One attempt to access MCC as root, bounced. The important one.
- One failed password for root on su-ing in a terminal (aperitif!).
- Successful su.
Then:-
# journalctl -ab --no-pager > journal.txt

Created attachment 4644 [details]
Output of journalctl after a Gnome authentification failure

As requested in comments 9-10

Looks good generally, but ultimately I'm afraid to say it just points to typing in the wrong password ;) (tho' to be fair the difference between this and a real bug is likely not much different)

As this is a test install, how complicated is your root password? Normally on my tests I just use two consecutive letters for simplicity and although I tried to confirm in a test VM here, I could not replicate :(

I'll keep on poking at it, but in the mean time can you try changing the root password to something really simple that couldn't be accidentally input incorrectly?

Colin...

Of course this is the first thing that springs to mind for the user, so he re-types whatever. I have typed my root password thousands of times, and for this problem have done so very carefully, and repeatedly. I have also checked it by su'ing in a console to check that the root password I type *is* accepted there - it always is. It is not too complicated. No problem with non-Gnome desktops. Why should I always get it wrong just under Gnome? And for all the weeks of trying Mageia 4 pre-release? Don't think I am complaining about an isolated incident.

Don't forget that the same problem arises when Gnome wants the *user* password, which is different, but also consistent over time so input thousands of times.

- It only happens with the Gnome graphical authentification dialogue.
- It applies equally to 'root'and 'user' passwords.
- It does not happen in any other circumstance or desktop.
- It has been a hard problem for weeks.

However, I *will* try your suggestion of changing the root p/w to something banal. Would it help if I sent you the offending passwords by private e-mail? Here is a bit too public.

I repeat that if no-one else has this problem, and we cannot pin it down, we can push it under the carpet.

POSSIBILITY? My *video* hardware (SiS) is not correctly handled by Xorg. I have a seperate bug about this, which normally corrupts specific display situations. But could it mess up typed *input*? This is the main factor which separates me from the rest. Another is that my processor does not have SSE2 instructions, but that normally crashes programs which use them.

Just throwing ideas in the hat, could this be caused by keyboard/locale disagreement with gnome-polkit?

Lewis I know you frequently use Welsh, English and French, which combination do you use in Gnome?

Re comment 15
Claire: your idea is quite reasonable. It is true that the language is Cymraeg (Welsh), but this has the standard UK keyboard that I use. As for timezone, that *is* for France (Paris). UK QWERTY and French AZERTY keybords are largely similar for most of the alphabet (only), with just a few differences. My original root and user passwords both included letters which differed between the 2 layouts. However, without trying to change 'locale', the following experiments should eliminate the need. 

Re comment 13
I changed the root password to 'root' (it complained), which does *not* differ between UK & French k/b's. Confirmed OK in terminal su. Refused on trying Mageia Control Centre from desktop.

I changed it, and confirmed it, to just 'x' again identical for the 2 k/b's (it complained bitterly). Still no joy with the Authentification dialogue.

Colin: is there any way of seeing the raw password seen by that process?

With Xfce, I need to use the user password for everything, even MCC.

CC: (none) => laidlaws

(In reply to Doug Laidlaw from comment #17)
> With Xfce, I need to use the user password for everything, even MCC.

That's likely unrelated to Xfce. Is your user in the wheel group? If so then it's due to /etc/polkit-1/rules.d/50-default.rules and thus expected. This file should perhaps be in polkit-desktop-policy (although fedora do not split this out so I'm tempted to just kill off the polkit-desktop-policy package (which is currently empty)

(In reply to Lewis Smith from comment #16)
> Colin: is there any way of seeing the raw password seen by that process?

I'm not too sure, but as you are able to reproduce this problem easily, I'll find a way to debug this better so we can get to the bottom of it!

(In reply to Colin Guthrie from comment #18)
> (In reply to Doug Laidlaw from comment #17)
> > With Xfce, I need to use the user password for everything, even MCC.
> 
> That's likely unrelated to Xfce. Is your user in the wheel group? If so then
> it's due to /etc/polkit-1/rules.d/50-default.rules and thus expected. This
> file should perhaps be in polkit-desktop-policy (although fedora do not
> split this out so I'm tempted to just kill off the polkit-desktop-policy
> package (which is currently empty)
> 

Thanks Colin.  Yes I was in the wheel group.  Took myself out of it and things are back to normal.  I was thinking that it must be a bug, and this one seemed a likely candidate.  I will remove myself from the cc list.

My install/upgrades of mga4 was from cauldron repository. Thierry has been working on bug 10289.  Until the latest update yesterday, mcc was starting; but after the latest update which included:

Dec 28 10:43 media/core/release/gksu-polkit-0.0.3-0.git20131130.9.mga4.x86_64.rpm
Dec 28 10:43 media/core/release/lib64gksu-polkit0-0.0.3-0.git20131130.9.mga4.x86_64.rpm
Dec 28 10:43 media/core/release/lib64gksu-polkit-devel-0.0.3-0.git20131130.9.mga4.x86_64.rpm
Dec 28 10:43 media/core/release/drakconf-12.47-1.mga4.noarch.rpm
Dec 28 10:43 media/core/release/drakconf-icons-12.47-1.mga4.noarch.rpm

mcc will no longer start and I now get:
# mcc
Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PolicyKit1 timed out

To be fair, the other day, I tried to install vbox extensions and got:
The installer failed with exit code 127: Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PolicyKit1 timed out.

Details:

Result Code: 
NS_ERROR_FAILURE (0x80004005)
Component: 
ExtPackManager
Interface: 
IExtPackManager {3295e6ce-b051-47b2-9514-2c588bfe7554}

However, mcc was starting just fine until these packages were updated.

polkit(folder limit) specifically asks for *root* password which it doesn't accept. Entered my user password and it seems to have accepted that.  Now, when I try to start mcc, I get:
# mcc
Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached

See also bug 10289

CC: (none) => pf

In case it matters, my userid is in /etc/sudoers; but not part of group wheel.

This doesn't appear to be the same problem Pierre. Your problem is that the polkit daemon itself is not running. As per my comment on #10289, please either ask via Cauldron ML or open a new bug and provide output of "systemctl status polkit" and "systemd-delta". Thanks.

(In reply to Colin Guthrie from comment #22)
> This doesn't appear to be the same problem Pierre. Your problem is that the
> polkit daemon itself is not running. As per my comment on #10289, please
> either ask via Cauldron ML or open a new bug and provide output of
> "systemctl status polkit" and "systemd-delta". Thanks.

Ooops, I'd written the comment, but never submitted it so my "as per my comment on" statement is bogus! But the principle is the same, please open a new bug (and add me to CC) or ask via Cauldron ML. The problem is that polkitd is not running on your system.

So I tried to reproduce this a few times and still fail :( I'll try with your locale settings shortly (welsh language, french timezone, UK keyboard if I've read properly!)

Writing from a MGA4 Final Live Gnome 64-bit installation...
The root password requested by the Gnome authentification dialogue for Mageia Control Centre is *accepted* on this installation. This makes me wonder:
- Was it always thus, OK on 64-bit? Sorry, cannot remember.
- Was it OK on even 32-bit Live Gnome installs? I cannot say, I gave them up as useless. But I think not.

What *is* certain is that the problem persists on the latest 32-bit MGA4 Classic Final installation, where of 6 desktops installed only Gnome shows the problem; the other desktops, Cinnamon included, use different dialogues which accept the root password OK.

So the problem manifests itself *just on *my* 32-bit box*. Could the fact that Gnome is so slow on it as to be unuseable have a bearing? i.e. Could it be speed related? (At 1.7GHz the box is not feeble). Can we intercept the string passed from the dialogue box?

Colin
The machine which consistently showed this problem is now out of use, so I cannot try it further. Can we close the bug? - as you see fit.

As nobody else had the same issue or confirmed it during the last ~12 months I'm closing this as COULDNOTREPRODUCE :)

Status: NEW => RESOLVED
CC: (none) => doktor5000
Resolution: (none) => WORKSFORME