Weird issue after full update

richardrosa · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Today 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 · Today 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 · Today 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 · Today 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 · Today 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 · Today 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 · Today 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.

Arch Linux

#1 Yesterday 12:41:10

Weird issue after full update

#2 Yesterday 16:27:51

Re: Weird issue after full update

#3 Yesterday 22:16:08

Re: Weird issue after full update

#4 Yesterday 22:29:26

Re: Weird issue after full update

#5 Today 09:00:06

Re: Weird issue after full update

#6 Today 12:26:54

Re: Weird issue after full update

#7 Today 12:56:12

Re: Weird issue after full update

#8 Today 19:41:52

Re: Weird issue after full update

#9 Today 19:48:49

Re: Weird issue after full update

#10 Today 20:22:56

Re: Weird issue after full update

#11 Today 20:29:02

Re: Weird issue after full update

Board footer