passwd can't change root password in freebsd14.2?

fff2024g

fff2024g

dear all:
morning, my old freebsd13.0 upgraded to freebsd14.2 , when i want to change my root password , below was the error :
root@issssssssssssss:~ # passwd
Changing local password for root
New Password:
Retype New Password:
passwd: entry inconsistent
passwd: pam_chauthtok(): Error in service module

,how to fix the error ? thanks.
 
I recently had a similar problem where I messed up with a source upgrade and did not do the needed removals.

I had to edit /etc/pam.d/system to get it back. Your error looks slightly different.

Mine was pam_opie was removed in FreeBSD and I did not allow it to be removed. Hence problems.
 
SirDice said:
I suspect your master.passwd has a bunch of merge issues left in there.
Click to expand...
Most likely this is the explanation for the failure.

fff2024g said:
,how to fix the error ? thanks.
Click to expand...
Boot system into single user mode, mount filesystem read/write

UFS
Code: 
 # mount -u /

ZFS (If the pool has a different name, or the "default" dataset, change accordingly.)
Code: 
 # zfs readonly=off zroot/ROOT/default
, edit /etc/master.passwd , remove those so called "conflict markers" (<<< ===== >>>) and referenced lines [1] [2].
 
T-Daemon said:
Most likely this is the explanation for the failure. […]
Click to expand...
As far as I know all tools (pw(8), vipw(8), passwd(1), chpass(1) and freebsd-update(8) → pwd_mkdb(8)) use a temporary master.passwd before committing any changes. This means new /etc/pwd.db and /etc/spwd.db are created from this scratch master.passwd. Only if everything worked fine all new files are rename(2)ed.​
SirDice said:
I suspect your master.passwd has a bunch of merge issues left in there. […]
Click to expand...
freebsd-update(8) rejects files still containing merge markers. I mean, you can override the check (type ACCEPT case‑insensitively) but I seriously doubt fff2024g is that dumb.​
Phishfry said:
[…] I had to edit /etc/pam.d/system to get it back. […]
Click to expand...
Yet /etc/pam.d/passwd does (by default) not include (“source”) /etc/pam.d/system. I would still temporarily remove any no_warn module parameter, maybe even add debug, see if that reveals the specific circumstance causing troubles.​
fff2024g said:
[…] i want to change my root password […]
Click to expand...
You “want” to disable password-based authentication for root entirely. There are sudo(8), doas(1), you name it. (OK, I gotta admit I still assign human-usable root passwords.)

PS: I haven’t used any upgrade process other than freebsd-update(8) so I’m not familiar with the source‑code based workflow (should fff2024g have used that avenue).​
 
T-Daemon said:
Most likely this is the explanation for the failure.


Boot system into single user mode, mount filesystem read/write

UFS
Code: 
 # mount -u /

ZFS (If the pool has a different name, or the "default" dataset, change accordingly.)
Code: 
 # zfs readonly=off zroot/ROOT/default
, edit /etc/master.passwd , remove those so called "conflict markers" (<<< ===== >>>) and referenced lines [1] [2].
Click to expand...
dear t-daemon:
i have removed conflict markers . but i still got below error.
root@iqqqqqq:~ # passwd
Changing local password for root
New Password:
Retype New Password:
passwd: entry inconsistent
passwd: pam_chauthtok(): Error in service module

how to easily rebuild password system in freebsd14.2 ? thanks.
 
Kai Burghardt said:
As far as I know all tools (pw(8), vipw(8), passwd(1), chpass(1) and freebsd-update(8) → pwd_mkdb(8)) use a temporary master.passwd before committing any changes. This means new /etc/pwd.db and /etc/spwd.db are created from this scratch master.passwd. Only if everything worked fine all new files are rename(2)ed.
freebsd-update(8) rejects files still containing merge markers. I mean, you can override the check (type ACCEPT case‑insensitively) but I seriously doubt fff2024g is that dumb.
Yet /etc/pam.d/passwd does (by default) not include (“source”) /etc/pam.d/system. I would still temporarily remove any no_warn module parameter, maybe even add debug, see if that reveals the specific circumstance causing troubles.
You “want” to disable password-based authentication for root entirely. There are sudo(8), doas(1), you name it. (OK, I gotta admit I still assign human-usable root passwords.)

PS: I haven’t used any upgrade process other than freebsd-update(8) so I’m not familiar with the source‑code based workflow (should fff2024g have used that avenue).​
Click to expand...
DEar kai burghardt ;
thanks for your reply , what is the best and fast solution about this issue ? thanks.
 
fff2024g said:
what is the best and fast solution about this issue ?
Click to expand...
Have you actually diagnosed what the root cause of the problem is? You can become root, and just look at the password files. The format of the file is easy to figure out: Comment lines start with # (I don't remember whether they have to be in column 1), and the rest of the lines are colon-delimited, with the fields documents in "man 5 passwd".

I the passwd and master.passwd files pass that test, then look at the config files for pam. They are all human readable, and pretty easy to understand.
 
fff2024g said:
dear t-daemon:
i have removed conflict markers . but i still got below error.
Click to expand...
Have you removed double entries as well?

Another option is to try master.passwd from backup: /var/backup/master.passwd.bak.

Rename /etc/master.passwd, copy backup in place (without .bak extension).
 
T-Daemon said:
Have you removed double entries as well?

Another option is to try master.passwd from backup: /var/backup/master.passwd.bak.

Rename /etc/master.passwd, copy backup in place (without .bak extension).
Click to expand...
Dear t-daemon:
i have removed conflict comment. i think the master.passwd was failure . and i don't have a backup . can we regenerate the master.passwd file ? thanks.
 
You are logging in Single User Mode correct? It runs without password and allows you to work on some problems.
In Single User mode look at vipw and look for comments. They are at top. Post it if you can,

"Leftover" comments from upgrade are also something that got me in the past.
It's telling you what to do but the diff is not easily readible to me.

>>FreeBSD 13. blah blah blah

I like to use vipw because it will tell you if password file is OK and it views the file in raw text mode.
As a bonus it saves all changes to the system database. So be careful with it.

Skipping steps of upgrade is the core problem for me. You have to resolve the issue.
From 13.0 to 14.2 was a big jump. It makes it harder.
 
T-Daemon said:
Have you also removed the same entries? See this post.
Click to expand...
DEar T-daemon:
i have removed wrong line. just keep below line in master.passwd.
root::0:0::0:0:Charlie &:/root:/bin/sh
toor:*:0:0::0:0:Bourne-again Superuser:/root:
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26::0:0:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
unbound:*:59:59::0:0:Unbound DNS Resolver:/var/unbound:/usr/sbin/nologin
proxy:*:62:62::0:0:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64::0:0:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
auditdistd:*:78:77::0:0:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin
_ypldap:*:160:160::0:0:YP LDAP unprivileged user:/var/empty:/usr/sbin/nologin
hast:*:845:845::0:0:HAST unprivileged user:/var/empty:/usr/sbin/nologin

. that is my wrong . can we regenerate a correct master.passwd file to replace the old one ? thanks.
 
fff2024g said:
i have removed wrong line. just keep below line in master.passwd.
Code: 
root::0:0::0:0:Charlie &:/root:/bin/sh
Click to expand...
A removed root password wouldn't cause the error you are seeing.

I suspect that during the system update process, merging and subsequent editing of master.passwd, maybe one or more non-printable control characters have sneaked in, probably carriage return (Newline) ( CR, \r, ^M). (which editor did you use?)

On a test system passwd: pam_chauthtok(): Error in service module is exactly the error message returned in a attempted password change, if a control character (^M) is present in master.passwd.

You can display those non-printable characters with vis(1), and base system vi(1), with the latter edit them out directly.

Make a copy of master.passwd before operating on it.

EDIT: The master.passwd from post # 15 looks unmodified, without users added. If that's the case don't bother editing, just fetch a new one, i.e.:

fetch https://cgit.freebsd.org/src/plain/etc/master.passwd
 
T-Daemon said:
A removed root password wouldn't cause the error you are seeing.

I suspect that during the system update process, merging and subsequent editing of master.passwd, maybe one or more non-printable control characters have sneaked in, probably carriage return (Newline) ( CR, \r, ^M). (which editor did you use?)

On a test system passwd: pam_chauthtok(): Error in service module is exactly the error message returned in a attempted password change, if a control character (^M) is present in master.passwd.

You can display those non-printable characters with vis(1), and base system vi(1), with the latter edit them out directly.

Make a copy of master.passwd before operating on it.

EDIT: The master.passwd from post # 15 looks unmodified, without users added. If that's the case don't bother editing, just fetch a new one, i.e.:

fetch https://cgit.freebsd.org/src/plain/etc/master.passwd
Click to expand...
Dear t-daemon:
thanks for your help. i have run your guide command . below was error :
fetch: https://cgit.freebsd.org/src/plain/etc/master.passwd: Operation timed out
i think this web site was not exist . please check it . thanks.

the ipv4 network can't reach that web site. i have use ipv6 network got it and replease it. but still got same error
root@iZf8z7jt2n2h7jopce0widZ:~ # passwd
Changing local password for root
New Password:
Retype New Password:
passwd: entry inconsistent
passwd: pam_chauthtok(): Error in service module
 
fff2024g said:
i have run your guide command . below was error :
fetch: https://cgit.freebsd.org/src/plain/etc/master.passwd: Operation timed out
i think this web site was not exist . please check it . thanks.
Click to expand...
Works for me.
fff2024g said:
the ipv4 network can't reach that web site. i have use ipv6 network got it
Click to expand...
Next time when using fetch(1) try option -6, --ipv6-only Forces fetch to use IPv6 addresses only.

fff2024g said:
got it and replease it. but still got same error
Click to expand...
I can't imagine what the origin of the error could be.

If you run passwd(1) with truss(1) you may get a hint as to the source of the error: truss passwd, enter password.
 
You must log in or register to reply here.
Back
Top