Weird issue after full update

richardrosa · 2026-11-03 12:41:10

Greetings All,

Recently I did a full update ('sudo pacman -Syu') for my Arch Linux system, and have run into a strange problem.

Years ago, I created a PERL script that runs during the boot process.
This script locates encrypted disks (including one that may contain /home) that MIGHT be present when the system is started.
If any of these disks are present, a prompt for the password is presented, and the disk is mounted.

This script has worked flawlessly with a number of distros and kernels.
It also worked with Arch UNTIL this update.

The script uses the utility 'systemd-ask-password' to request the password from the user.
After this update, this routine was issuing an 'invalid argument' message, and bypassing the password prompt.
However, if the script was executed from a terminal AFTER KDE user sign-in, no error message was issued, and the password prompt succeeded.

What 'systemd-ask-password' was complaining about turned out to be 'esc' characters (used for color/highlighting).
Removal of these characters eliminated the error message & failure.

Does any kind soul have an idea as to what has been added to or removed from this update that would cause this issue?
I would like to return this formatting to the password prompt.
My eyesight is not very good, and NOT having highlight/color in a password prompt makes the message harder to see.

Current version info:
Plasma:6.8.0
KDE Frameworks: 6.31.0
QT Version:6.12.0
Kernel: 7.3.11-arch1-1 (64-bit)

Hardware:
Lenovo T430s
Intel 4 core CPU
Graphics:Intel HD 4000 + Nvidia

Thanx.

Richard Rosa

seth · 2026-11-03 16:27:51

What 'systemd-ask-password' was complaining about turned out to be 'esc' characters (used for color/highlighting).
Removal of these characters eliminated the error message & failure.

Seeing the actual script might help - apparently the escape sequences bleed into the input?

richardrosa · 2026-11-03 22:16:08

Here is the troublesome section of code:

my $Bold = "\e[1m";
my $Green = "\e[32m";
my $Reset =  "\e[0m";
my $msg = "$Bold$Green Enter password for $source:$mp$Reset ('quit' to bypass)";
my $pw = `systemd-ask-password --timeout=0 "$msg" `;

Bypassed error by changing $msg to:

my $msg = "Enter password for $source:$mp ('quit' to bypass)";

This worked fine before the update.
It also works ok from a KDE 'Konsole' without the changes

Rich

seth · 2026-11-03 22:29:26

Does it work w/ any of

my $msg = "\e[1;32mEnter password for $source:$mp\e[0m ('quit' to bypass)";

my $msg = "\033[1;32mEnter password for $source:$mp\033[0m ('quit' to bypass)";

my $msg = "\x1b[1;32mEnter password for $source:$mp\x1b[0m ('quit' to bypass)";

?

richardrosa · Yesterday 09:00:06

Nice idea, but all variations produce the same results.

What is also weird is that esc codes DO work if i issue them in a PRINT statement:

 my $msg = "$Bold$Green Enter password for $source:$mp$Reset ('quit' to bypass)";
print "$msg\n";

This is my workaround (for now). Not as nice, but a decent solution.

I suspect something strange is going on with the TTY setup. Either something added, or something removed.

This update was done on my laptop (which I use occasionally).
Before I apply ANY updates to my main machine, I need to figure out what this issue is.

Thanx for your help.

Rich

seth · Yesterday 12:26:54

I suspect something strange is going on with the TTY setup.

esc codes DO work if i issue them in a PRINT statement

I need to figure out what this issue is

=> /var/log/pacman.log, probably a systemd update?
Despite

if the script was executed from a terminal AFTER KDE user sign-in, no error message was issued, and the password prompt succeeded.

Does the message actually get printed (in color)?

Where exactly do you get the "issuing an 'invalid argument' message"?

dimich · Yesterday 12:56:12

richardrosa wrote:

a PERL script that runs during the boot process.

How does it run during boot process? From systemd service or somehow else? Does it ask password via plymouth in this case?

richardrosa wrote:

The script uses the utility 'systemd-ask-password' to request the password from the user.
After this update, this routine was issuing an 'invalid argument' message, and bypassing the password prompt.

What packages were updated? What systemd and plymouth versions were installed before the update?

richardrosa · Yesterday 19:41:52

seth wrote:

Does the message actually get printed (in color)?
Where exactly do you get the "issuing an 'invalid argument' message"?

The PRINT statement WILL print in color.
The error message is added to the System Log.
It is also shown on the terminal, but it scrolls by too fast to read it.

dimich wrote:

How does it run during boot process? From systemd service or somehow else? Does it ask password via plymouth in this case

I start this script as a system service:

[Unit]
Description=RRM Custom setup
DefaultDependencies=no
Conflicts=shutdown.target
After=local-fs.target
Before=NetworkManager.service systemd-user-sessions.service
Wants=local-fs-pre.target



[Service]
Type=oneshot
ExecStart=/usr/bin/perl /etc/RRM/customize.pl

StandardError=journal+console
StandardOutput=journal+console

RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

What packages were updated? What systemd and plymouth versions were installed before the update?

That is what I am trying to determine.
I Did a FULL update.
Previous level was installed sometime in March or April of this year.

Rich

seth · Yesterday 19:48:49

I Did a FULL update.

seth wrote:

=> /var/log/pacman.log, probably a systemd update?

Though

Previous level was installed sometime in March or April of this year

means "everything was updated"

The PRINT statement WILL print in color.

but what about the "systemd-ask-password" one?
Or does that just not run at all?

my $pw = `systemd-ask-password --timeout=0 "\e[0mfoo" `;

causes the same?

richardrosa · Yesterday 20:22:56

seth wrote:

but what about the "systemd-ask-password" one?
Or does that just not run at all?
my $pw = `systemd-ask-password --timeout=0 "\e[0mfoo" `;
causes the same?

If there are ANY 'esc' chars in the message, systemd-ask-password will terminate with an error.
I DID try (one more case) of directly coding the esc (instead of using a PERL variable) with the same results.

A PRINT statement with esc color codes (issued just before the ask-password works as expected (prints in color).

For jollies, I copied an older version of 'systemd-ask-password from a different machine.
It still fails when there are esc codes.
So this does NOT appear to be an issue with the utility itself, but something that it is using.

Thanx again for the suggestions.

Rich

seth · Yesterday 20:29:02

For jollies, I copied an older version of 'systemd-ask-password from a different machine.

… like libsystemd-shared-*-1.so …
systemd is very much integrated, you're lucky if mixing different versions works at all (the link should™ go to a versioned library and trying to use an older copy fail completely) - the script is probably executed in the initramfs, though and changing anything on the host system (w/o regenerating the initramfs) inert?

Still check your pacman.log to see between which two systemd versions you changed.

dimich · Today 01:01:10

richardrosa wrote:

If there are ANY 'esc' chars in the message, systemd-ask-password will terminate with an error.

systemd-ask-password dispatches requests to different mechanisms depending on how it runs.

$ systemd-ask-password --no-tty --timeout=0 "Enter "$'\e'"[33mpassword: "

yields "Failed to query password: Invalid argument" in console as well.

Probably related: https://github.com/systemd/systemd/comm … 6256c6956a

UPD:

$ SYSTEMD_LOG_LEVEL=debug systemd-ask-password --system --no-tty --timeout=0 "Enter "$'\e'"[33mpassword: "
Password request contains unsafe characters, refusing.
Failed to query password: Invalid argument

Last edited by dimich (Today 01:28:12)

qinohe · Today 08:50:34

So reading this, I thought why not use tput, no escape codes! and perl should be able to work with that.
It may or may not work I haven't tested it.

bold=$(tput bold)
green=$(tput setaf 2)   # or use one of the 255 colors f.i.
reset=$tput sgr0)
msg="$bold $green Enter password for $source:$mp$reset ('quit' to bypass)";

dimich · Today 09:31:58

qinohe wrote:

I thought why not use tput, no escape codes!

Really? How do you think tput changes colors?

$ tput bold | od -An -tx1
 1b 5b 31 6d

qinohe · Today 10:47:33

Of course it does I didn't even realize when I typed it, you're right it's no solution

richardrosa · Today 11:42:16

seth wrote:

ystemd is very much integrated, you're lucky if mixing different versions works at all (the link should™ go to a versioned library and trying to use an older copy fail completely) - the script is probably executed in the initramfs, though and changing anything on the host system (w/o regenerating the initramfs) inert?

That would explain why it works AFTER the boot finishes.
Something MIGHT be messed up in the initrd.
I'll try rebuilding it.

seth wrote:

Still check your pacman.log to see between which two systemd versions you changed.

What I can glean from the log, systemd-libs went from 259.3-1 to 262.1-1 in 4 separate updates.

Thanx again for all your help.

Rich

dimich · Today 12:41:05

richardrosa wrote:

That would explain why it works AFTER the boot finishes.

It works because systemd-ask-password doesn't validate prompt when run on tty but recently started to validate it when asking via an agent. The changes are in /usr/lib/systemd/libsystemd-shared-*.so, not in systemd-ask-password binary.
Link to the commit is in #12.

It's a big question to systemd devs, why they decided to validate prompt inplace rather than let an agent to do it, and why they consider escape sequences "unsafe".

Arch Linux

#1 2026-11-03 12:41:10

Weird issue after full update

#2 2026-11-03 16:27:51

Re: Weird issue after full update

#3 2026-11-03 22:16:08

Re: Weird issue after full update

#4 2026-11-03 22:29:26

Re: Weird issue after full update

#5 Yesterday 09:00:06

Re: Weird issue after full update

#6 Yesterday 12:26:54

Re: Weird issue after full update

#7 Yesterday 12:56:12

Re: Weird issue after full update

#8 Yesterday 19:41:52

Re: Weird issue after full update

#9 Yesterday 19:48:49

Re: Weird issue after full update

#10 Yesterday 20:22:56

Re: Weird issue after full update

#11 Yesterday 20:29:02

Re: Weird issue after full update

#12 Today 01:01:10

Re: Weird issue after full update

#13 Today 08:50:34

Re: Weird issue after full update

#14 Today 09:31:58

Re: Weird issue after full update

#15 Today 10:47:33

Re: Weird issue after full update

#16 Today 11:42:16

Re: Weird issue after full update

#17 Today 12:41:05

Re: Weird issue after full update

Board footer