Description of problem: I have gone from Fedora21->22->23 The system has installed a file /usr/lib/tmpfiles.d/lirc.conf but has not created the user lirc this then make systemd-tmpfiles-setup.service to exit with a failed condition. In my version Fedora21 lirc was not installed. The update was done following these basic steps rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-$(uname -i) yum update yum yum clean all yum --releasever=22 distro-sync rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-$(uname -i) dnf upgrade dnf clean all dnf --releasever=23 --setopt=deltarpm=false distro-sync Version-Release number of selected component (if applicable): How reproducible: I expect it should be Steps to Reproduce: 1. have a system with Fedora 21 with lirc installed 2. follow the released procedure 3. watch the boot log. Actual results: Error message in booting sequence in systemctl status for systemd-tmpfiles-setup.service Expected results: No error in bootup Additional info: Expected solution is either to not install the lirc.conf or create the required user lirc correctly.
Ack, this is fixed in f23 but has not been backported to f22 (the lirc installation requires the lirc user to exist). The question is just if this justifies pushing a fix for f22. It seems unlikely that such a fix would actually solve any problem - you are the first one reporting this. My gut feeling is that this should be postponed to the f23 update, but I might certainly be wrong. For the record: the culprit is the "%pre" snippet which should be "%pre core" Thoughts?
Thanks for the update. I personally am happy if you can advise me the password/group file entries I should add to make it happy. Based on what you said what has probably happened to me is the fact that because I went from F21->22->23 straight. I did do a dnf update between F22 and F23 but it could easily be that it might not have implemented the required patch/update which you mention and thus I have an error. This is a one off event so a one off fix sounds fine to me. Maybe the create the user if non existent can be added to F23 (as a safety). I certainly would not spend a great deal on it.
Here is the specfile snippet to run manually: getent group lirc >/dev/null || groupadd -r lirc getent passwd lirc >/dev/null || \ useradd -r -g lirc -d /var/log/lirc -s /sbin/nologin \ -c "LIRC daemon user, runs lircd." lirc usermod -a -G dialout lirc &> /dev/null || : usermod -a -G lock lirc &> /dev/null || : usermod -a -G input lirc &> /dev/null || : Thanks for reporting. For now, leaving bug open for others to find.
I can confirm that the snippet supplied has added the required user etc and the display error is now gone. This will fix this problem. I am happy with the result. I will allow others to adjust the status etc on this bug when appropriate.
I am quite sure the update in fact worked correctly. After further examination I noted that I have a password/user update task that syncs data between machines. I am almost positive that it will have over written the updated client details with old server information before the update got to the server machine and correctly did that one also. Thus no actual bug but the snippet fixed the problem of my own making it looks like. Thanks again for the help etc.
OK, let's close this one... thanks for reporting and continued feedback!