In new, cssu'ish /etc/event.d/rcS-late, we have checks for home_fsck. User that sets it to 0 assume no forced fsck, ever, while '1' results in fsck -p

Still, just few lines later, same /etc/event.d/rcS-late ignore any user settings, and force fsck -y, in case of failure to properly mount /home

Are you (cssu) perfectly sure, that doing so *before* fixed e2fsprogs get included into CSSU? I must admit - in current state, it won't do any harm to booting, as device with umountable /home is unbootable, anyway. So, it won't either help or hurt booting.

But, even unmountable /home can contain salvageable data, important for user. OTOH, stealthy fsck -y'ing it with segfaulting e2fsprogs on board leave filesystem in unsalvageable mess (unless user instantly boot into things like rescueOS and use working e2fsprogs from there).

Also - for future plans of making fsck default thing on boot (when fixed e2fsprogs make it's way to cssu-t) - it would be good, if /etc/event.d/rcS-late would respect user preferences re fsck'ing even in case of unmountable /home. In case of doubt, it may be good to add another line for /etc/default/mount-opts, something like:
... that would control the (currently) stealthy fsck -y in case of /home mount failure.

/Estel

// Edit

For concerned ones - editing out whole "if to fi"" meant for that fsck -y temporary fixes it, of course.

// Edit 2

Well, there is a (not uncommon) case, where it can turn perfectly fixable (to bootable state) filesystem into total, unusable mess. Ironically, I had such possible situation few days ago.

It's situation when filesystem refuses to mount only because checksum errors - in this case, user can run fsck manually, allow it to fix checksum errors, then answer 'no' for all other "fixing" attempts. In most cases, system will be perfectly bootable, afterwards.

Now, stealthy fsck -y'ing it also fixes checksum errors, but then, makes filesystem FUBAR by attempting other fixes and e2fsprogs segfaulting in the middle.

Good enough reason for hotfix?