e2fsck: aborted

[Andreas Dilger]

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