systemd/busybox fsck fail to run

[Alex Kiernan <alex.kiernan@gmail.com>]

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