FS#66760 - [systemd] systemd-udevd logs lots of "line takes no effect, ignoring" warnings in the initramfs

Attached to Project: Arch Linux
Opened by Daan De Meyer (DaanDeMeyer) - Saturday, 23 May 2020, 22:31 GMT
Last edited by freswa (frederik) - Thursday, 04 June 2020, 01:18 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Currently, when using systemd as the init in the initramfs, systemd-udevd logs lots of "line takes no effect, ignoring" warnings. After investigating the issue (https://github.com/systemd/systemd/issues/15716), it turns out this happens because we disable systemd-udevd name resolving by adding a drop-in for the systemd-udevd service that adds the --resolve-names=never option (see initcpio-install-systemd in this package). That workaround was initially added to solve https://bugs.archlinux.org/task/49849 so when we remove the drop-in, we get lots of errors from systemd-udevd in the initramfs. The root cause of those errors is that /etc/group only contains the root user in the initramfs and nothing else. To solve the issue, we should add systemd-sysusers, systemd-sysusers.service and (at least) sysusers.d/basic.conf to the initramfs so that systemd fills in /etc/group in the initramfs with the necessary groups to allow systemd-udevd to function correctly. After adding those, the systemd-udevd workaround dropin can be removed.

Steps to reproduce:
- Use systemd mkinitcpio hook
- Rebuild initramfs
- Reboot
- journalctl -e -u systemd-udevd should show lots of "line takes no effect, ignoring" warnings.
This task depends upon

Closed by  freswa (frederik)
Thursday, 04 June 2020, 01:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  245.6-1
Comment by Daan De Meyer (DaanDeMeyer) - Wednesday, 27 May 2020, 16:43 GMT
The systemd developers advised to simply ship a static /etc/group in the initramfs instead of adding systemd-sysusers to the initramfs. If we simply take all the groups from https://github.com/systemd/systemd/blob/master/sysusers.d/basic.conf.in and put those in /etc/group in the initramfs we should be able to drop the udev workaround as well.
Comment by Christian Hesse (eworm) - Monday, 01 June 2020, 21:16 GMT
With systemd 245.6-1 we have static groups in /etc/group, derived from basic.conf. Please have a detailed look and test.
Comment by Daan De Meyer (DaanDeMeyer) - Tuesday, 02 June 2020, 06:39 GMT
That fixes the issue, I see no more warnings. Thanks!
Comment by Eli Schwartz (eschwartz) - Wednesday, 03 June 2020, 14:35 GMT
They definitely don't come from basic.conf, because basic.conf dynamically allocates them. :p

They conflict the UIDs/GIDs documented for a very, very long time in https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database and they also conflict whatever high-level UIDs/GIDs were most likely assigned on users' machines when pacstrapping arch after https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/filesystem&id=20928f58767d34ed6711befd6255f6a0b1706ae8

This probably does not matter, because the initramfs doesn't (shouldn't) share state with the final system, but, it feels a bit silly to be told we need to statically allocate these after systemd told us to stop statically allocating them on the final booted system.

Is there any situation where we care about the UIDs? Perhaps just for consistency, we should be using:

getent passwd root nobody >"$BUILDROOT/etc/passwd" || die "missing users in /etc/passwd"
getent group root tty users video .... >"$BUILDROOT/etc/group" || die "missing groups in /etc/group"

(Also, actually, using getent reduces the lines of code and results in less hardcoded knowledge of the passwd database format, so it's still a win if you ask me.)


...

Systemd honestly doesn't have a good track record for fiddling with UIDs/GIDs. :/  FS#56662   FS#56828   FS#57041   FS#58306  off the top of my head. Why do they keep doing this stuff?

Loading...