[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(1.4.24) parted resize lost ext3 partition . . .suggestions?

From: Gary Akers
Subject: (1.4.24) parted resize lost ext3 partition . . .suggestions?
Date: Sun, 22 Dec 2002 22:23:53 -0500

(1.4.24) parted resize lost ext3 partition  . . .suggestions?
I believe the partition is there, but my partition table says it is the new
smaller size and my superblock still says it is the old larger size.
Known error in procedure:   "didn't unmount the partition first"

After shrinking a (RH7.3)  mounted /usr partition with the command:
(parted ver. 1.4.24)

parted /dev/sda resize  5    1090.380   15000

(15000 was well within the empty range.)  That churned along for a while
and then reported an error indicating the kernel could not reread the partition
table and that I should reboot immediately with a rescue disk and reinstall
the boot loader [read section 4 of the parted user documentation. . . .did that

On reboot the 7.3 box gets through LILO ok, but can't mount /usr
A manual fsck gives the error:

The filesystem size (according to the superblock is 5122719 blocks. The physical size of the device is 3560397 blocks. Either the superblock or the partition table is likely to be corrupt! abort<y>?

. . .then attempted to reverse the error in maintenance mode with "parted /dev/sda resize 5 1090.380 21101" reports success, but doesn't change line #5 below back to what it was.

[before]   parted  /dev/sda    print
minor start end type filesystem flags 1 0.031 39.221 primary FAT
2             39.221            1066. 816       primary     ext3
3         1066.816           1090.349        primary     ext3            boot
4         1090.349         34710.754       extended
5         1090.380         21101.000       logical       ext3
6       21101.032         33094.841       logical       ext3
7       33094.872         34122.436                           linux-swap
8       34122.467         34640.156      logical       ext3
9       34640.187          34710.754     logical       ext3

[after]   parted  /dev/sda    print
same except for the expected line #5
5         1090.380         14998.183             logical       ext3

I've noted that the linux rescue environment doesn't complain about mounting the partition. This happened in the middle of an upgrade at a time when my backup won't be in sync. After-the-fact I have a "cp -a" backup with only about a dozen files or so showing IO errors If I get it back in time to get the project back on schedule, I'll verify everything to the
rpm signature database.

next day tried:

   e2fsck -f -n /dev/sda5

pass 1: checking inodes, blocks, & sizes error reading block 4097453 (invalid argument) while reading indirect blocks of inode 18290.
              Ignore error?  (no)
Error while iterating over blocks in inode 18290: Invalid argument /usr: /184724/2562240 files (0.2% non-contiguous), 907103/512279

and then tried     resize2fs -f -p /dev/sda5

              resize2fs:  Can't read an block bitmap while trying to rezize
                               /dev/sda5.  The file system is now 3560397
                               blocks long.

However,  the "change" to 3560397 doesn't stick as shown by subsequent
"parted /dev/sda print" and the fsck error indicating the size of the partition
doesn't match the size of the file system which I can't seem to get through
a successful fsck repair.
see ya Monday

reply via email to

[Prev in Thread] Current Thread [Next in Thread]