On Monday, 14 December 2020 06:07:40 GMT thelma@sys-concept.com wrote:
> On 12/13/2020 06:33 AM, Victor Ivanov wrote:
> [snip]
> 
> > Out of curiosity, do you have the "sys-fs/dosfstools" package installed?
> > 
> > This is the package that provides the fsck.fat binary. It's not a
> > dependency of commonly installed system packages so unless you install
> > it manually it's probably missing which might explain why fsck is
> > exiting with an error code.
> > 
> > - Victor
> 
> Yes, I had this packaged installed, but it did not help. I got hit by
> this bug.  I'm surprised that it hasn't been discovered earlier.

We don't know for sure this was either a fsck bug, or a corrupt ESP vfat fs.  
We know some kernel couldn't complete its booting process.  There could be 
many other extraneous reasons for it, like missing kernel drivers, missing 
firmware, incomplete initramfs (if one was being used at the time).

There's a difference between troubleshooting a problem patiently until the 
root cause is established and resolved, Vs trying different things as fast as 
possible to boot a system.  Reverting to old(er) working paradigms, e.g. 
legacy BIOS and /boot with ext2 fs is not a solution to the original problem, 
proof of a bug with fsck, proof of a corrupt VFAT, or unsuitability of using 
an ESP.  However, it soon got the PC booting again, so at least it satisfied 
that objective (booting, sooner).  :-)