Bug 1015467 - fsck.btrfs not included but used by systemd startup service
fsck.btrfs not included but used by systemd startup service
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Zbigniew Jędrzejewski-Szmek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-04 06:38 EDT by Rudolf Kastl
Modified: 2013-11-24 18:48 EST (History)
11 users (show)

See Also:
Fixed In Version: systemd-208-6.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-24 18:48:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rudolf Kastl 2013-10-04 06:38:27 EDT
Description of problem:
fsck.btrfs not included but used by systemd startup service

Version-Release number of selected component (if applicable):

either fix this package to include the link asked by systemd or change the systemd scripts to call the correct fsck tool: /usr/sbin/btrfsck
Comment 1 Eric Sandeen 2013-10-15 14:54:12 EDT
In this age of journaling filesystems, it's probably best for utilities to just gracefully handle the absence of fsck.$FS - it's simply not needed at boot time, in general.
Comment 2 Zbigniew Jędrzejewski-Szmek 2013-11-11 18:50:31 EST
before you argued that we shouldn't install fsck.btrfs, and use passno=0 by default. But this stopped working with recent changes in systemd, since we assume that /sysroot should be fsck'ed in the dracut unless explicitly disabled, and the same is true for other filesystems mounted later on. In addition, anaconda writes '1 1' for /root.

So I think we could do either of:

1. provide dummy fsck.btrfs
2. stop logging when fsck.<filetype> is missing
3. modify anaconda to write '0 0' instead.
4. do nothing

4 seems unattractive, 3 will not fix every case.

I guess that 2. is easiest... Should we silently ignore all cases where the checker is not found, or embed the knowledge that btrfs and xfs are special in this regard and don't require fsck?

Or do we want to push for 1.?
Comment 3 Kay Sievers 2013-11-11 20:41:55 EST
1. Seems a bit like papering over the real problem, and getting stuck
   in the past :)

2. Sounds fine to me. we could use the existence of the file as an idication
   to run it. a bit like mount(8) calls out to mount.<fstype> and will not
   complain if that's not there

   We could still complain in the real root when we find 1 but no
   checker program?

3. Should be done sure, but it would not solve the dracut problem, will it?

4. Nah :)
Comment 4 Zbigniew Jędrzejewski-Szmek 2013-11-11 20:57:05 EST
OK. Actually, we should complain if we find 1 in initramfs too.
Comment 5 Zbigniew Jędrzejewski-Szmek 2013-11-15 23:27:03 EST
Fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=94192cd: missing /sbin/fsck.btrfs is downgraded to a warning. For btrfs /etc/fstab should not have passno=1.
Comment 6 Fedora Update System 2013-11-19 23:54:21 EST
systemd-208-6.fc20 has been submitted as an update for Fedora 20.
Comment 7 Fedora Update System 2013-11-23 22:33:05 EST
Package systemd-208-6.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-6.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2013-11-24 18:48:33 EST
systemd-208-6.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.