JFS root FS mounted read-only on battery power after unclean umount

[Augusto Santos]

If a JFS FS is ever unmounted unclearly, the filesystem needs to be checked. If the FS is mounted without a fsck, the FS will be read only. The effect is that if an install with a JFS root FS ever crashes, looses power, or otherwise shuts down uncleanly and the system is then booted up without AC power, the system will silently and without warning mount the root FS read only and fail to start a variety of applications, most notably GDM. If a user does not know how to fsck their root by hand, the system will become unusable until the system is booted with AC power present.

A fsck on JFS takes well under a minute to run so concerns about battery power are less important than they might be in ext3. I see no reason to have the checkroot.sh script always run the fsck if the system is JFS. This will address fix this issue for JFS laptop users.

To reproduce the bug: (1) unmount JFS root FS uncleanly; (2) boot system without AC power.

[neilyalowitz (neilyalowitz)]

I found this on a search, and I think my bug may be related. File system boots read-only (MOST of the time) or is switched to read-only after one minute.

https://bugs.launchpad.net/ubuntu/+bug/366867

This started occurring immediately after updating to Jaunty (the official release). Why would a filesystem suddenly boot read-only?

VERY disappointing to see there has been no action on your bug, since my bug may be related. It has made my machine useless. I have quite a few nasty things to say about Ubuntu at the moment, because this is not my first disappointment with an upgrade, but I will hold my words.

[Augusto Santos (mkhaos7)]

Well, actually i MIGHT have found the solution of this problem, or better, the cause.
On my system suspend/resume doesn't work, so some times I try to see if this is fixed and, when resuming, the system hangs, and the only solution is a hard reboot.
When doing that the filesystem is dirty and hence need to be fscked. The problem is that sometimes I turn up the machine of the mains, and so fsck is not being executed (which I think is pretty silly).
When the filesystem is dirty jfs refueses to mount the filesystem as r/w and mounts it only as r/o.

The solution, for me, is to run fsck on the readonly root and then reboot the system.
Last time this happened this solved the problem.

But I'll leave this bug open because fsck should be run even when on batteries.
Hope this helps your problem.

[Benjamin Mako Hill (mako)]

This bug is not actually a duplicate of #219382.

#219382 is a generic bug about filesystem checks on boot based on on_ac_power. This bug is about behavior in relation to JFS which should be handled separately.

If a JFS FS is ever unmounted unclearly, the filesystem needs to be checked. If the FS is mounted without a fsck, the FS will be read only. The effect is that if an install with a JFS root FS ever crashes, looses power, or otherwise shuts down uncleanly and the system is then booted up without AC power, the system will silently and without warning mount the root FS read only and fail to start a variety of applications, most notably GDM. If a user does not know how to fsck their root by hand, the system will become unusable until the system is booted with AC power present.

A fsck on JFS takes well under a minute to run so concerns about battery power are less important than they might be in ext3. I see no reason to have the checkroot.sh script always run the fsck if the system is JFS. This will address fix this issue for JFS laptop users.

I've included a patch that does this. It may not be the right place (I don't know the codebase well) but it fixes the issue and should explain roughly what needs to happen

[Benjamin Mako Hill (mako)]

I've left the importance undecided for someone more familiar with the package to set. The bug itself is a major problem for anyone running JFS on a laptop. That said, I suspect that the number of users in such configurations is very small and that most of them know enough to get them out of the trouble that this bug gets them into.

[Clint Byrum (clint-fewbar)]

I don't believe 9.10 and later have this script, as mountall decides when to run fsck on the root filesystem. With Hardy's desktop support ending in less than 6 months, I'd rather not have peoples' limited time spent testing this fix to Hardy, so closing as Won't Fix.