[Gllug] fsck: 'unable to set superblock flags on /1'

[Nix]

On Mon, 15 May 2006, Garry Heaton prattled cheerily:
> Just had a freeze while attemtping to delete the contents of a
> directory on Fedora Core 5. Powered off and rebooted then Fedora
> attempted to repair the filesystem but insisted I needed to do it
> manually so dropped me into a shell. It was taking far too long
> responding to y/n confirmations for repairs so I decided to reboot
> using the Fedora Core 5 Rescue Disk. This gave me a /mnt/sysimage
> shell but I then realised running 'fsck' on a mounted filesystem isn't
> a good idea. So, I rebooted with Knoppix 3.8, 'umount'-ed the
> troublesome /dev/hda1 which, curiously, had been successfully
> automounted and was readable. Running both 'sudo e2fsck -p /dev/hda1'
> and 'sudo fsck -a /dev/hda1' produced the same error: '.... unable to
> set superblock flags on /1'. What's the source of this problem? What
> to do?

As far as I can tell from the code, it means that fsck tried to do
journal recovery automatically (which it does near the start of
fscking), and then found that the journal still needed recovery even
though it had just been recovered. A comment in the code says `this
should never happen, unless the hardware or device driver is being
bogus', but it seems to me that this is incorrect: if the ext3
filesystem is actually mounted and being written to, you could well see
the journal being updated by the kernel at the same instant as fsck is
recovering it, leading to this error.

But if the fs isn't mounted anymore, something odder is going on.
Appeal on the ext2-devel mailing list :)

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug