e2fsck: aborted

Andreas Dilger adilger at dilger.ca
Sat May 29 02:47:24 UTC 2010

On 2010-05-28, at 17:49, J.B. Nicholson-Owens wrote:
> Andreas Dilger wrote:
>> What is more important to know is why it thinks the block/inode
>> bitmaps and inode table need to be relocated in the first place. That
>> is a pretty serious/significant problem that should normally never
>> been seen, since the bitmaps never move, and there are backups of all
>> the group descriptors (that say where the bitmaps are located).
> I was unaware this was such a serious issue.  Unfortunately I have no
> helpful information to offer.

Unless you have the original output from the first e2fsck run, it will be quite difficult to determine what actually went wrong here.

>> Did you do something like resize your filesystem before having this
>> problem?
> No resizing at all; this drive has always had one volume on it at max size (1TB minus whatever ext3 needs for its own bookkeeping).
> I used to have this drive mounted in another computer running gNewSense
> (latest + updates) but I thought I'd detach it and put the drive on this
> 64-bit 4GB machine.
> Does it matter that the other system was a 32-bit system?  Would it be
> wise to attempt fsck on a 32-bit machine?

It shouldn't make any difference, but it isn't impossible that there is some kind of bug involved, since I doubt this gets tested all too often.  That said, it seems unlikely, since I'm sure it _does_ happen often enough that it would be reported.  It wouldn't hurt to give it a try on the original 32-bit system, but I fear that even if that were the cause the later e2fsck runs may have changed the filesystem enough that it will be hard to recover.

Cheers, Andreas

More information about the Ext3-users mailing list