YaST fails with message:
Permission denied.
Possibly incorrect password, please try again.
On some systems, you need to be in a special group (often: wheel) to use this program.
Adding the user to group wheel does not help.
openSUSE systems do not use the security filosophy that uses the wheel group.
OTOH other operating systems that use the wheel group, do not use YaST.
Thus I do not undrstand the “On some systems ,” at all.
Are you using YaST for the first time? I doubt.
Do you use it from a strange place? Normaly in a GUI one simply clicks on the YaST icon in the main menu (or panel). The fact that you use /usr/bin/xdg-su points to you starting it from a terminal. But from where? A terminal inside a GUI session? What user in that terrminal session? When it is a normalk user and outside a GUI session, what do you expect to happen?
In fact, we miss the complete copy/paste of the prompt-command line, the output and the new prompt line. Something that could tell others a lot of things.
Actually I click the starter on my desktop which is linked as follows:
karl@erlangen:~> ll Schreibtisch/org.opensuse.YaST.desktop
lrwxrwxrwx 1 karl users 49 17. Okt 09:09 Schreibtisch/org.opensuse.YaST.desktop -> /usr/share/applications/org.opensuse.YaST.desktop
karl@erlangen:~>
karl@erlangen:~> cat /usr/share/applications/org.opensuse.YaST.desktop
[Desktop Entry]
Type=Application
Categories=Settings;System;X-SuSE-Core-System;X-SuSE-ControlCenter-System;X-GNOME-SystemSettings;
Name=YaST
Icon=yast-control-center
GenericName=Administrator Settings
Exec=/usr/bin/xdg-su -c /sbin/yast2
Encoding=UTF-8
Comment=Manage system-wide settings
karl@erlangen:~>
Authentication fails with a window displaying:
Der Zugriff wird verweigert.
Möglicherweise wurde das falsche Passwort verwendet. Bitte versuchen Sie es erneut.
Auf manchen Systemen ist die Zugehörigkeit zu einer speziellen Gruppe (oft: wheel) für das Verwenden dieser Anwendung notwendig.
I am using KDE.
From an icon in the panel, the Properties say that the location is /home/henk/.local/share/plasma_icons and that the Command is is /usr/bin/xdg-su -c /sbin/yast2.
henk@boven:~/.local/share/plasma_icons> cat YaST\ \(1\).desktop
[Desktop Entry]
Type=Application
Categories=Settings;System;X-SuSE-Core-System;X-SuSE-ControlCenter-System;X-GNOME-SystemSettings;
Name=YaST
Icon=yast
GenericName=Administrator Settings
Exec=/usr/bin/xdg-su -c /sbin/yast2
Encoding=UTF-8
Comment=Manage system-wide settings
henk@boven:~/.local/share/plasma_icons>
Which is not the same place as your icon on the Desktop (I do not have that), but the command is the same.
I never had any problem with starting YaST through that panel icon.
From the Main KDE menu the item YasST (in System) shows the same command: /usr/bin/xdg-su -c /sbin/yast2
When I execute that command from a Konsole terminal emulator:
henk@boven:~/.local/share/plasma_icons> /usr/bin/xdg-su -c /sbin/yast2
henk@boven:~/.local/share/plasma_icons>
It first shows the window to enter the password and after entering it, it show the YaST main window.
Thus I guess the command is correct.
Which again does not bring us much nearer to the cause of your problem.
May I ask again if this is the first time you start YaST in this way (or at all), or is this something where we have to search for some update or install done lately?
It worked for years the same way it works for you. After updating to 20191014 / KDE 5.17 the starter is broken.
Can you roll back?
I assume we will get more people having this in short notice.
(I am not running TW, so do not count on me).
I just tested here (in a KVM virtual machine). And Yast still works the same way as ever.
I tried with both a “Full Wayland” session and an X11 session. No problems either way.
Try opening a root command line, and running “yast2” from there. Does that work?
The problem occurs with xdg-su. As I am running a root konsole anyway by typing ‘su -’ adding ‘yast2&’ is a handy workaround. I checked out Bug List to no avail.
That was a good idea for testing indeed.
I do not have pam_kwallet installed. If you have that installed, you might experiment with uninstalling to see if that changes anything. At some time in the past, pam_kwallet did cause problems. That was fixed, but a similar bug might have shown up.
Hello,
I have exactly the same problem on one computer.
I don’t have it (the problem) on another computer with the same OS (which is a laptop), there everything works as expected.
On the command line “su” and “sudo” work perfectly…
But when I enter (command line)
kdesu dolphin
the same error (wrong password) appears…
Already any idea?
Thanks,
Johannes
Try to find out where those two systems differ.
Or, because it seems to be a desktop issue, try to find out where those two users differ (e.g. by creating a new user and see if it has the problem).
If the problem is on only one machine when the two machines should otherwise be pretty close to identical, instead of trying to identify the problem I’d instead ensure that the problem machine is fully updated and consistent, and if that didn’t work then do a re-install (dup).
Updating and resetting system’s internal consistency
zypper up
“Quick” re-install
zypper dup
Deeper re-install
Use the DVD to repair, followed by updating.
TSU
Hi
Looks like it’s a bug… fix on the way:
I ran the following an succeeded:
2019-10-19 11:53 32579 1.14.30 zypper ar -f -p 100 https://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Factory test
2019-10-19 11:54 32739 1.14.30 zypper install plasma5-workspace-5.17.0-483.1.x86_64
It also worked here. However while installing there were some error messages that some scripts failed. The reason was the same as the reason for kdesu not working.
Therefore two questions:
- Has anybody an idea, if this has an impact?
- Can I remove the “test” repository again?
Thanks,
Johannes
I always run ‘zypper dup’ before changing the list of repos. When adding test and installing the following no errors were reported:
erlangen:~ # zypper se --installed-only --repo test
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+------------------------+-------------------------------------+--------
il | plasma5-workspace | The KDE Plasma Workspace Components | package
il | plasma5-workspace-libs | The KDE Plasma Workspace Components | package
erlangen:~ #
test has priority 100, which is lower than default value 99, ‘zypper dup’ reports: Nothing to do. Thus it probably will not cause trouble when installing new snapshots.
I enabled notification by adding my mail address to 1154345 – plasma breaks exporting bash functions and will disable repo test when notified.
Got notified about pending updates and installed:
erlangen:~ # zypper se --installed-only --repo download.opensuse.org-tumbleweed
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-------------------------+--------------------------------------------+--------
i | gmenudbusmenuproxy | GMenu to DBusMenu Proxy | package
i+ | plasma5-session | KDE Plasma 5 X11 Session | package
i | plasma5-session-wayland | KDE Plasma 5 Wayland Session | package
i+ | plasma5-workspace | The KDE Plasma Workspace Components | package
i | plasma5-workspace-lang | Translations for package plasma5-workspace | package
i+ | plasma5-workspace-libs | The KDE Plasma Workspace Components | package
i | xembedsniproxy | XEmbed SNI Proxy | package
erlangen:~ #
Repo test is not needed anymore.
I’ve noticed this exact same problem with only my oldest snapshot not displaying this behaviour. I needed to delete a printer & use YaST2 HPLIP plugin to configure new printer. The work around is to execute “yast2” from root shell.