File corruption detected upon running journalctl --verify

i have been noticing abnormal boot times and weird behaviour of systemd-journal-flush.service, i ran journalctl --verify and noted the following output

17cdd08: Data object's entry array not sorted                                                                                                           
File corruption detected at /var/log/journal/e17805972b2e4b21a44aef95fabaff95/system@31a91fa223424921a7d00be2eb10f1f2-0000000000000001-0005c6379f9119e0.journal:265f518 (of 41943040 bytes, 95%).

FAIL: /var/log/journal/e17805972b2e4b21a44aef95fabaff95/system@31a91fa223424921a7d00be2eb10f1f2-0000000000000001-0005c6379f9119e0.journal (Bad message)

PASS: /var/log/journal/e17805972b2e4b21a44aef95fabaff95/system.journal           
                                                                       
PASS: /var/log/journal/e17805972b2e4b21a44aef95fabaff95/user-1000@360761ea52db434e97fa4f2b117b6024-000000000000186f-0005c6331aba8bc1.journal       
     
PASS: /var/log/journal/e17805972b2e4b21a44aef95fabaff95/user-1000.journal `

This is not fine, anything i can do to fix this?

[I could be wrong but here are my opinions]

Apparently this is a pretty famous issue. There are open issues about this that hasn’t resolved yet. After reading many community discussions. I think it is common to have such a type of output unless one has ECC memory. (No, “common” doesn’t it’s okay.)

Usually, people either ignore it or delete the corrupted journal/coredump log. But there are some workaround like changing the default values of coredump.conf and journald.conf files which are inside /etc/systemd directory which has worked for some people.