Description of problem: Every boot there is a message " systemd[1]: Failed to load configuration for systemd-fsck-root.service: No such file or directory" Version-Release number of selected component (if applicable): systemd 212-4 How reproducible: Always Steps to Reproduce: 1. Boot Actual results: systemd[1]: Failed to load configuration for systemd-fsck-root.service: No such file or directory Expected results: Seems like it tries to find it, can't find it twice, then later it finds it. systemd[1]: Installed new job systemd-fsck-root.service/start as 117 I'd like to think it can find it right away or something is wrong when it's saying "failed to load" something. Additional info: # systemctl status systemd-fsck-root.service ● systemd-fsck-root.service - File System Check on Root Device Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static) Active: active (exited) since Tue 2014-06-10 11:37:46 MDT; 2min 20s ago Docs: man:systemd-fsck-root.service(8) Process: 341 ExecStart=/usr/lib/systemd/systemd-fsck (code=exited, status=0/SUCCESS) Main PID: 341 (code=exited, status=0/SUCCESS) CGroup: /system.slice/systemd-fsck-root.service Jun 10 11:37:46 localhost.localdomain systemd[341]: Executing: /usr/lib/systemd/systemd-fsck Jun 10 11:37:46 localhost.localdomain systemd-fsck[341]: /dev/sda3: clean, 101662/3276800 files, 1027945/13107200 blocks (check after next mount) Jun 10 11:37:46 localhost.localdomain systemd[1]: Child 341 belongs to systemd-fsck-root.service Jun 10 11:37:46 localhost.localdomain systemd[1]: systemd-fsck-root.service: main process exited, code=exited, status=0/SUCCESS Jun 10 11:37:46 localhost.localdomain systemd[1]: systemd-fsck-root.service changed start -> exited Jun 10 11:37:46 localhost.localdomain systemd[1]: Job systemd-fsck-root.service/start finished, result=done Jun 10 11:37:46 localhost.localdomain systemd[1]: Started File System Check on Root Device. Jun 10 11:37:46 localhost.localdomain systemd[1]: systemd-fsck-root.service: cgroup is empty
Created attachment 907338 [details] journal journalctl -b -l -o short-monotonic includes systemd.log_level=debug and rd.debug
Actually there are a bunch of these same "Failed to load configuration for" messages some of which successfully load later. Why is systemd even trying to load configurations file for them if they don't exist? syslog.service: No such file or directory systemd-readahead-replay.service: No such file or directory systemd-readahead-collect.service: No such file or directory systemd-fsck-root.service: No such file or directory syslog.service: No such file or directory systemd-readahead-replay.service: No such file or directory systemd-readahead-collect.service: No such file or directory systemd-fsck-root.service: No such file or directory syslog.target: No such file or directory ntpd.service: No such file or directory sntp.service: No such file or directory ntpdate.service: No such file or directory gssproxy.service: No such file or directory lvm2-activation.service: No such file or directory lvm2-activation-early.service: No such file or directory systemd-random-seed-load.service: No such file or directory ip6tables.service: No such file or directory iptables.service: No such file or directory sysroot.mount: No such file or directory session-1.scope: No such file or directory
Without looking at the details, it almost certainly is caused by the initramfs not having the systemd-fsck-root.service file. The question is whether it should have it, or not. This bug has the same root cause as #1098799.
Harald, can you comment on this please?
After looking at the sources, I'm quite certain that systemd-fsck-root.service should *not* appear in the initramfs, and should not be required. Can you add 'rd.break' on the kernel commandline, and then check what tries to pull in systemd-fsck-root.service in the initramfs? I think that 'systemctl show systemd-fsck-root.service' should show the dependency as WantedBy/RequiredBy/etc. If this doesn't work, then please do 'grep -r /usr/lib/systemd/system systemd-fsck-root.service; ls -lR /usr/lib/systemd/system | grep -A10 -B10 systemd-fsck-root.service'. This should nail the culprit.
Created attachment 911605 [details] systemctl show systemd-fsck-root.service At rd.break I get a switch_root:/# prompt, and the attached is what I get for the systemd show command. There's nothing wanted or required listed.
# grep -r /usr/lib/systemd/system systemd-fsck-root.service; ls -lR /usr/lib/systemd/system | grep -A10 -B10 systemd-fsck-root.service ExecStart=/usr/lib/systemd/systemd-fsck -rw-r--r--. 1 root root 1235 May 28 04:51 syslog.socket drwxr-xr-x. 1 root root 0 May 28 04:51 syslog.target.wants -rw-r--r--. 1 root root 646 May 28 04:51 systemd-ask-password-console.path -rw-r--r--. 1 root root 657 May 28 04:51 systemd-ask-password-console.service -rw-r--r--. 1 root root 419 May 31 13:38 systemd-ask-password-plymouth.path -rw-r--r--. 1 root root 400 May 31 13:38 systemd-ask-password-plymouth.service -rw-r--r--. 1 root root 574 May 28 04:51 systemd-ask-password-wall.path -rw-r--r--. 1 root root 689 May 28 04:51 systemd-ask-password-wall.service -rw-r--r--. 1 root root 784 May 28 04:51 systemd-backlight@.service -rw-r--r--. 1 root root 1015 May 28 04:51 systemd-binfmt.service -rw-r--r--. 1 root root 683 May 28 04:51 systemd-fsck-root.service -rw-r--r--. 1 root root 682 May 28 04:51 systemd-fsck@.service -rw-r--r--. 1 root root 548 May 28 04:51 systemd-halt.service -rw-r--r--. 1 root root 505 May 28 04:51 systemd-hibernate.service -rw-r--r--. 1 root root 712 May 28 04:51 systemd-hostnamed.service -rw-r--r--. 1 root root 523 May 28 04:51 systemd-hybrid-sleep.service -rw-r--r--. 1 root root 484 May 28 04:51 systemd-initctl.service -rw-r--r--. 1 root root 489 May 28 04:51 systemd-initctl.socket -rw-r--r--. 1 root root 957 May 28 04:51 systemd-journald.service -rw-r--r--. 1 root root 833 May 28 04:51 systemd-journald.socket -rw-r--r--. 1 root root 702 May 28 04:51 systemd-journal-flush.service
OK, I have no idea what is going on. systemd-fsck-root.service *is* there.
But it's there only when sysroot is mounted, right? Initramfs doesn't have it, and it's being initiated before sysroot is mounted.
Ignore comment 7 and 9, I'm an idiot. I did the systemctl command at the dracut prompt, but did the grep command after fully starting up. When I do that at switch_root:/# I get grep: systemd-fsck-root.service: No such file or directory
Created attachment 911635 [details] systemctl show systemdfsckrootservice This one is from rd.break switch_root:/# systemctl show systemd-fsck-root.service
Created attachment 911636 [details] systemctl show systemdfsckrootservice for completed startup This one is from a normal/complete startup. [root@rawhide ~]# systemctl show systemd-fsck-root.service
# lsinitrd initramfs-3.15.0-1.fc21.x86_64.img | grep fsck -rwxr-xr-x 1 root root 316656 Jun 9 21:46 usr/lib/systemd/systemd-fsck -rw-r--r-- 1 root root 682 May 28 04:51 usr/lib/systemd/system/systemd-fsck@.service -rwxr-xr-x 2 root root 0 Jun 9 21:46 usr/sbin/btrfsck -rwxr-xr-x 1 root root 33088 Jun 9 21:46 usr/sbin/fsck For sure systemd-fsck-root.service is not in the initramfs.
OK, now I know what is going on. systemd-fsck@... has After=systemd-fsck-root.service, and this causes an attempt to load systemd-fsck-root.service. But this is logged only at debug level, at least in systemd-214, which is acceptable. So there's really no bug here.
I'll submit a patch which (incidentally) fixes also this wart. systemd-fsck-root.service will be present in the initramfs.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=4dda4e637e