MATE Password for Mate desktop expired

D

dalpets

I am running FBSD 13.0 (release-n244733, April 2021), with Mate desktop. Due to circumstances I haven't used the system for some time and I think my user password has expired, as I can no longer open the desktop with my last known password.

How can I now get access to the Mate desktop?

Thank you in advance
 
Accounts never expire, passwords only expire if explicitly configured that way (not by default). If you didn't do that, I'd look for the more common reasons: Password forgotten, wrong keyboard layout, caps lock enabled, ...
 
When I confirm my new password in single user mode the system does not ask me for my existing password as expected & reports ;
pam chauthtok(): Error in service module

further help please. Thanks
 
This site says there are as many as 9 reasons why this error might occur.
/https://www.cyberciti.biz/faq/linux-unix-bsd-osx-passwd-pam_chauthtok-error-in-service-module/

I didn't have success there. Checks I tried there seemed to be saying my drive was not mounted. So I mounted it. But whenever I tried to reboot with the mount the reboot struggled to find it even though I had quoted it for remount repair.
If I can't get further help I will have to take the last resort of reinstalling the OS. I don't really want to do this because of the work involved.
 
No, the answer is blatantly obvious, pay attention during the upgrade. Because sometimes new accounts and/or new groups are added. And if you don't pay attention you will destroy your current users and groups.
 
SirDice said:
No, the answer is blatantly obvious, pay attention during the upgrade. Because sometimes new accounts and/or new groups are added. And if you don't pay attention you will destroy your current users and groups.
Click to expand...
Blatantly obvious! Not to me. Please explain why new accounts etc should interfere with existing users & groups? That seems counter intuitive to lesser beings. And why only sometimes?
 
dalpets said:
Please explain why new accounts etc should interfere with existing users & groups?
Click to expand...
When you update that new user/group gets merged into your existing user database. When things go sideways you end up with a default user/group database, one that doesn't include all the users/groups that were added since initial install. Think users/groups that are created by installing ports/packages for example, or the ones you added yourself (your own user account for example). No account means you can't login.

dalpets said:
And why only sometimes?
Click to expand...
Not all major/minor upgrades include new base users/groups that need adding. Thus, not all upgrades have this risk.
 
SirDice said:
When you update that new user/group gets merged into your existing user database. When things go sideways you end up with a default user/group database, one that doesn't include all the users/groups that were added since initial install. Think users/groups that are created by installing ports/packages for example, or the ones you added yourself (your own user account for example). No account means you can't login.


Not all major/minor upgrades include new base users/groups that need adding. Thus, not all upgrades have this risk.
Click to expand...
I didn't add any new users or groups so it seems likely that the problem lies elswwhere. As a result I have to dead computers.
Is there a debug script I can use to find out what the problem is?
 
dalpets said:
When I confirm my new password in single user mode the system does not ask me for my existing password as expected & reports ;
pam chauthtok(): Error in service module
Click to expand...
Have you mounted the file system read-write in single-user mode before executing passwd(1)? When the system is booted into single-user mode the file system is mounted read-only (this can be verifyed by executing mount without options). If the file system wasn't mounted read-write, then the error message is printed because of that.

To set the password for the user you don't need to boot into single-user mode necessarily, just boot normal and change into a virtual terminal (assuming there is a login manager running, Ctrl + Alt + F5 for example), and log in as root.

If you insist on single-user mode, before setting a password for the user, mount the file system read-write, execute

when UFS2: mount -uw /,

when ZFS: zfs readonly=off zroot/ROOT/default.
 
T-Daemon said:
Have you mounted the file system read-write in single-user mode before executing passwd(1)? When the system is booted into single-user mode the file system is mounted read-only (this can be verifyed by executing mount without options). If the file system wasn't mounted read-write, then the error message is printed because of that.

To set the password for the user you don't need to boot into single-user mode necessarily, just boot normal and change into a virtual terminal (assuming there is a login manager running, Ctrl + Alt + F5 for example), and log in as root.

If you insist on single-user mode, before setting a password for the user, mount the file system read-write, execute

when UFS2: mount -uw /,

when ZFS: zfs readonly=off zroot/ROOT/default.
Click to expand...
Thanks for your help.
I removed the original user & home group, & added an new user/group & executed mount -uw / so I am a little further on but my Mate desktop advises that it fails to execute the new group & password.
Is this a Mate rather than a BSD misconfiguration. How could I rectify this?
 
My limited knowledge necessitates a reinstallation of two FBSD 13.0 computers for the reason detailed herein, so I have since taken in as much information as I can to avoid a repeat of potential udating/upgrading gotchas.
Youtube tends to only deal with dot version updates not upgrades between major versions & chapter 24 is so complex & non sequential in its treatment that I would be bound to mess up so I'm not ready for that excursion.

I feel I now have the confidence to successfully update dot versions but my outstanding question is, is the upgrade procedure to go from one major version to another major version the same procedure as for dot versions.

If there is info somewhere that I have missed please let me know.

Thanks.
 
dalpets said:
is the upgrade procedure to go from one major version to another major version the same procedure as for dot versions.
Click to expand...
The only difference is for a major version upgrade you need to run freebsd-update install three times, for a minor version upgrade it's two.
 
SirDice said:
The only difference is for a major version upgrade you need to run freebsd-update install three times, for a minor version upgrade it's two.
Click to expand...
But apart from the above there seems to be evidence that major version upgrades are much more complicated than minor updates. That being so what is the defined process that needs to be adhered to for doing so?

I have been unable to find any related documentation as there is for minor updates.
 
dalpets said:
there seems to be evidence that major version upgrades are much more complicated than minor updates
Click to expand...
What evidence is this?

I use ports so there’s one extra command I need to use, but otherwise it’s pretty simple.

Not saying there aren‘t complications but you need to be a bit more specific about what you mean.
 
Just a comment I read online!
The degree of difficulty is surely a matter of 'horses for courses'.
I'm using packages, not ports, so I shouldn't mix them midstream.

If it's 'pretty simple' why did It fail for me when I recall I spent a lot of time trying to get it right?

If it's so simple why can't someone just write down the logical step by step elements of the process for me, including any potential complications along the way?

I appreciate that Sir Dice's comment above is intended to help but it has no context, so it's not ultimately helpful.
 
Is the following process all I need for major to major upgrades

With a major version upgrade; First freebsd-update install only installs the new kernel. You should reboot.

Then run the second freebsd-update install. This updates libraries, userland, everything else except the kernel (that was already done in the first).

At this point rebuild (or reinstall your packages). pkg upgrade -yf
a third freebsd-update install will remove all of the old libraries, tools and whatever else needs removing.

Run pkg check --checksums –to verify none of your existing package installations has been corrupted (when?)

execute freebsd-version -kru after each reboot to see the progress.



pkg upgrade -n also tells you if anything is available to upgrade and will also do the hidden pkg update for you.
 
dalpets said:
First freebsd-update install only installs the new kernel. You should reboot.

Then run the second freebsd-update install. This updates libraries, userland, everything else except the kernel (that was already done in the first).
Click to expand...
For a minor version upgrade the process stops here. This is all that needs to be done in that case.

dalpets said:
At this point rebuild (or reinstall your packages). pkg upgrade -yf

a third freebsd-update install will remove all of the old libraries, tools and whatever else needs removing.
Click to expand...
These are the additional steps that are required for a major version upgrade. It's very important to upgrade your packages at this point, before that last freebsd-update install. If you happen to screw up and forget to upgrade your ports/packages you may run into a problem, pkg(8) might stop working (because the old libraries have now been removed). You can usually fix this by forcing a pkg(7) bootstrap; pkg bootstrap -f. After that pkg(8) should be working again and you can complete the upgrade with pkg upgrade.

There's typically no need to force the pkg-upgrade(8). pkg(8) is smart enough to notice you just did a major version upgrade and will automatically upgrade everything. Early versions of pkg(8) didn't notice this, that's why you might see pkg upgrade -f in some howtos or articles.
 
You must log in or register to reply here.
Back
Top