superblock size != partition size after Fedora 14 install with resize option

[manse]

I've just installed Fedora 14 over an old Ubuntu (heron, I think). The old install used a single partition for both / and /home; and I wanted to try to avoid reinstalling /home if possible (but yes, I did back it up).

I chose the anaconda option to shrink the old Ubuntu /, and created a new LVM for the Fedora /. This seemed to work perfectly. I mounted the old / on '/host' (an old naming habit), and then mounted individual home dirs into /home using autofs. All seemed fine. However, on my first reboot after the autofs mounts fsck failed.

The current situation is as follows:

# fsck /dev/sda6
fsck from util-linux-ng 2.18
e2fsck 1.41.12 (17-May-2010)
The filesystem size (according to the superblock) is 15360000 blocks
The physical size of the device is 15359895 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

# dumpe2fs /dev/sda6 | grep 'Block count'
dumpe2fs 1.41.12 (17-May-2010)
Block count: 15360000

# dumpe2fs -o superblock=32768 /dev/sda6 | grep 'Block count'
dumpe2fs 1.41.12 (17-May-2010)
Block count: 15360000

Same thing for all the other backup superblocks I've tried.

# echo '15360000 4 * p' | dc
61440000

# fdisk -s /dev/sda6
61439583

resize2fs tells me to run fsck, and complains of a short read if I try to force. fsck seems to run fine if I say 'no' to the abort prompt, but doesn't change the problem. Filesystem is ext3..

Can anyone suggest a way to fix this short of remaking the filesystem and recovering from the backup?

Many thanks.

manse.

---------- Post added 11th April 2011 at 01:36 AM ---------- Previous post was 10th April 2011 at 08:13 PM ----------

Managed to fix it, thanks to http://smartmontools.sourceforge.net/badblockhowto.html.

For the record:

Started with debugfs. First used icheck and ncheck to work out which file(s) had been written to the non-existent blocks past the partition size. Fortunately, there was only one. Deleted that file (can restore it from backup later). Quit debugfs.

Now resize2fs -p -f worked perfectly. fsck after resizing was clean. Reboot seems happy.

Hope someone else finds this helpful.

As for the origin of the problem, I would guess there's a rounding bug in the code anaconda uses to shrink partitions ...

m.

[manse]

Not sure what has become of the original messages here. But since the thread is still open I'll try to reprise in case others hit the same problem.

I resized an ext3 filesystem as part of a Fedora 14 install, choosing the option to do so in anaconda. A rounding bug (I presume) meant that once I was done the filesystem was very slightly larger than the partition. After one mount the nonexistent blocks beyond the partition end were allocated. On reboot, fsck failed with a complaint about filesystem size (in superblock) being larger than the partition. resize2fs wouldn't work -- wanted me to run fsck if run without -f, complained about a short read if run with -f.

The fix was to run debugfs (see http://smartmontools.sourceforge.net/badblockhowto.html). I used icheck and ncheck to find the file that had been moved to the end of the filesystem, removed it, and then could resize2fs -f successfully.

m.

[dirkhartzer]

i've created an account just to thank you

THANK YOU!!!

i installed Fedora 16 this week and had the same issue after a resize