* systemd/busybox fsck fail to run
@ 2018-09-05 8:37 Alex Kiernan
2018-09-05 12:46 ` Andrej Valek
0 siblings, 1 reply; 4+ messages in thread
From: Alex Kiernan @ 2018-09-05 8:37 UTC (permalink / raw)
To: openembedded-core, andrej.valek, Chen Qi
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.
--
Alex Kiernan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: systemd/busybox fsck fail to run
2018-09-05 8:37 systemd/busybox fsck fail to run Alex Kiernan
@ 2018-09-05 12:46 ` Andrej Valek
2018-09-05 20:25 ` Khem Raj
0 siblings, 1 reply; 4+ messages in thread
From: Andrej Valek @ 2018-09-05 12:46 UTC (permalink / raw)
To: Alex Kiernan,
Denys Vlasenko <vda.linux@googlemail.com>; Chen Qi,
openembedded-core
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.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: systemd/busybox fsck fail to run
2018-09-05 12:46 ` Andrej Valek
@ 2018-09-05 20:25 ` Khem Raj
2018-09-06 8:18 ` Alex Kiernan
0 siblings, 1 reply; 4+ messages in thread
From: Khem Raj @ 2018-09-05 20:25 UTC (permalink / raw)
To: Andrej Valek, Alex Kiernan,
Denys Vlasenko <vda.linux@googlemail.com>; Chen Qi,
openembedded-core
[-- Attachment #1.1: Type: text/plain, Size: 2273 bytes --]
On 9/5/18 5:46 AM, Andrej Valek wrote:
> 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
>
I am not sure if systemd-fsck is supposed to work with anything other
than util-linux and e2progfs tools. So lets add a hard dependency in
systemd for this.
> 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.
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: systemd/busybox fsck fail to run
2018-09-05 20:25 ` Khem Raj
@ 2018-09-06 8:18 ` Alex Kiernan
0 siblings, 0 replies; 4+ messages in thread
From: Alex Kiernan @ 2018-09-06 8:18 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core
On Wed, Sep 5, 2018 at 9:25 PM Khem Raj <raj.khem@gmail.com> wrote:
>
>
>
> On 9/5/18 5:46 AM, Andrej Valek wrote:
> > 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
> >
>
> I am not sure if systemd-fsck is supposed to work with anything other
> than util-linux and e2progfs tools. So lets add a hard dependency in
> systemd for this.
>
I started prepping this change and then realised why I'm seeing
this... I've been chopping away at image size so am running with
NO_RECOMMENDATIONS in my image recipe and we currently have
util-linux-fsck as a RRECOMMENDS not an RDEPEND, so I end up not
taking it.
But... my feeling is we should probably still make it a hard
dependency as it doesn't seem to me that it meets the definition of
"packages that extends the usability of a package being built".
> > 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.
> >>
>
--
Alex Kiernan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-09-06 8:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-05 8:37 systemd/busybox fsck fail to run Alex Kiernan
2018-09-05 12:46 ` Andrej Valek
2018-09-05 20:25 ` Khem Raj
2018-09-06 8:18 ` Alex Kiernan
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.