Description of problem: On every reboot, journalctl output shows item line ... systemd-fsck[289]: recovering journal An e2fsck -f /dev/sda5 from another OS also shows corrupted journal table. This is serious! Version-Release number of selected component (if applicable): 27 updated to current. This appeared a few weeks ago. How reproducible: Always! Every reboot or shutdown. This is from a custom ext4 kickstart installation. Everything loaded does function. It will show even when Xorg has not been started - console only.
I have removed my custom kickstart system of F27 described before. I replaced it with a completely standard F27 workstation / gnome3 graphical installation. It exhibits the identical flaw described in my unique kickstart arrangement above. In particular, every reboot corrupts the / filesystem. It appears in journalctl output & in my main Linux OS when I run e2fsck on the F27 partition. I have looked at output of tune2fs -l from my main Linux OS after reboot; there were no clues. Something is amiss; on reboot, the / mount is not being properly unmounted. It's reminiscent of an era long ago when one had to kill the power in order to recover from a lockup. The journal had similar entries of lost / orphaned nodes. This is not good & should get prompt attention.
Performed a minimal install scheme to a high speed flash drive. Rebooted that drive repeatedly. Same result as with hard drive (SSD in my case). Every reboot showed a corrupted filesystem.
This may be same as Bug 1533620. I have not tried remedy suggested there in systemd-shutdown script adding line mount -o remount,ro /. Should this not be in the distribution as an update by now? Can anyone else reproduce / verify this?
Please explain what you mean by "corrupted journal table" - there is no such thing as a "journal table" so it's not clear to me what you're seeing. If you're simply seeing a journal replay, that is /not/ corruption.
On every reboot, journalctl output shows item line ... systemd-fsck[289]: recovering journal An e2fsck /dev/sda5 from another OS also shows the same. sda5 holds / for the F27 system. Something is wrong here! (Let's leave out other words, viz., corrupted, dirty, ... that may confuse the reader.)
Well, the words we use need to describe the problem accurately. Corruption has a very specific meaning, and what you are seeing is not corruption. I think that what you are describing is: "The journal replays after every reboot" not "the journal is corrupted after every logout." If so, this bug /is/ a dup of bug #1533620 and it is not a kernel or filesystem bug, it is more likely a systemd bug - the root filesystem is not being cleanly unmounted (or remounted ro) when the system reboots. If this sounds like your problem, let's just dup this bug to #1533620.
Bug #1508984 claims that after updating to systemd-234-10.git5f8984e.fc27 the problem went away. Can you confirm?
I have just installed F28. The same *CORRUPTED* file system error remains on each reboot. e2fsck reports: "Dirty bit is set. FS was not properly unmounted & some data is corrupt." I can not judge if this is same as bug #1533620 since that was xfs vs ext4 that I've used. Proceed as you see fit.
systemd was causing this failure by not cleanly unmounting the root. A couple bugs have been fixed recently, but I don't know about the status of the bug with the systemd in F28. Moving this to systemd so they can disposition it appropriately. (FWIW the error message you quote is from fsck.fat, not e2fsck)
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.