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 still unavailable. Version-Release number of selected component (if applicable): This occured within 12 hours after cron-yum upgraded to systemd.x86_64 231-11.fc25 Additional info: 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 at https://www.freedesktop.org/wiki/Software/systemd/journal-files/ 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: https://github.com/systemd/systemd/commit/d89c8fdf48c7bad5816b9f2e77e8361721f22517 And the docs at: https://www.freedesktop.org/wiki/Software/systemd/journal-files/ were never updated. So it goes.