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
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
|
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
Thursday, 04 June 2020, 01:18 GMT
Reason for closing: Fixed
Additional comments about closing: 245.6-1
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#56662FS#56828FS#57041FS#58306off the top of my head. Why do they keep doing this stuff?