Bug 88491

Summary: RFE: udev should default to --resolve-names=never if in_initrd() returns true
Product: systemd Reporter: Alain Kalker <a.c.kalker>
Component: generalAssignee: systemd-bugs
Status: NEW --- QA Contact: systemd-bugs
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Alain Kalker 2015-01-16 11:38:03 UTC
Using Arch Linux x86_64, mkinitcpio `systemd` hook changed to not install /etc/{passwd,group} and some supporting files into initrd, systemd-udevd logs the following errors (priority=3) to journal on boot:

$ journalctl -b -p3
-- Logs begin at Fri 2015-01-16 11:20:13 UTC, end at Fri 2015-01-16 11:20:20 UTC
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'tty' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'uucp' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'kmem' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'input' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'video' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'audio' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'lp' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'disk' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'optical' unknown
Jan 16 11:20:13 localhost systemd-udevd[49]: specified group 'storage' unknown

Related CoreOS issue: Normal boot on a vagrant vbox machine produces 26 critical[sic] error entries in journal · Issue #70 · coreos/bugs : https://github.com/coreos/bugs/issues/70

`man systemd-udevd` shows that it supports the `--resolve-names` option, which I suppose is meant to deal with situations like this.
From some digging, I found the following commit in systemd Git:

---[cut here]---
commit 5f03ed8a56d308af72db8a48ab66ed68667af2c6
Author: Scott James Remnant <scott@ubuntu.com>
Date:   Tue Jan 20 21:33:02 2009 +0000

    Allow user and group lookup to be disabled.
    
    In certain cut-down situations such as an installer or inside the
    initramfs, we simply don't have any kind of name service.  While we
    could use rules without OWNER or GROUP, it's better to have the same
    rules as a full system and have udevd ignore those parts of the rules.
    
    Adds a --resolve-names=never switch to udevd that has this effect.
---[cut here]---

This appears to confirm my assumption.

This option doesn't appear to be used in any of the units shipped with systemd, perhaps it is an idea to create a variant of `systemd-udevd.service` (perhaps named `systemd-udevd-initrd.service`) with this particular setting for use in the initrd.
Comment 1 Alain Kalker 2015-01-16 11:43:26 UTC
Link to the mentioned commit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=5f03ed8a56d308af72db8a48ab66ed68667af2c6
Comment 2 Alain Kalker 2015-01-16 17:58:43 UTC
A workaround (maybe even a permanent solution) is the following:

- Don't include /etc/{passwd,group} or supporting files in the initrd
- Arrange for the following drop-in snipped to be included *in the initrd*:

--[File: /etc/systemd/system/systemd-udevd.service.d/50-resolve-names-never.conf]--
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-udevd --resolve-names=never
--[End of file]--

Testing this on my system, there were no more unknown group errors in the journal, and after the system was fully booted, all devices do have the right ownership and permissions (which I assume are set aftter udev initializes on the real rootfs).
Comment 3 Lennart Poettering 2015-02-04 18:46:27 UTC
I figure systemd-udevd should default to --resolve-names=never when run in an initrd (i.e. in_initrd() returns true). Would be happy to take a patch for this.
Comment 4 Alain Kalker 2015-04-26 14:00:20 UTC
I have tried (unsuccessfully) one other alternative: add /usr/lib/systemd/system/systemd-sysusers.service and /usr/lib/sysusers.d/basic.conf to the initrd.
The dependency ordering suggests that this could work: systemd-udevd.service contains an After= directive which includes systemd-sysusers.service.

However, when I boot this setup in a VM (with an added `ExecStartPre=/usr/bin/sleep 5` added to systemd-udevd.service via a drop-in for debugging purposes), I get the following in the journal:

[..snip..]
Apr 26 15:30:01 localhost systemd[1]: Starting Create System Users...
Apr 26 15:30:01 localhost systemd[1]: Started Create list of required static device nodes for the current kernel.
Apr 26 15:30:01 localhost systemd[1]: Started udev Coldplug all Devices.
Apr 26 15:30:01 localhost systemd-journal[45]: Journal started
Apr 26 15:30:01 localhost systemd[1]: Started Journal Service.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group optical with gid 999.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group utmp with gid 998.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group adm with gid 997.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group users with gid 996.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group input with gid 995.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group audio with gid 994.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group disk with gid 993.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group wheel with gid 992.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group lock with gid 991.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group kmem with gid 990.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group uucp with gid 989.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group lp with gid 988.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group storage with gid 987.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group video with gid 986.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group tty with gid 5.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group root with gid 0.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating user root (Super User) with uid 0 and gid 0.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating group nobody with gid 65534.
Apr 26 15:30:01 localhost systemd-sysusers[48]: Creating user nobody (Nobody) with uid 65534 and gid 65534.
Apr 26 15:30:01 localhost systemd[1]: Started Create System Users.
Apr 26 15:30:01 localhost systemd[1]: Starting Create Static Device Nodes in /dev...
Apr 26 15:30:01 localhost systemd[1]: Started Create Static Device Nodes in /dev.
Apr 26 15:30:01 localhost systemd[1]: Starting udev Kernel Device Manager...
Apr 26 15:30:02 localhost kernel: tsc: Refined TSC clocksource calibration: 3600.029 MHz
Apr 26 15:30:06 localhost systemd-udevd[60]: starting version 219
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'tty' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'uucp' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'kmem' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'input' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'video' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'audio' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'lp' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'disk' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'optical' unknown
Apr 26 15:30:06 localhost systemd-udevd[60]: specified group 'storage' unknown
[..snip..]

As is clear from the timestamps, systemd-udevd cannot determine the groups even though they have been created just 5 seconds ago.

The initrd does contain the required /etc/{group,password,...} at the end of the early boot stage, so I don't know why systemd-udevd is failing here. Journal output from yet another drop-in tacked onto initrd-cleanup.service:

Apr 26 15:30:06 localhost systemd[1]: Starting Initrd Default Target.
Apr 26 15:30:06 localhost systemd[1]: Starting Cleaning Up and Shutting Down Daemons...
Apr 26 15:30:06 localhost ls[96]: /etc:
Apr 26 15:30:06 localhost ls[96]: drwxr-xr-x    4 0        0                0 Apr 26 13:30 .
Apr 26 15:30:06 localhost ls[96]: drwxr-xr-x   12 0        0                0 Apr 26 13:30 ..
Apr 26 15:30:06 localhost ls[96]: -rw-------    1 0        0                0 Apr 26 13:30 .pwd.lock
Apr 26 15:30:06 localhost ls[96]: -rw-r--r--    1 0        0                0 Apr 26 13:29 fstab
Apr 26 15:30:06 localhost ls[96]: -rw-r--r--    1 0        0              211 Apr 26 13:30 group
Apr 26 15:30:06 localhost ls[96]: ----------    1 0        0              179 Apr 26 13:30 gshadow
Apr 26 15:30:06 localhost ls[96]: -rw-r--r--    1 0        0                0 Apr 26 13:29 initrd-release
Apr 26 15:30:06 localhost ls[96]: -rw-r--r--    1 0        0             1739 Apr 26 13:29 ld.so.cache
Apr 26 15:30:06 localhost ls[96]: -rw-r--r--    1 0        0                0 Apr 26 13:29 ld.so.conf
Apr 26 15:30:06 localhost ls[96]: -r--r--r--    1 0        0               33 Apr 26 13:30 machine-id
Apr 26 15:30:06 localhost ls[96]: drwxr-xr-x    2 0        0                0 Apr 26 13:29 modprobe.d
Apr 26 15:30:06 localhost ls[96]: lrwxrwxrwx    1 0        0               17 Apr 26 13:29 mtab -> /proc/self/mounts
Apr 26 15:30:06 localhost ls[96]: -rw-r--r--    1 0        0               80 Apr 26 13:30 passwd
Apr 26 15:30:06 localhost ls[96]: ----------    1 0        0               42 Apr 26 13:30 shadow
[..snip..]
Apr 26 15:30:06 localhost grep[99]: /etc/passwd:root:x:0:0:Super User:/root:/bin/sh
Apr 26 15:30:06 localhost grep[99]: /etc/passwd:nobody:x:65534:65534:Nobody:/:/sbin/nologin
Apr 26 15:30:06 localhost grep[99]: /etc/group:input:x:995:
Apr 26 15:30:06 localhost grep[99]: /etc/group:uucp:x:989:
Apr 26 15:30:06 localhost grep[99]: /etc/group:storage:x:987:
Apr 26 15:30:06 localhost grep[99]: /etc/group:tty:x:5:
Apr 26 15:30:06 localhost grep[99]: /etc/group:wheel:x:992:
Apr 26 15:30:06 localhost grep[99]: /etc/group:kmem:x:990:
Apr 26 15:30:06 localhost grep[99]: /etc/group:nobody:x:65534:
Apr 26 15:30:06 localhost grep[99]: /etc/group:lp:x:988:
Apr 26 15:30:06 localhost grep[99]: /etc/group:users:x:996:
Apr 26 15:30:06 localhost grep[99]: /etc/group:optical:x:999:
Apr 26 15:30:06 localhost grep[99]: /etc/group:adm:x:997:
Apr 26 15:30:06 localhost grep[99]: /etc/group:utmp:x:998:
Apr 26 15:30:06 localhost grep[99]: /etc/group:audio:x:994:
Apr 26 15:30:06 localhost grep[99]: /etc/group:lock:x:991:
Apr 26 15:30:06 localhost grep[99]: /etc/group:video:x:986:
Apr 26 15:30:06 localhost grep[99]: /etc/group:root:x:0:
Apr 26 15:30:06 localhost grep[99]: /etc/group:disk:x:993:

Any idea why this isn't working?

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.