From: Andrej Valek <andrej.valek@siemens.com>
To: Alex Kiernan <alex.kiernan@gmail.com>,
"Denys Vlasenko <vda.linux@googlemail.com>; Chen Qi"
<Qi.Chen@windriver.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: systemd/busybox fsck fail to run
Date: Wed, 5 Sep 2018 14:46:05 +0200 [thread overview]
Message-ID: <4b1aadc2-475b-df41-270c-ffbfbcf086c1@siemens.com> (raw)
In-Reply-To: <CAO5Uq5SjWvxmEXisPRmgM92JaGRHgAdd0qoCsTb=P=1PDzh+fg@mail.gmail.com>
Hi Alex,
There could be multiple options, how to handle this.
My 2cents about this problem:
1. Use update-alternatives to handle this
2. Rework busybox itself to handle this option
3. Just create a patch to ignore this option
Cheers,
Andrej
On 09/05/18 10:37, Alex Kiernan wrote:
> I've just come across a box with a corrupt filesystem which wasn't
> being cleaned (using systemd and busybox):
>
> Aug 29 16:03:22 localhost systemd-fsck[143]: read_bad_blocks_file: No
> such file or directory while trying to open -M
> Aug 29 16:03:22 localhost systemd-fsck[143]: Warning: fsck.ext4
> /dev/mmcblk0p4 terminated by signal 8
> Aug 29 16:03:22 localhost systemd-fsck[143]: fsck failed with exit status 8.
> Aug 29 16:03:22 localhost systemd-fsck[143]: Ignoring error.
> Aug 29 16:03:22 localhost systemd[1]:
> systemd-fsck@dev-mmcblk0p4.service: cgroup is empty
> Aug 29 16:03:22 localhost systemd[1]:
> systemd-fsck@dev-mmcblk0p4.service: Child 143 belongs to
> systemd-fsck@dev-mmcblk0p4.service.
> Aug 29 16:03:22 localhost systemd[1]:
> systemd-fsck@dev-mmcblk0p4.service: Main process exited, code=exited,
> status=0/SUCCESS
> Aug 29 16:03:22 localhost systemd[1]:
> systemd-fsck@dev-mmcblk0p4.service: Changed start -> exited
> Aug 29 16:03:22 localhost systemd[1]:
> systemd-fsck@dev-mmcblk0p4.service: Job
> systemd-fsck@dev-mmcblk0p4.service/start finished, result=done
> Aug 29 16:03:22 localhost systemd[1]: Started File System Check on
> /dev/mmcblk0p4.
>
> It turns out systemd-fsck unconditionally passes `-l` to lock the filesystem:
>
> https://github.com/systemd/systemd/blame/master/src/fsck/fsck.c#L408
>
> which busybox fsck doesn't interpret and so passes on to fsck.ext4,
> which then interprets it as a badblocks file...
>
> What's the right answer here? Add a patch to busybox fsck so it just
> ignores `-l`, or do we need something more sophisticated?
>
> Obviously swapping in util-linux-fsck works around the problem.
>
next prev parent reply other threads:[~2018-09-05 12:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 8:37 systemd/busybox fsck fail to run Alex Kiernan
2018-09-05 12:46 ` Andrej Valek [this message]
2018-09-05 20:25 ` Khem Raj
2018-09-06 8:18 ` Alex Kiernan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b1aadc2-475b-df41-270c-ffbfbcf086c1@siemens.com \
--to=andrej.valek@siemens.com \
--cc=Qi.Chen@windriver.com \
--cc=alex.kiernan@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.