finit trys to fsck rootfs even if it's not a valid fsckable fs

[hongkongkiwi]

In the latest version, finit trys to fsck my rootfs which is squashfs.

Could I suggest that you check if the command fsck.FSTYPE exists and if not just silently ignore this? In my case, my root is a squashfs, but I can also imagine that some users will be using an encrypted dev as their root (or something else with no fsck).

My kernel cmdline shows: root=/dev/mtdblock6

My fstab shows /dev/root as squashfs, but I assume that this is ignored (I saw in other places that actually the /dev/root line is ignored and the kernel cmdline is taken instead).

[ ⋯  ] Checking filesystem /dev/mtdblockfsck: fsck.squashfs: not found
fsck: Error 2 while executing fsck.squashfs for /dev/mtdblock6
[ OK ]
[ ⋯  ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020)
[ OK ]
[ ⋯  ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020)
[ OK ]
[ ⋯  ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020)
[ OK ]
[ ⋯  ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020)
[ OK ]
[ ⋯  ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020)
[ OK ]
[ OK ] Mounting filesystems from /etc/fstab.slot.flash_recovery_rootfs.0

Everything else apart from root is ok.

[troglobit]

Hmmm, that's not right, of course. What does your fstab look like?

Finit (should) skips everything that has pass=0 and generates the rest to the fsck tool to figure out the correct feck.foo to call. Having Finit know all valid types of file systems doesn't feel sustainable really. So setting pass to zero for such entries should be the way here.

You can verify what a Finit reads from your fstab, by enabling debug mode. In case there are any lingering issues with reading wrong passno, for instance.

[hongkongkiwi]

Ah yes, I had fsck set to 1 in my fstab for this rootfs.

After setting it to 0 it seems ok now.

[troglobit]

Phew, thanks! 😁

[hongkongkiwi]

Is it possible to suppress the e2fsck version number? [ ⋯ ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020) [ OK ] [ ⋯ ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020) [ OK ] [ ⋯ ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020) [ OK ] [ ⋯ ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020) [ OK ] [ ⋯ ] Checking filesystem /dev/mmcblk0pe2fsck 1.45.6 (20-Mar-2020) [ OK ] [ OK ] Mounting filesystems from /etc/fstab.slot.flash_recovery_rootfs.0

[troglobit]

Should be, I'll check.

[troglobit]

Are you using configure --enable-fsckfix?

Seems e2fsck always dumps this info on stderr when -p (or the traditional -a) option is not set. The -y option, which --enable-fsck-fix sets, is not compatible with -p.

I'm hesitant to create a special case for fsck, e.g. by redirecting stderr, it uses the same interactive run as most other early setup calls use. The idea of more verbose bootup log is introduced in this release cycle. I was afraid a lot of issues like this would show up ... random useless info printed on the console. In my view this particular issue should be fixed in e2fsprogs, i.e. only show this info in verbose mode. I guess you could have a local patch for this, something like this:

--- output/build/e2fsprogs-1.46.5/e2fsck/unix.c
+++ output/build/e2fsprogs-1.46.5/e2fsck/unix.c
@@ -1461,7 +1461,7 @@ int main (int argc, char *argv[])
        }

        init_resource_track(&ctx->global_rtrack, NULL);
-       if (!(ctx->options & E2F_OPT_PREEN) || show_version_only)
+       if (verbose || show_version_only)
                log_err(ctx, "e2fsck %s (%s)\n", my_ver_string,
                         my_ver_date);

[hongkongkiwi]

Are you using configure --enable-fsckfix?

Yup, I'm using this so it runs: fsck -yf /dev/mmcblk0p10

I'm hesitant to create a special case for fsck, e.g. by redirecting stderr, it uses the same interactive run as most other early setup calls use. The idea of more verbose bootup log is introduced in this release cycle. I was afraid a lot of issues like this would show up ... random useless info printed on the console. In my view this particular issue should be fixed in e2fsprogs

Makes sense. Seems like a patch is the best approach, thank you for the suggestion, I'll add it to my build.