Here's the file content:
d /run/lock/lvm 0700 root root -
d /run/lvm 0700 root root -
This file want opentmpfiles to create them, but it will never happen when lvm is start.
You can see it in an rc.log
OpenRC 0.34.11 is starting up Gentoo Linux (x86_64)
* Setting up tmpfiles.d entries for /dev ... (opentmpfiles-dev start)
[ ok ]
* /run/lvm: creating directory (it's actually device-mapper)
* Starting lvmetad ... (here it's really lvm)
[ ok ]
* Setting up the Logical Volume Manager ...
[ ok ]
* Setting up tmpfiles.d entries ... (opentmpfiles-setup start)
[ ok ]
lvm is run at boot runlevel, and opentmpfiles-setup is also run at boot runlevel, but as you can see, opentmpfiles-setup could be run AFTER lvm.
which mean: if opentmpfiles-setup read the config file and create the directory and file it is ask to create, it will do that AFTER lvm has start ; which is pointless.
And you can see it by running the opentmpfiles commands:
This is command run from opentmpfiles-dev, which is run at sysinit runlevel, so before lvm
tmpfiles --prefix=/dev --create --boot --dry-run --verbose
_c /dev/autofs 0600 0 0 0 10:235
_c /dev/fuse 0600 0 0 0 10:229
... (only creating file for /dev)
And this is the command run from opentmpfiles-setup, that is run after lvm
tmpfiles --exclude-prefix=/dev --create --remove --boot --dry-run --verbose
_d /run/lock/lvm 0700 root root 0 <--- !!!
_d /run/lvm 0700 root root 0 <--- !!!
_d /var/cache/man 0755 man man 1w
_d /run/minidlna 0755 minidlna minidlna 0
_d /var/cache/revdep-rebuild 0700 0 0 0
_d /tmp/screen 0775 root utmp 0
It only works because device-mapper have this, and it is start before lvm:
checkpath -q -d -m 0700 -o root:root /run/lvm /run/lock/lvm
the /usr/lib/tmpfiles.d/lvm2.conf file is then just useless ; but it's a call for bug, because if anyone think it do the job, it does not.
You are probably right for OpenRC world and we can't fix it. If we would depend on tmpfiles-setup service, we would create an impossible depgraph because tmpfiles-setup can't run before fsck but lvm wants to run before fsck...
In systemd world it's a different story and therefore not useless.