Red Hat Bugzilla – Bug 125706
can't make root volume read-write again
Last modified: 2007-11-30 17:10:44 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: I have a flaky box that has been crashing at random, due to unknown problems (not memory). Today, when I tried to log into it, I found out its root filesystem, mounted off a logical volume, was read-only. Some filesystem error that failed to make it to /var/log/messages because it was read only :-(, I thought. Anyhow... I tried to remount it read-write, and it said the logical volume was read-only. So I tried vgscan, vgchange -ay VG0, and they failed because they couldn't create the lock files. Adding --ignorelockingfailure worked around this problem, and the volume group was fine. So I figured the logical volume might have become unavailable or read-only. lvchange -ay --ignorelockingfailure works, but lvchange -prw --ignorelockingfailure says the latter can only be used for -a. I was stuck. Too bad I forced a reboot before realizing I could have simply used separate storage for the lock files et al. The box didn't come back. Probably filesystem corruption :-( Version-Release number of selected component (if applicable): lvm2-2.00.15-2 How reproducible: Couldn't Reproduce Steps to Reproduce: 1.Get the logical volume holding the root filesystem into a read-only state 2.Try to make it read-write again Actual Results: Without additional storage, can't be done Expected Results: I'd hope lvchange could accept --ignorelockingfailure to do so. Additional info:
The logical volume can't change from read-write to read-only on its own as far as I know. lvchange -p needs to write metadata so there's no way it can be allowed to ignore locking failures. It's a requirement of using the tools that you have a rw lock directory e.g. tmpfs.
The locking directory shouldn't really ever be on an LV, of course.
Ok, so maybe mount -o remount,rw / simply refused to mount the root filesystem because it contained errors (which is likely, since the machine didn't come back up). Bug report withdrawn, but feel free to leave it open if you'd like a reason to work on keeping the metadata in tmpfs or so.
The point about how to recover from setting the only LV which also contains the locking to read-only ought to go into the FAQ.