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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
