That sounds very much like what I experienced long ago.
Try the steps I describe, if you can’t use YaST to reset the root password (logged in as root), then use the passwd command in a console (again, logged in as root).
TSU
I searched the whole of this thread, but usage of su (or even sudo) is nowhere mentioned (until my poost #16).
The OP only reports that he has a problem with the password window offered when calling YaST (the GUI). When you found that he used
su -
or even
su
please give me the post number and I will cover myself in ashes :\
Isn’t that the same thing?
YaST requires privilege escalation.
I don’t know that there is any difference between the Yast2 graphical tool and elevating in a console (I often elevate in a console before invoking Yast2, it saves lots of entering YaST passwords opening different YaST modules).
So, at least in my mind when I saw the described problem (YaST root authentication required), to me it’s the same as elevating in a console which I then recalled my own situation.
TSU
The result is the same: running certain child processes as owned by user with UID 0 (and user name root). Something you call “elevating” or “privilege escalation”, which is easy to give roughly one name to all different methods to reach that result, but as soon as we have to find out if and what goes wrong, one has yo go into the details and not see all those different methods as one magical wand where all will fail when one fails.
And su and sudo are some of the programs that can do so. Each in their own way.
henk@boven:~> ls -l $(which su) $(which sudo)
-rwsr-xr-x 1 root root 31744 22 okt 2015 /usr/bin/su
-rwsr-xr-x 1 root root 155112 21 okt 2015 /usr/bin/sudo
henk@boven:~>
And they do so by:
- being owned by root and having the SUID bit set (thus they start their life in a process already as root even when started by a non-root process);
- they check if all conditions to allow further action are met, like can the user provide the root password (in the case of su), or are they conform the conditions configured inn the sudoers file (in the case of sudo).
- they bail out when the conditions are not met, else they start the required subprocess (which as child will now inherit root as owner).
Calling yast/yast2 from the CLI requires you to already run the shell as root.
Calling YaST from the GUI does (in my case from the YaST icon on the desktop):
/usr/bin/xdg-su -c /sbin/yast2
and
boven:~ # ls -l $(which xdg-su)
-rwxr-xr-x 1 root root 14579 Oct 3 2013 /usr/bin/xdg-su
boven:~ #
which is NOT SUID and thus uses another means to check the conditions (in this case a window asking for the root pasword is opened, etc…) and to start a chile owned by root.
Thus these are different ways implemented in different software and thus prone to do fail different (when they fail).
This is just a wrapper that selects program from current Desktop Environment (like gksu or kdesu) falling back to su/sudo if nothing better is found. Programs it calls that actually do the job are suid root.
Yes, of course in the end, one of those program is SUID root (else there is no way to run a root owned process as child from not root-owned process).
But my point is that using the GUI adds a lot of extra processes and processing to the that done by a simple su. Thus when something goes wrong, stating that when that GUI range of processes failed, that it is then clear that su will also fail is not a correct conclusion.
Sorry for been away…
I have tried this and it fails, still will not accept the password.
I have used sudo and su in console modes and the problem is still there not accepting the password.
Try as I may… I cannot solve this problem…
Ok.
I have just downloaded TW and written it to a USB stick using imagewriter… Done through the process to install TW again.
Installed if into the same partition as before.
set the / partition and format, /home is on a separate disk no-format, swap exist and is used by openSUSE as well. I have also installed on my system the Manjaro (a rolling release with up to date apps similar to TW) uses the same swap partition.
All 3 OS’s are on their own Primary Partition on the SSD. This setup has been used for over 1 year.
The rolling releases are updated approx every 7 days… openSUSE 42.3 was newly installed a few days after it was released.
Everything was working. I could login as root on any of the OS’s and add, configure etc fine.
The root issue with TW came about after updating back in September. I was not aware of the problem until I wanted to add an application and found the root password was throwing up this error. Today is the 5th new install I have attempted using 8 character passwords for root ( same as user, different from user) and in each scenario the result is the same ‘Authentication failure’ I have used console, xterm.it makes no difference. Used CTRL-ALT-F1 make no difference.
Note:
My system is setup
SSD for O/Systems
sdb
sdb1… Manjaro
sdb2… Tumbleweed
sdb3… openSUSE
sda…
Swap on sda7
sda1 win7
sda2 data
sda3 shared (multimedia files)
sdc1. /home (500GB)
sdc2 unused
Removable 1TB disk in caddy for backups
Grub2 on sda (long time never changed to another disk)
I could not fix this problem in TW…
So I removed it from my system and installed Leap 4.2… Tested users and can confirm that root login works in all scenario, no Issues…
As I prefer to use TW as my OS of choice, I have upgraded Leap to TW as shown in the openSUSE documents. Checked the system after the upgrade… Successful upgrade…
When through the same process of checks as I did in Leap… The root password works under all the tests…
I now have a working system with Tumbleweed OS installed.
Closing…
Congratulations with reaching your goal.
It still might be bit frustrating that you do not know what the root cause of the problem was.
But when you can live with that … enjoy openSUSE.
Thank for all your suggestion and help from the forum… appreciated
I will come back to trying a fresh install of TW again on a separate partition, to see if it still happens. But will leave it for a few months before doing so.