The suggested password check command did not point details out for which I would worry at the moment.
I am becoming more concerned about an other message in my change root environment.
nohostname:/ # passwd $USER_ID
passwd: Module is unknown
passwd: password unchanged
Several users stumbled on such a “surprise” before. I am curious on the way to fix the involved software dependencies for my use case.
Can a system reinstallation be avoided?
I can only suggest examining the journal log for errors eg pam_unix messages
journalctl -f
then run the passwd command in another VT. Maybe that wil yield ore information about what is wrong. That’s about all I can offer here.
By which function implementation is the message “passwd: Module is unknown” generated?
Do the corresponding source files provide more useful insights?
Can’t help you with those questions… Did you examine the journal log (as per my last post)?
Messing with the shadow file probably did not help. Did you restore it from a backup?
No. - I stored a copy of the shadow file before I started to experiment with password alternatives for the desired login.
How are the chances to repair the dependencies by another software update?
If BTRFS then use snapper to drop to previous state then do the update
The problem was not in shadow so that should not be changed or messed with
The reactiviation of a previous login system revision will not work in this way while I prefer to use other file systems.
The problem was not in shadow so that should not be changed or messed with
Can the error source be determined by additional means (besides inspection of special log files)?
Thanks for your suggestion.
journalctl -f
Jun 20 22:00:01 nohostname passwd[6753]: PAM unable to dlopen(/lib64/security/pam_unix.so): /lib64/libnsl.so.2: symbol key_secretkey_is_set, version TIRPC_0.3.2 not defined in file libtirpc.so.3 with link time reference
Jun 20 22:00:01 nohostname passwd[6753]: PAM adding faulty module: /lib64/security/pam_unix.so
Jun 20 22:00:01 nohostname audit[6753]: USER_CHAUTHTOK pid=6753 uid=0 auid=2000 ses=3 msg='op=PAM:chauthtok grantors=? acct="elfring" exe="/usr/bin/passwd" hostname=? addr=? terminal=pts/1 res=failed'
Jun 20 22:00:01 nohostname kernel: audit: type=1108 audit(1466452801.900:673): pid=6753 uid=0 auid=2000 ses=3 msg='op=PAM:chauthtok grantors=? acct="elfring" exe="/usr/bin/passwd" hostname=? addr=? terminal=pts/1 res=failed'
then run the passwd command in another VT.
Another try for a password adjustment succeeded in my change root environment after I updated the mentioned software libraries by the tool “zypper” once more.
Maybe that wil yield ore information about what is wrong.
Do the shown software dependencies need eventually further considerations?
Another try for a password adjustment succeeded in my change root environment after I updated the mentioned software libraries by the tool “zypper” once more.
Okay, so you can login as root successfully now?
Yes. - The login procedure seems to work again as expected.
I needed a while to become more aware about solutions for a questioanble PAM module configuration. How do you think about to improve the specification of involved dependencies for the corresponding libraries and software packages?
Good to know.
I needed a while to become more aware about solutions for a questioanble PAM module configuration. How do you think about to improve the specification of involved dependencies for the corresponding libraries and software packages?
I can’t answer that - many of your questions are too cryptic and esoteric for me. You probably should direct them at the developers.
How often do you fiddle with software settings to repair the mentioned dependencies for the PAM system?
Not often AFAIK this was a one off problem. In TW you need to expect problems since it is a rolling release and constantly changing.
I would appreciate if the probability for such technical surprises can be reduced a bit more. How do you think about to achieve better and safer specifications for software packages?
Well report problem on bugzilla to hope to have any problem fixed but if you want stable better to use LEAP
I have got the impression that a single bug report will not really help in this use case.
You can always get involved and program/test. But you must expect problem in a cutting edge rolling release