FS#79619 - [systemd] 20-systemd-sysusers.hook fails to execute on a fresh system
Attached to Project:
Arch Linux
Opened by Markus Zucker (irminsul) - Friday, 08 September 2023, 16:41 GMT
Last edited by Toolybird (Toolybird) - Sunday, 10 September 2023, 09:42 GMT
Opened by Markus Zucker (irminsul) - Friday, 08 September 2023, 16:41 GMT
Last edited by Toolybird (Toolybird) - Sunday, 10 September 2023, 09:42 GMT
|
Details
Description:
When installing a fresh Arch system, `20-systemd-sysusers.hook` fails to initialize `/etc/group`, resulting in a file that only contains the `root` group provided by the `filesystem` package. This leads to tons of follow-up errors as essential system groups such as `udev`, `wheel`, `systemd-journal`, etc. are not present. Here's an excerpt from `pacman.log`: > [ALPM-SCRIPTLET] Initializing machine ID from random generator. > [ALPM-SCRIPTLET] Failed to write /etc/machine-id: Bad file descriptor > ... > [ALPM-SCRIPTLET] Failed to copy permissions from /etc/group to /etc/.#groupe76aefb9d161c4b5: No such file or directory > ... > [ALPM-SCRIPTLET] chgrp: invalid group: ‘systemd-journal-remote’ > ... > [ALPM-SCRIPTLET] /usr/lib/tmpfiles.d/dbus.conf:13: Failed to resolve user 'dbus': No such process > [ALPM-SCRIPTLET] /usr/lib/tmpfiles.d/libutempter.conf:1: Failed to resolve group 'utmp': No such process > [ALPM-SCRIPTLET] /usr/lib/tmpfiles.d/static-nodes-permissions.conf:12: Failed to resolve group 'audio': No such process > [ALPM-SCRIPTLET] /usr/lib/tmpfiles.d/static-nodes-permissions.conf:13: Failed to resolve group 'audio': No such process > [ALPM-SCRIPTLET] /usr/lib/tmpfiles.d/static-nodes-permissions.conf:14: Failed to resolve group 'disk': No such process > [ALPM-SCRIPTLET] /usr/lib/tmpfiles.d/static-nodes-permissions.conf:18: Failed to resolve group 'kvm': No such process > [many more errors like that] Additional info: * systemd (254.2-1) * Full `pacman.log` file from running `pacstrap` is attached. Steps to reproduce: Try to install Arch as per the installation instructions in the wiki. I used archlinux-2023.09.01-x86_64.iso as the installation image. 
pacman.log
(30 KiB)
|
This task depends upon
Closed by Toolybird (Toolybird)
Sunday, 10 September 2023, 09:42 GMT
Reason for closing: Fixed
Additional comments about closing: systemd 254.3-1
Sunday, 10 September 2023, 09:42 GMT
Reason for closing: Fixed
Additional comments about closing: systemd 254.3-1
The problem was not evident yesterday morning, so something must have broken very recently.
However today morning this error apeared.
Edit:
See also [2].
Out of interest what if you apply the attached diff that stops sysusers or tmpfiles from being executed when the system is not booted?
Edit:
Corrected 245.1-1 to 254.1-1.
[1] https://wiki.archlinux.org/title/Bisecting_bugs_with_Git
[2] https://github.com/systemd/systemd/issues/29137
[1] https://github.com/systemd/systemd-stable/commit/8046167dc2d6d7ad62a447991efcd0404d784180
[2] https://github.com/systemd/systemd/issues/29137#issuecomment-1712127340
[1] https://github.com/systemd/systemd/commit/7b9da3861a2d27dd31c360674947005a19f3cbe7
[2] https://github.com/systemd/systemd-stable/pull/320
$ pacman -U https://archive.archlinux.org/packages/s/systemd/systemd-254.1-1-x86_64.pkg.tar.zst
It's 254.1-1 (not 245.1-1).
In my case it ran over the groups creation and failed in bootctl on the chrooted new system.
My analysis points to arch-chroot as root cause:
- It is creating a new PID namespace (using unshare --pid)
- But the /proc mount is copied from the root PID namespace, thus showing wrong processID´s
- starting from system-254.2 it uses /proc/<pid>/fd instead of /proc/self/fd.
It searched for /proc/<pid> using its PID in its (chroot-created) namespace, but does not find it, because /proc refers to the root namespace PIDs , and they differ by design.
- I partially solved it by re-mounting /proc inside the arch-chroot, then it reflects the PID´s of the chroot-created PID namespace.
Hope this helps for analysis, let me know if I help any further.
.
1. I am able to successfully run `systemd-firstboot` without it erroring "Bad file descriptor"
2. I am able to fully run my install script after updating the package inside the chroot, which makes use of systemd-boot, systemd-firstboot and the systemd hooks in mkinitcpio (and anything else a usual install makes use of).