I'm starting to suspect our patch (comment #39) isn't directly to blame for the systemd issue. Disabling or otherwise breaking systemd-fsckd.service doesn't stop fsck output from polluting the console and triggering this bug. Only skipping fsck avoids it. You can skip fsck using 'fastboot' or 'fsck.mode=skip' on the kernel command line.
The fact that fsck prints a useless success message to its stdout is the issue, but it's upstream systemd asking for that:
I'm starting to suspect our patch (comment #39) isn't directly to blame for the systemd issue. Disabling or otherwise breaking systemd- fsckd.service doesn't stop fsck output from polluting the console and triggering this bug. Only skipping fsck avoids it. You can skip fsck using 'fastboot' or 'fsck.mode=skip' on the kernel command line.
The fact that fsck prints a useless success message to its stdout is the issue, but it's upstream systemd asking for that:
https:/ /github. com/systemd/ systemd/ blob/main/ src/fsck/ fsck.c# L336
and there doesn't seem to be any simple fsck parameter to tell it to run more quietly (systemd already uses fsck -T).
I think maybe Red Hat unwittingly works around the problem by starting the Plymouth splash earlier in initrd because they have SimpleDRM enabled.