Description of problem:
One of the journal files on my f25 box has become corrupted and jc refuses to open it.
restarting journald opened a new file and continued logging, but the file contents were
Version-Release number of selected component (if applicable):
This occured within 12 hours after cron-yum upgraded to
I looked up the on-disk file format spec and opened the corrupted file in a hex editor,
the field Header.incompatible_flags had the value 2, which is illegal, according to the spec
the only flag currently defined for that field has the value 1. Changing the value of the field
from 2 to 1 made the file readable again.
It seems incredibly unlikely that a random corruption (bits flip, it happens) would be
so surgically precise in rendering an entire file unreadable. This occurred shortly after a systemd
upgrade, but that might be a coincidence. I may also have been hacked, in which case this is a cute,
though not very stealthy, trick.
Putting this here as a notice, just in case similar reports begin to surface which might show this is
more than a freak accident.
This was very likely caused by the new build. The original journal was built against and used lz4 compression, but the new build didn't. Personally, I hate that error message as it is pretty useless, but I'm not sure if it can be easily fixed.
*** This bug has been marked as a duplicate of bug 1404406 ***
Looks right, only if the compression support was left out of the build, how in the hell could
journald read the lz4 compressed hournal file once I flipped the incompatible bit to call it xz compressed? curious.
Either that build was very strange or you have a redundant dep somewhere.
Anyway, that flag was added in 2014:
And the docs at:
were never updated. So it goes.