run0, mkinitcpio and zstd error

ForUmIx · 2024-08-10 07:53:23

Hello.

I get an error when creating an initial ramdisk environment.

$ run0 --background=
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: username
Password:
==== AUTHENTICATION COMPLETE ====

[ /home/username ] # mkinitcpio -p linux-lts
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts.img
==> Starting build: '6.6.44-3-lts'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
zstd: error 70 : Write error : cannot write block : Broken pipe
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-lts.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful

This error occurs only when using `run0` to run commands as root.
There are no errors when using `doas`.

That said...

$ run0 --background=
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: username
Password:
==== AUTHENTICATION COMPLETE ====

[ /home/username ] # pacman -S linux-lts
warning: linux-lts-6.6.44-3 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)     Old Version  New Version  Net Change  Download Size

core/linux-lts  6.6.44-3     6.6.44-3       0.00 MiB     128.30 MiB

Total Download Size:   128.30 MiB
Total Installed Size:  128.54 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...
...
...
==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts.img
==> Starting build: '6.6.44-3-lts'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-lts.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful

No errors in this case either.

In all cases, the system boots and runs normally, but I would like to understand the cause of the error.

seth · 2024-08-10 09:26:49

Contrary to the media-buzz, https://man.archlinux.org/man/core/systemd/run0.1.en is NOT a sudo alternative or privilege escalation tool but a shorthand for https://man.archlinux.org/man/core/syst … d-run.1.en that implicitly uses polkit for privilege escalation w/ the implications of any context isolation and possibly resource limitations.

In this case it seems to conflict w/ some zstd call in the kms hook, resulting in a broken pipe error (edit: via ECOMM)
You could trace https://gitlab.archlinux.org/archlinux/ … e=heads#L4 by wrapping the function in "set -x" … "set +x" to look at the actual call

Last edited by seth (2024-08-10 09:28:11)

ForUmIx · 2024-08-10 09:52:32

Thanks for the quick response, seth.

seth · 2024-08-10 17:14:12

If you've a trace but don't know what to make of it, feel free to post it.
We resp. the mkinitcpio maintainer might wanna look there (could be some implicit assumption) but I'm not excited about enablign kms for testing purposes (and would likely run out of space on the /boot partition

ForUmIx · 2024-08-10 19:36:39

I had an assumption that there was something wrong with the permissions here I had set for /boot and /efi to block public reading. But now I've reset everything back to default and zstd error is still here. The only thing that confuses me is the different permissions for /boot/vmlinuz-linux-lts and /boot/initramfs-linux-lts.img even with the default settings.

# stat /boot/vmlinuz-linux-lts | grep Access
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

# stat /boot/initramfs-linux-lts.img  | grep Access
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)

Is this normal?

$ doas -s
# umask
0022

$ run0
# umask
0022

seth · 2024-08-10 19:53:13

The permission difference is normal - that doesn't indicate anything (and I can't find any way to actually configure them)
I also don't think the ECOMM is any kind of permission error - did you trace the hook?

ForUmIx · 2024-08-10 21:58:15

Yes. It's a very big log. The thing about the error:

++ read -r -d '' mod
++ decomp_to_stdout /lib/modules/6.6.44-3-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst
++ grep -Eq '^(drm_privacy_screen_register)'
++ case "$1" in
++ zstd -q -d /lib/modules/6.6.44-3-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c
zstd: error 70 : Write error : cannot write block : Broken pipe.
+++ ((  70  ))
+++ [[ decomp_to_stdout == add_* ]]
++ mod=thinkpad_acpi.ko.zst
++ mod=thinkpad_acpi
++ printf '%s\n' thinkpad_acpi

seth · 2024-08-11 09:01:45

So it can't writ eto sdtout, but this seems odd - vim /tmp/foo and then

#!/usr/bin/env bash
zstd -q -d /lib/modules/6.6.44-3-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c | grep -Eq '^(drm_privacy_screen_register)' &> /dev/null

chmod +x /tmp/foo
/tmp/foo
systemd-run /tmp/foo
run0 /tmp/foo

ForUmIx · 2024-08-11 10:35:24

$ /tmp/zstd-error

$ systemd-run /tmp/zstd-error
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
...
==== AUTHENTICATION COMPLETE ====
Running as unit: run-u52.service; invocation ID: f71636ae984044918640b6fc80988e22

$ run0 /tmp/zstd-error
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
...
==== AUTHENTICATION COMPLETE ====
zstd: error 70 : Write error : cannot write block : Broken pipe

seth · 2024-08-11 14:17:48

Breaks the pipe - somehow

grep -Eq '^(drm_privacy_screen_register)' < <(zstd -q -d /lib/modules/6.6.44-3-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c)  &> /dev/null

Interestingly

(sleep 5; echo foo) | grep -Eq '^(drm_privacy_screen_register)' &>/dev/null

works, I suspect it's related to the binary output of zstd

ForUmIx · 2024-08-11 18:19:17

grep -Eq '^(drm_privacy_screen_register)' < <(zstd -q -d /lib/modules/6.6.44-3-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c)  &> /dev/null

The same error after run0.

(sleep 5; echo foo) | grep -Eq '^(drm_privacy_screen_register)' &>/dev/null

Empty output after run0.
Edit: not empty.
error code: 1

Last edited by ForUmIx (2024-08-11 18:23:05)

seth · 2024-08-11 19:36:49

I'm could have sworn I didn't get that, but do now - maybe I messed up b/c the first test I ran was simply

grep -Eq '^(drm_privacy_screen_register)' < <(zstd -q -d /lib/modules/6.1.26-1-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c)

and that does work - it seems the stderr redirection cause trouble as well - but then

grep -Eq '^(drm_privacy_screen_register)' < <(zstd -q -d /lib/modules/6.1.26-1-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c) > /dev/null

grep -Eq '^(drm_privacy_screen_register)' < <(zstd -q -d /lib/modules/6.1.26-1-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c) 2> /dev/null

Both seem to work. Then not.
Then

grep -Eq '^(drm_privacy_screen_register)' < <(zstd -q -d /lib/modules/6.1.26-1-lts/kernel/drivers/platform/x86/thinkpad_acpi.ko.zst -c) 2> /dev/null 1>&2

worked. Then not.

systemd at work…

ForUmIx · 2024-08-11 21:49:45

Unfortunately, I have the same zstd error in all four variants. Why is the error getting only with thinkpad_acpi.ko.zst?

 zstd -q -d /usr/lib/modules/6.6.44-3-lts/kernel/drivers/platform/x86/ideapad-laptop.ko.zst -c | grep -Eq '^(drm_privacy_screen_register)' &> /dev/null

No errors.

seth · 2024-08-11 22:13:51

Previously I would have said the binary output but meanwhile I think it's maybe a race condition because of the seemingly incosistent behavior (or I'm going slightly mad)
run0 initially had issues w/ leaking file descriptors of the UID0 PID into the unprivileged context, maybe they just hacked around that?

thnkpad_acpi is ~5x the size of ideapad-laptop

ForUmIx · 2024-08-12 07:22:01

A few years ago, I and other users had Xorg fail to start after updating systemd. And it was a race condition.
I downgraded systemd, systemd-libs and systemd-sysvcompat version to 256-1 but that didn't help.
Arch Linux must reject systemd in favor of other alternatives.

Arch Linux

#1 2024-08-10 07:53:23

run0, mkinitcpio and zstd error

#2 2024-08-10 09:26:49

Re: run0, mkinitcpio and zstd error

#3 2024-08-10 09:52:32

Re: run0, mkinitcpio and zstd error

#4 2024-08-10 17:14:12

Re: run0, mkinitcpio and zstd error

#5 2024-08-10 19:36:39

Re: run0, mkinitcpio and zstd error

#6 2024-08-10 19:53:13

Re: run0, mkinitcpio and zstd error

#7 2024-08-10 21:58:15

Re: run0, mkinitcpio and zstd error

#8 2024-08-11 09:01:45

Re: run0, mkinitcpio and zstd error

#9 2024-08-11 10:35:24

Re: run0, mkinitcpio and zstd error

#10 2024-08-11 14:17:48

Re: run0, mkinitcpio and zstd error

#11 2024-08-11 18:19:17

Re: run0, mkinitcpio and zstd error

#12 2024-08-11 19:36:49

Re: run0, mkinitcpio and zstd error

#13 2024-08-11 21:49:45

Re: run0, mkinitcpio and zstd error

#14 2024-08-11 22:13:51

Re: run0, mkinitcpio and zstd error

#15 2024-08-12 07:22:01

Re: run0, mkinitcpio and zstd error

Board footer