Bug 1107818
Summary: | initrd: Failed to load configuration for systemd-fsck-root.service | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||
Component: | systemd | Assignee: | systemd-maint | ||||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | rawhide | CC: | bugzilla, hhoyer, johannbg, lnykryn, msekleta, s, systemd-maint, vpavlin, zbyszek | ||||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | systemd-220-1.fc23 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2015-06-10 17:05:22 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Chris Murphy
2014-06-10 17:41:58 UTC
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. |