… because the update has switched my (German) keyboard to English (USA) and I don’t know how to reach the “²”-character (AltGr-2 in the German layout), which is part of my pass-code.
Somebody will probably offer an easier way, but i think at the end you should follow the procedure for forgotten password, set a password with only english characters (and remember y and z are changed), login in, set the keyboard layout and change it again.
Pump esc on boot to show grub.
Hit e to edit the boot line.
Change ro to rw. Add single at the end.
Ctrl X will boot as root.
passwd user, new password in plain English
sync
reboot
That is if you do not use encryption otherwise you have to unlock the container beforehand.
Plain English Passwords are completely useless as long as they’re shorter than a booklet.
And the perspective to be forced through such a painful and hour-eating procedure by standard updates doesn’t encourage me to start it.
And I just can’t believe that it’s impossible to enter unicode with an American keyboard without an editor …
… or why such a thing is set as Manjaro’s standard for a global audience.
Unfortunately, the layout for US is only 2 level, so it doesn’t include ². In fact I don’t think even the us_intl layout includes it.
It’s not Manjaro, it’s the default for something but I can’t remember what right now.
It should only take a few minutes (or less) to change the password (or the setting once you know what it is).
Another option is to use a live USB, manjaro-chroot -a into the system and change the password or setting. Might be easier if you use encryption, but you’d have to unlock your filesystems before chrooting.
Edit:
It could be xkeyboard-layout, as mentioned in the known issues from the stable update thread. Here’s the link from that thread.
Linux, BSD - unfortunately they are at the core US. So using passwords you can’t type in on a standard US layout without using any additional software/service has the potential to lock you out of your system.
That is a common misunderstanding.
Nuzzle1-Flagship5-Dynamite7
The above example has enough entropy to be nearly impossible to brute force.
sure, but I’d have to do it for all users and installations on all machines (well currently just 2, 3rd pending)
and I’m more than happily glad I didn’t dare to let it update this desktop from which I’m currently writing this.
Due to a bureaucratic deadline this week, that would’ve been devastating.
And the reboot alone causes a loss of more than an hour for restoring the environment for a specific task with all its windows spread over the suitable workspaces.
Even if I believed that it would protect against Google, Meta, Microsoft and the like …
it would definitely lock me out latest tomorrow if I didn’t stick it directly and irremovable to the screen. 
Mod edit: Consecutive posts merged.
Probably the xkeyboard layout thing from the eos link above. Because i have previously edited my vconsole.conf and my german keyboard did not disappear after the update.
Of course as a computer user since 1993 i have learned never to make passwords with non-us characters. For years, that was not even possible anyway. But better safe than sorry. There are enough ways for secure authentication with English - certificates, passkeys, pseudo-sentences like the above, paddings, etc.
As i showed you above, the desktop login password protects you from nothing if the attacker has a physical access, there encryption for that. And if you use remote access vie ssh it should not use passwords at all.
There’s more than 1 aspect of “safe”: safe from hacking, safe to remember¹, safe for updates, … 
¹) that’s become a challenge for some years 
And in the 90ties I felt safe with “simple” passwords, had no clue of how much would be invested into the “AI”-weapon nowadays.
… and I didn’t get stuck in that era however I enjoyed it.
There are generally two types of attacks against passwords.
- Dictionary attacks
- Brute-force attacks
A dictionary attack is very easy to circumvent — simply choose a password that’s not in the dictionary. This is why dictionary attacks are not used much.
A brute-force attack is harder to circumvent, because it uses random combinations of characters — including non-ASCII characters — and circumventing it relies on creating enough entropy, in combination with something like fail2ban, which delays the login procedure by a certain (potentially increasing) amount of time between failed login attempts.
Therefore, it is wiser to use long passwords, and keeping in mind that brute-force attacks primarily use random characters as password guesses in order to break entropy by sheer luck, to actually not choose a password made up of random characters, but to instead choose a password (or passphrase) that makes sense to you and that is also easy to remember for you.
And of course, if the attacker knows you or has access to your private data, then they will of course also attempt to use birth dates, phone numbers, pet names, et al — of yourself as well as of your family members.
Also interesting to note is that a UNIX login does not get validated until after both a user account and a password are supplied. Therefore, the attacker won’t know whether a username is valid or not until they have successfully supplied both a correct username and its correct password, and in the event of a failed login, the error message will not tell them that the username was invalid, even if it was. It will simply state “Login incorrect.”
For everything, i use Keepass. Loooong random passwords, safely encrypted with loooong password and key data.
For login/sudo as said doesn’t make much sense if one gets hold of the laptop. For this purpose - encryption or hdd password (not the safest but a good compromise against casual thiefs who just want to resell the laptop, against those hdd password is more than enough. Depending on hardware there might actually even be an encryption behind.
First of all, big thanks for all your contributions!
And as an answer to the last and last but one:
The aspects which @Aragorn mentions I’ve always taken into account.
And I’d used keepass and similar applications and encryption until their passwords had been erased from my (biological) memory and I needed some weeks including travels to sessions with two very capable hackers in family & friends to restore at least a backup with most of the data.
Anyway, I’ll postpone recommissioning that laptop for ~ a week (won’t need it badly until traveling in September) and concentrate on preparing the (productive) desktop correspondingly for that update, later this week.
— Follow-up —
Meanwhile I’ve dared to let the desktop update
after finishing 3 “deadlined” tasks in time
and preparing it with simple passwords …
… just to be surprised that it hasn’t suffered the keyboard theft, the laptop had.
(probably thanks to the older kernel)
So I thought to be ready to repair the laptop, but got stuck:
In that system’s grub command line the line starting with linux contains rw already, so I left it as is.
Appending single to it effects in throwing me in grub rescue mode after hitting Ctrl-X.
Neither there nor when going to the single commands mode via Ctrl-C or F2,
it knows/accepts a passwd command.
Mod edit: Consecutive posts manually merged, to preserve the reactions. 
There are several options for this, alternatively try
init=/bin/bash
Or
systemd.unit=rescue.target
none of these lines (even after managing to enter them with the broken keyboard SW) has any visible effect.
At least passwd still cannot be found (and I have no clue what else to try).
Interesting i have to test when i get home.
Then the only option will be a live iso, boot there, chroot and then change the password. You know how to chroot i guess?
P.s. actually if chroot i guess you can try to fix the vconsole.conf and then problem will be solved without changing the pass temporarily.
edit: tested single, on a systemd based boot it works like rescue target (it is NOT grub rescue, it is systemd rescue which has more commands), but requires the root password. Well, things change, at least i refreshed my knowledge.
Well, I’ve successfully chrooted from the iso several times in the past few years …
Ahh - if it’s about vconsole.conf, I could probably do it from the grub command line - the necessary tools seem reachable from there.
setxkbmap de
command does not reset the keyboard layout to German?
Don’t think that the command is reachable from where the system keeps throwing me into.
And the situation has become worse:
I seem to be no longer able to intercept booting into the grub menu and enter the bios settings in order to boot from my iso stick.
Can’t say anything about this…maybe you are not fast enough…start pumping the key immediately after pressing the start button. The same second, even before the screen turns on and pump it very fast until the system pauses. I actually use 2 hands - one on the power button and the other on F2, 12, del or whatever according to manufacturer.
But, after you figure it out, here is my German vconsole file. just for reference since it took me some time experimenting to find the right layout (no guarantees, this is on Ideapad)
[teo@teo-lenovo-v15 ~]$ cat /etc/vconsole.conf
# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=de-latin1-nodeadkeys
FONT=lat2-16
FONT_MAP=8859-1
XKBLAYOUT=de,us
Frustration by this update is becoming infinite.
Developing from “not amused” to growing annoyance to desperation.
Eventually I’ve managed to boot from the ventoy stick.
Time to press F10 (for BIOS) (or F8 for boot sequence) to intercept the grub has always been 1-3 seconds, after the update it’s decreased to (a fraction (?) of) a millisecond.
But unlike to such sessions in the past (last one perhaps a year ago), once I’ve “successfully” entered it, I don’t find a way to access the configuration (“dot”-files or privileged directories) of the permanent file system, nor a way to temporarily install usable applications (e.g. Nemo to replace Nautlus which not even shows the option to show hidden files or Terminal instead of Console) …
oh well part of the above was an effect of missing internet (which is normally connected automatically).
After connecting it’s now nagging with a request to “install” >900 updates in a frequency > 1Hz.
An hour later I got to /etc/vconsole.conf - it contains just “KEYMAP=de” - - - and now?
Is XKBLAYOUT suddenly (since that disastrous update) indeed necessary?
…
One night later:
Eventually I’ve been able to shorten the passwords for the users in the permanent file system by taking the chroot route.
I don’t regard this as a solution for the initial problem (loss of keyboard configuration for log-in) so do not mark it as 
Solution.
But the whole story showed me again the vital importance of having multiple working systems to retain one for searching possibilities to rescue another wrecked one.
— end of story —