Please try running yast2 from the console to see if you get any error messages, and try the various plugins:

su -
yast2
yast2 --qt
yast2 --ncurses

Finally, attach yast2 logs:

save_y2logs /tmp/y2logs.tgz

Part 1&2 (with clicking on the different modules and then ending the YaST2 Control Center graphically):




# yast2

** (y2controlcenter-gnome:30171): WARNING **: key not found [/apps/yast-control-center/cc_actions_list]

Invalid MIT-MAGIC-COOKIE-1 keyxprop:  unable to open display ':0.0'
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s
Invalid MIT-MAGIC-COOKIE-1 keyxprop:  unable to open display ':0.0'
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s
Invalid MIT-MAGIC-COOKIE-1 keyxprop:  unable to open display ':0.0'
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s
Invalid MIT-MAGIC-COOKIE-1 keyxprop:  unable to open display ':0.0'
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s
Invalid MIT-MAGIC-COOKIE-1 keyxprop:  unable to open display ':0.0'
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s
#

Seems to be not much different than on the 11-Mar-2011 23:37
(compare: http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/455279-after-zypper-dup-11-4-most-graphical-yast-modules-do-not-start-via-yast.html#post2302267)

Part 3 of 4:

# yast2 --qt
No index for key:  "Name"  value:  "" 
# 


The Qt based YaST Control Center is still working (seems to me flawlessly).

Part 4 of 5:

# yast2 --ncurses
# 

The YaST Control Center without Desktop Environment seems to work without problems.

Created attachment 420360 [details]
Hopefully a the YaST log files (compressed)

Part 5 of 5:
# save_y2logs /tmp/y2logs.tgz
Saving y2logs to /tmp/y2logs.tgz
tar: Removing leading `/' from member names
#

Thanks, Martin. Just wanted to be sure that wasn't an artefact from using gnomesu, or some such.

This is definitively some problem with yast2-control-center-gnome. Let's set the Component to Gnome, where the maintainers of that tool hang out...

Probably not related, but there are a few yast2 crashes reported in /YaST2/signal over the logs file. They seem to be related to the software manager. Martin, if you can (still) reproduce them, please let me know.

(In reply to comment #7)
> Probably not related, but there are a few yast2 crashes reported in
> /YaST2/signal over the logs file. They seem to be related to the software
> manager. Martin, if you can (still) reproduce them, please let me know.
Thanks Ricardo for your question(s).
I think the old YaST2 crashes were related to crash in the Milestone Phase in the middle of December 2010.
compare:
Bug 659089 - panel not shown for one user - no nm-applet in panel for the next user (after nm-a crash while update)
https://bugzilla.novell.com/show_bug.cgi?id=659089
https://bugzilla.gnome.org/show_bug.cgi?id=637126

Nowadays (if I get the software Manager to start) I have no more problems with it (only some reports on the SCIM program but this is so at least since openSUSE 11.2).

I would have made not bug report but just a clean install of openSUSE 11.4 final but as there are several users who had the same/a simular bug (probably all after *upgrading* to 11.4) I thought it would be in the interest of the project if I stay with this installation/configuration to explore the real cause of my that problem.

(In reply to comment #6)
> Thanks, Martin. Just wanted to be sure that wasn't an artefact from using
> gnomesu, or some such.
> 
> This is definitively some problem with yast2-control-center-gnome. Let's set
> the Component to Gnome, where the maintainers of that tool hang out...
Thanks for changing that.
And if would be (also) related to the gnomesu program (in contrast to e. g. kdesu or gksu/gksudo or a policykit solution) there may be people in the GNOME team or a Base system team that know how to deal best with the user rights/privileges management system in openSUSE's GNOME, too.

Should I try any newer version of yast2-control-center-gnome? If so which version from which repository?

Vincent: user cannot run the gnome yast2 control center after zypper dup 11.4 upgrade. Both gnomesu and "su -" error out with a display connection errors. (xauth issues)

Martin: this happens only for yast2 control center, right? I mean, do other gnome applications (say, gnome-calculator) work fine if you run them as root?

If it doesn't work under "su -", then gnomesu is not really relevant.

Can you try running other graphical apps under "su -"? Say gcalctool, xeyes, gedit, etc.?

Hi Ricado, hi Vincent,

I have no problems to start YaST modules directly after becoming root with "su -" (just like with gnomesu); other applications/graphical programs can also be started and I see not (real) problems only sometimes funny messages. And root's nautilus process was not automatically ended as I closed the nautilus window - I had to end it by the GNOME System Monitor (never did this before after "su -" only with gnomesu).



~> su -
Password: 
~ # /sbin/yast2 users
~ # /sbin/yast2 sw_single
~ # gnome-calculator

(process:10072): Gtk-CRITICAL **: set_table: assertion `buffer->tag_table == NULL' failed
~ # gcalctool

(process:10084): Gtk-CRITICAL **: set_table: assertion `buffer->tag_table == NULL' failed
~ # xeyes
~ # gedit
~ # nautilus
Initializing nautilus-gdu extension
Initializing nautilus-open-terminal extension

** (nautilus:10112): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.ConsoleKit.Manager.GeneralError: Unable to lookup session information for process '10112'
Terminated
~ #

The issue I can see is that desktop files for yast have "X-KDE-RootOnly=true" and also specify xdg-su in the Exec line. Which means we use both gnomesu and xdg-su (which will call gnomesu...).

Can you try editing /usr/share/applications/YaST2/firewall.desktop and remove the 
"X-KDE-RootOnly=true" line, and then see if you can start the firewall module correctly?

If that fixes the issue, we should fix yast desktop files, and we can also work around this in glib by changing our patch looking for this key (to avoid calling gnomesu if xdg-su is already used). Note: in the long term, this patch would get removed anyway, see bug 540627.

(In reply to comment #14)
> The issue I can see is that desktop files for yast have "X-KDE-RootOnly=true"
> and also specify xdg-su in the Exec line. Which means we use both gnomesu and
> xdg-su (which will call gnomesu...).
> 
> Can you try editing /usr/share/applications/YaST2/firewall.desktop and remove
> the 
> "X-KDE-RootOnly=true" line,
done, now /usr/share/applications/YaST2/firewall.desktop :

[Desktop Entry]
X-SuSE-translate=true
X-SuSE-DocTeamID=ycc_firewall
Type=Application
Categories=Settings;System;Qt;X-SuSE-YaST;X-SuSE-YaST-Security;

X-KDE-ModuleType=Library
X-KDE-HasReadOnlyMode=true
X-KDE-Library=yast2
X-SuSE-YaST-Call=firewall
X-SuSE-YaST-Group=Security
X-SuSE-YaST-Argument=
X-SuSE-YaST-RootOnly=true
X-SuSE-YaST-AutoInst=all
X-SuSE-YaST-Geometry=
X-SuSE-YaST-SortKey=
X-SuSE-YaST-AutoInstClonable=true
X-SuSE-YaST-AutoInstRequires=lan
X-SuSE-YaST-AutoInstSchema=firewall.rnc

Icon=yast-firewall
Exec=xdg-su -c "/sbin/yast2 firewall"

Name=Firewall
GenericName=Configure a firewall
StartupNotify=true


> and then see if you can start the firewall module
> correctly?

Not jet (if better after a restart of the desktop envioment/the system I will report again):

[Code]
~> su -
Password: 
[...]
~ # yast2

** (y2controlcenter-gnome:12473): WARNING **: key not found [/apps/yast-control-center/cc_actions_list]
[/Code]

Clicked on the firewall symbol -> an window (title: "xdg-su /sbin/yast2 firewall (as superuser") ) with a to me unknown terminal emulator opens and says (hopefully correct - I cannot copy it):

[CODE]
Invalid MIT-MAGIC-COOKIE-1 key
y2base:12628: Gtk-WARNING **: cannot open display: :0.0
[/CODE]

So no great improvement jet.

(In reply to comment #15)
> (In reply to comment #14)

> Not jet (if better after a restart of the desktop envioment/the system I will
> report again):

No change/improvement after restart. And the funny terminal like window appears not if I start graphically the yast control center and by this way the firewall yast module.

Ok, and can you now remove the xdg-su at the beginning of the Exec line too?

Alternatively, can you do this in a shell:

su -
xdg-su -c xeyes

Success!

1.
(In reply to comment #17)
> Ok, and can you now remove the xdg-su at the beginning of the Exec line too?
I hope it was meant in that way:
Exec=xdg-su -c "/sbin/yast2 firewall"
->
Exec=/sbin/yast2 firewall

2.
After that I started yast2 via GNOME terminal:
[CODE]
~ # yast2

** (y2controlcenter-gnome:28084): WARNING **: key not found [/apps/yast-control-center/cc_actions_list]
[/CODE]
[I started the firewall yast module via the Yast Control Center edited the logging level, accepted so closed the module's window. Started again and edited the logging level back to "Logg Only Critical".Then I closed the YaST Control Center] 
[CODE]
~ #
[/CODE]

3.
Accordingly to 2. when I stared the YaST Control Center via the GNOME Main Menu. .

(In reply to comment #18)
> Alternatively, can you do this in a shell:
> 
> su -
> xdg-su -c xeyes

Seems not to work (if I understood that the expected result should be the openning of the eyes - I saw only a flickering like as a window was opened and closed just after that):

~> su -
Password: 
linux-o7fu:~ # xdg-su -c xeyes
linux-o7fu:~ # xdg-su -c xeyes
linux-o7fu:~ # 


By the way: Is it normal/wished that there are now still not only the process gnomesu but also xdg-su waiting and sleeping (status in GNOME's System Monitor).

(In reply to comment #20)
> By the way: Is it normal/wished that there are now still not only the process
> gnomesu but also xdg-su waiting and sleeping (status in GNOME's System
> Monitor).

xdg-su calls gnomesu, so it's kind of expected (although unfortunate).

I'm really confused now. Does this work fine?

su -
xterm

FWIW, I can't reproduce the issue locally, so I wonder if you have changed your security settings, your pam settings, or if you have any specific xauth configuration.

(In reply to comment #22)
> I'm really confused now. Does this work fine?
> 
> su -
> xterm
Besides that I do not know how to copy out of a xterm window it looks fine:

linux-abcd:~ # xterm
gives a window with
linux-abcd:~ # xterm

[abcd is a substitute]



> 
> FWIW, I can't reproduce the issue locally, so I wonder if you have changed
> your
> security settings, your pam settings, or if you have any specific xauth
> configuration.

I do not recall to have done anything like that. I even to not know where alter my Pluggable Authentication Modules (PAM) or something with X Window authorization nor do I recall to have ever used xauth. The nearest to that would be that I have activated all the magic keys and notification for my default user.

But as there are several users with the same problem in the forums it seemed to me not to be caused by an unusual/singular stupidity.

(In reply to comment #18)
> Alternatively, can you do this in a shell:
> 
> su -
> xdg-su -c xeyes

By the way:
As an normal user with xdg-su it does work:

# exit
logout
user@linux-abcd:~> xdg-su -c xeyes
[a window appears, I enter my root password, small brother is watching, I closed the xeyes window]
user@linux-abcd:~>

Why should root become root/get root privileges (again)?

(In reply to comment #23)
> (In reply to comment #22)
> > I'm really confused now. Does this work fine?
> > 
> > su -
> > xterm
> Besides that I do not know how to copy out of a xterm window it looks fine:

Okay, I just don't understand now. xdg-su is simply calling xterm and there it seems it doesn't work. But if you do it manually, it does work. I think I'd really need to be able to reproduce to better debug that.

Or someone can play with xdg-su (it's a shell script) to see what's the difference between what I asked here and xdg-su. If someone knows how to reproduce this issue from a fresh install, I'd welcome instructions...

> But as there are several users with the same problem in the forums it seemed to
> me not to be caused by an unusual/singular stupidity.

Heh, it's not stupidity. But there's a difference somewhere between our systems, and I have no idea what this is...

(In reply to comment #24)
> Why should root become root/get root privileges (again)?

This is simply what yast does: you run the shell as root, and it executes the modules with xdg-su. So I was simply trying to reproduce the issue outside of yast.

In reply to comment #25

but citing comment #22 :
[...]
> FWIW, I can't reproduce the issue locally, so I wonder if you have changed your
> security settings, your pam settings, or if you have any specific xauth
> configuration.

Maybe you could make a guess / give me a hint where the usual and unusual suspects should be fould and I could add them as attachment or post them. If there might be any passwords or things like that in that data I would be happy to get a warning so I might be able to delete them before that.

I in my amateurish view would presume that there is the possibility that I have some settings (made by default or maybe not intently by me) that has been working well with the pre-release versions (and for other users with the 11.3 versions) and are (because of a change before the Goldmaster release?) not working with the current programs.

2)
Should I also/after that/alternativly try to update or downgrade any (xdg-related?) programs/packages to play a bit try and error (think I have already done so a bit by reinstalling or de-installing or installing some of them but seems to me without success -> compare above, keyword: stup* )? ;-)

If so - to what versions in what repository?

compare:
~ # zypper search -s xdg
[...]

S | Name                          | Type       | Version       | Arch   | Repository         
--+-------------------------------+------------+---------------+--------+--------------------
  | python-pyxdg                  | package    | 0.19-0.pm.1.1 | noarch | Packman Repository 
  | python-pyxdg                  | srcpackage | 0.19-0.pm.1.1 | noarch | Packman Repository 
i | python-xdg                    | package    | 0.19-6.1      | i586   | openSUSE-11.4-Oss  
v | xdg-menu                      | package    | 0.2-202.1     | i586   | openSUSE-11.4-Oss  
i | xdg-menu                      | package    | 0.2-398.1     | i586   | (System Packages)  
v | xdg-user-dirs                 | package    | 0.13-7.1      | i586   | openSUSE-11.4-Oss  
i | xdg-user-dirs                 | package    | 0.13-18.1     | i586   | (System Packages)  
i | xdg-user-dirs-debuginfo       | package    | 0.13-7.1      | i586   | openSUSE-11.4-Debug
  | xdg-user-dirs-debugsource     | package    | 0.13-7.1      | i586   | openSUSE-11.4-Debug
i | xdg-user-dirs-gtk             | package    | 0.8-15.1      | i586   | openSUSE-11.4-Oss  
i | xdg-user-dirs-gtk-debuginfo   | package    | 0.8-15.1      | i586   | openSUSE-11.4-Debug
  | xdg-user-dirs-gtk-debugsource | package    | 0.8-15.1      | i586   | openSUSE-11.4-Debug
  | xdg-user-dirs-gtk-lang        | package    | 0.8-15.1      | noarch | openSUSE-11.4-Oss  
v | xdg-utils                     | package    | 1.0.2-93.1    | noarch | openSUSE-11.4-Oss  
i | xdg-utils                     | package    | 1.0.2-105.1   | noarch | (System Packages) 

Regards
Martin
(pistazienfresser)

Bug 679158 - Yast2 sometimes does not start from the menu
https://bugzilla.novell.com/show_bug.cgi?id=679158

looks to me a bit like the smaller KDE-brother of this (GNOME ?) bug.
Could they be connected?

Regards
Martin
(pistazienfresser)

Compare also (connected?/the cause?):

Bug 655751 - gdbus aborting due to unauthorized socket in DBUS_SESSION_BUS_ADDRESS

With https://bugzilla.novell.com/show_bug.cgi?id=655751#c0 :
"Description Guido B[...] 2010-11-24 14:39:12 UTC 
[...]
When DBUS_SESSION_BUS_ADDRESS is set to the valid socket of another user glib
will abort due to an assertion failure when more than one connection attempt
via gdbus is made. In practice this often happens when users try to execute GTK
applications which use GConf through su/sudo without properly clearing the
environment (e.g. starting YaST with xdg-su xterm+su).
A minimal example which triggers the problem is attached.

This bug affects glib2 verion 2.27.x in Factory, openSUSE 11.3 is not affected
since it uses an older glib version without GDBus. The bug has been reported
upstream: https://bugzilla.gnome.org/show_bug.cgi?id=635694
[...]
"

I have also to type my user password again each time I log in the desktop enviorment GNOME (others too, not sure about KDE).
I do not recall changing my security settings like that way.
And I am not able to change that back in the appearing (GNOME keyring?) window - that option is grayed out/disabled there.

Are you interested in this bug/failure any more?
I would like to install the hole openSUSE 11.4 system again in the next time but would do not so if there is a real possibility that I could help improving openSUSE with reporting further data about the issue.

The last updates including those to
- yast2-control-center|2.20.2-1.3.1|i586
- yast2-control-center-qt|2.20.2-1.3.1|i586
brought no changes to that issue as far as I could retrace.

But playing around I to noticed that the entry in the YaST Control Center for the online update configuration just starts easily. Using the "Advanced" bottom there I was even able change the priority of a repository. 
The clicking on that entry seems to initiate the execution of
/sbin/yast2 online_update_configuration
and so it is using probably *no* xdg stuff
(and not trying to become root or get root privileges a second time):


/usr/share/applications/YaST2/online_update_configuration.desktop
[CODE]
[Desktop Entry]
X-SuSE-translate=true
X-SuSE-DocTeamID=ycc_online_update_configuration
Type=Application
Categories=Settings;System;Qt;X-SuSE-YaST;X-SuSE-YaST-Software;

X-SuSE-YaST-Call=online_update_configuration
X-SuSE-YaST-RootOnly=false
X-SuSE-YaST-Group=Software
X-SuSE-YaST-AutoInst=all
X-SuSE-YaST-AutoInstClonable=true
X-SuSE-YaST-AutoInstRequires=lan,proxy
X-SuSE-YaST-AutoInstSchema=online_update_configuration.rnc

Icon=yast-online_update
Exec=/sbin/yast2 online_update_configuration

Name=Online Update Configuration
GenericName=Online Update Configuration
StartupNotify=true
[/CODE]

Dear all,

I have the same problem on my laptop. I have upgrade opensuse 11.4 from 11.3 (The first installation was an 11.0 updated to 11.1 then 11.2, 11.3 and finally 11.4). 
If I do in a shell 
su 
yast2 
I have the following error
GLib-GIO:ERROR:gdbusconnection.c:2279:initable_init: assertion failed: (connection->initialization_error == NULL)
/sbin/yast2: line 423:  5239 Abandon  

But I can open it graphically via computer -> yast2. In the opened window when I try to open an application nothing append (just the waiting symbole). Now if I do in a shell
su
yast2 --ncurses this ungraphic version works well. 

Finally, if I open the graphical version via computer and that I move the icons on my Desktop (ie I create a desktop short cut) I can open the applications by using the icons of Desktop without problems... (I have just to give the root password).

I'm not an expert but as it appears that it is a graphical problem I give you my graphic card configuration: I have a NVIDIA 9600M GT graphic card and to install driver I can't use the rpm of NVIDIA repository (the version of kernel is not the same of mine?) so I use the file provided on NVIDIA web site:   
http://www.nvidia.fr/object/linux-display-amd64-260.19.36-driver-fr.html
that I installed in root.  

I hope that my message help you to fix the problem.

I think I might have a similar issues here: https://bugzilla.novell.com/show_bug.cgi?id=739088

There appears to be an issue with xdg-su.

You can read more here: http://forums.opensuse.org/english/get-technical-help-here/applications/470492-yast-wont-open-up-when-opened-kickoff-menu.html

Dear Reporter,

Thank you for taking the time to report this bug and helping to make openSUSE better.

We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in openSUSE since the time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a current, supported openSUSE version.

When you test it and it is still an issue, kindly reopen this bug and move it to the tested version of openSUSE. 

Truly yours.