On Fri, 2004-07-23 at 22:46, Robert wrote:
I do not know if this is related, but perhaps the following bugzilla report applies:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90894
This has been continuing into RHEL3 and FC1 last I checked. Not sure about FC2, but some interesting comments that may apply...
--Rob
Thanks for the reply and the bugzilla URL. They sure sound related to me. My new question is whether or not anyone has successfully attacked one of the affected partitions with Partition Magic.
Last I tried, PartitionMagic 8.01 trashed the RHEL3 installed partition I had - it was time for the backup tape..... At least, parted told me it did not like the partition, PM hosed it up.
But, of course, YMMV....
--Rob
It is now after the fact. All valuable data on the partition I was interested in resizing has been saved, the drive fdisk'ed and mke2fs'ed and the blank partition WAS untouchable by either parted or PartitionMagic. After reading the following, I did another mke2fs on each of the ext3 partitions on that drive using the -O none option and the result is, as Jonathan found, partitions that contain many more super blocks but which are parted-friendly. (PM8 also likes them).
Like this:
[root@mavis root]# mke2fs -j -O none /dev/hdb2
Until libparted is fixed to deal with the different structure, I'll happily sacrifice storage space for compatibility & flexibility.
Thanks again to those who replied.
Subject: Parted 1.6.11 croaks when 'sparse_super' is set? From: Jonathan D Reed <jdreed@xxxxxxx> Date: Wed, 19 May 2004 17:56:20 -0400 CC: jdreed@xxxxxxx Newsgroups: gmane.comp.gnu.parted.bugs
(N.B. While I saw the effect of this bug reported in other messages, I didn't see one that actually tracked it down to sparse_super - apologies if I missed one.)
Parted appears to not be able to deal with ext2 filesystems that have sparse_super set. I first noticed this when running parted (and qtparted) from the SystemRescueCD (http://sysresccd.org). I downloaded 1.6.11 and built it to confirm that the bug was still present in the latest version. Here's an example of what happens:
0) Make sure partition isn't mounted:
infinite-loop.mit.edu# mount | grep -i hda7
infinite-loop.mit.edu# grep -i hda7 /proc/mounts infinite-loop.mit.edu#
1) infinite-loop.mit.edu# /sbin/mke2fs /dev/hda7
[completes correctly, for the sake of brevity, I'll just list the superblock backup]
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
2) Just for fun, let's make sure it's ok:
infinite-loop.mit.edu# /sbin/e2fsck /dev/hda7 e2fsck 1.32 (09-Nov-2002) /dev/hda7: clean, 11/1596224 files, 50103/3190902 blocks
3) It is, now we'll run parted check on it:
infinite-loop.mit.edu# parted /dev/hda check 7 No Implementation: This ext2 filesystem has a rather strange layout! Parted can't resize this (yet).
4) Now we'll recreate the same filesystem, this time with no special options (suitable for mounting on pre-Linux 2.2 systems)
infinite-loop.mit.edu# /sbin/mke2fs -O none /dev/hda7
[success, this time creating many more superblock backups]
5) Again, let's check it:
infinite-loop.mit.edu# /sbin/e2fsck /dev/hda7 e2fsck 1.32 (09-Nov-2002) /dev/hda7: clean, 11/1596224 files, 50279/3190902 blocks
6) It's good. Run parted on it:
infinite-loop.mit.edu# parted /dev/hda check 7 Information: The ext2 filesystem passed a basic check. For a more comprehensive check, use the e2fsck program.
7) OK, now it works. Just to confirm it's sparse_super that's breaking things, we'll do it one more time. mke2fs by default will enable "filetype" and "sparse_super" if no options are specified. So we'll enable filetype, and disable sparse_super.
infinite-loop.mit.edu# /sbin/mke2fs /dev/hda7 -O filetype,^sparse_super infinite-loop.mit.edu# /sbin/e2fsck /dev/hda7
e2fsck 1.32 (09-Nov-2002)
/dev/hda7: clean, 11/1596224 files, 50279/3190902 blocks
infinite-loop.mit.edu# parted /dev/hda check 7
Information: The ext2 filesystem passed a basic check. For a more comprehensive check, use
the e2fsck program.
So, for some reason, parted is croaking when it encounters filesystems with sparse superblocks. This is unfortunate, as it prevents users from resizing partitions that are large enough to merit sparse_superblocks.
I was able to reproduce this behavior on 3 machines, one running Gentoo with a 2.4.26 kernel, one running RedHat 9 with a 2.4.20 kernel (2.4.20-30.9), and one running RedHat Enterprise Linux 3.0 (Update 2) with a 2.4.21 kernel (2.4.21-15.EL).
Oh, and just for kicks, my partition table:
Disk geometry for /dev/hda: 0.000-38172.750 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 47.065 primary ext3 2 47.065 10048.469 primary fat32 boot, lba
3 10048.469 10566.188 primary linux-swap 4 10566.189 38170.063 extended 5 10566.220 25572.216 logical ext3 6 25572.248 25705.568 logical ext2 7 25705.600 38170.063 logical ext2
But all 3 machines had different partition tables.
-Jon
-------- Jonathan Reed jdreed@xxxxxxx
-- Democracy is a form of government in which it is permitted to wonder aloud what the country could do under first-class management. -- Senator Soaper
09:33:00 up 28 min, 3 users, load average: 0.38, 0.19, 0.12
One billion seconds ago it was 06:46:20 CST Thu 11/30/72