As mentioned in one of my prior posts, I had a server that kept remounting the hard drive as read-only because of filesystem problems. The problem it was encountering was an aborted journal, which was identified by fairly unambiguous language in the output from ‘dmesg’. The solution, of course was to rebuild the journal.
This post on the solution to fixing an aborted journal saved my bacon. I don’t have much of my own to contribute to the conversation other than to note one of the pitfalls I ran into.
After getting the filesystem unmounted the commands to execute, as noted in the post linked above, are:
fsck -y /dev/volume
tune2fs -O ^has_journal /dev/volume
fsck -f -y /dev/volume
tune2fs -j /dev/volume
Of course, volume here is the volume you need to fix. In my case, this was /dev/VolumeGroup0/lv_root because this machine is set up with lvm and I needed to fix the logical volume named lv_root that is a part of VolumeGroup0.
The pitfall I ran into is that when I looked at the manual entry for fsck, there was no -f option documented. This made me believe it wasn’t implemented on that system. I was wrong. I ran the command without -f and the process completed successfully. Little did I know that because it was lacking the directive to force it, it wasn’t really doing its job and reported a clean drive, even though it was still full of issues. This also seemed to be connected to the following tune2fs command not actually rebuilding the journal like it was supposed to, though it’s possible something else was at play.
2 thoughts on “Repairing an Aborted Ext3 Journal”
Awesome article, thanks! This got me through a nasty problem.
Glad to hear it!