init: fsck: wait for devices and unhide messages

[mglae]

I was wondering why the file system corruption found in #3804 was not visible in the boot logs on my generic systems.

Recovery was done as part of the fsck operation but the output redirected to /dev/null. Make the messages visible in dmesg, i.e.:

[    6.322266] Checking disk(s):  UUID=0703-3126 UUID=7858ca35-a758-4559-8079-a51ce61415fc

[    8.353237] fsck: CP437: Invalid argument
[    8.353237] fsck: fsck.fat 3.0.28 (2015-05-16)
[    8.353237] fsck: /dev/sdb1: 49 files, 29041/65501 clusters
[    8.353237] fsck: /dev/sdb2: clean, 11586/3735552 files, 1395995/14935040 blocks

The Invalid parameter error is an issue with dosfstools and may be fixed by updating to master HEAD with internal CP850 code page (not tested, just a guess).

Second change is to wait up to 10 seconds for slow devices like USB sticks to appear in the system. I'm afraid that RPI SD cards do need this delay too and have not been checked before. All tries are logged to /dev/fsck.log

[MilhouseVH]

Thanks for this - it should be useful.

Couple of questions:

1. isn't it a little troubling that we run /usr/sbin/fsck on multiple filesystems, potentially multiple times, and if we have a problem with one filesystem we force a fsck on all filesystems? Would it be better to check filesystems individually/sequentially, force checking only the filesystem with errors?

2. Our version of dosfstools is pretty ancient, can you think of a reason we haven't bumped it...? Although that would be best done in a separate PR (edit: see dosfstools/e2fsprogs: update to latest #3858).

[mglae]

1. In init fsck is only run on /flash and /storage (if they are local devices). I expect not automatic to recoverable fs errors only to appear in the large /storage partition. IMO the additional forced checking of /flash is not worth more code complexity.

2. Overlooked! :-) Just noticed you bumped it - thanks. But 4.1 from Jan 2017 does not include the IMO needed commits 76c0362 and d74c592 for CP850.

[MilhouseVH]

1. OK, thanks.

2. I looked at the CP850 patches, and they're not entirely trivial (nor do they apply cleanly on top of 4.1). Those 2 commits come from two larger PRs (adding codepage support and making building with iconv optional) so cherry-picking just the 2 commits might not be a good idea. Also, given it's just a cosmetic issue that almost nobody should ever see, I'd rather wait for 4.2 to be released with the CP850 fixes (although given the rate of dosfstools releases, that could be a while...)