[solved] Expanding partitions on a larger-than-original GPT disk

My assumption is that you are using a GUID Partition Table (GPT).

The crux of the problem is that the GUID Partition Table (GPT) stores the ending Logical Block Address (LBA) of the disk when it is created.  Since you have added more disk space to the RAID, the GPT is still unchanged and hence limits actions to within its definition of the end of the disk.

GParted unfortunately does not handle this situation yet.
See Bug 566935 - Unable to expand Areca RAID partition.

There is good news though, in that parted should be able to increase the partition size.  If you use parted from the command line to "fix" the problem with the partition table, then you should be able to go back into GParted and continue with the expansion of your ext3 partition :-)

Thank you

However, parted does not offer to fix the issue with the GPT disk in my case and I cannot figure out how to trigger it to do so.

I'll post the output of that command you had people run in the bug report:

sudo parted /dev/sdb print unit s print unit chs print
Model: HPT DISK_4_0 (scsi)
Disk /dev/sdb: 7001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  5001GB  5001GB  ext3                    

Model: HPT DISK_4_0 (scsi)
Disk /dev/sdb: 13673562112s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End          Size         File system  Name  Flags
 1      34s    9766830046s  9766830013s  ext3                    

Model: HPT DISK_4_0 (scsi)
Disk /dev/sdb: 851139,223,27
Sector size (logical/physical): 512B/512B
BIOS cylinder,head,sector geometry: 851139,255,63.  Each cylinder is 8225kB.
Partition Table: gpt

Number  Start   End           File system  Name  Flags
 1      0,0,34  607957,13,22  ext3                    

yes I have - parted even sees it, look in the code block, it says 7001GB total size

I figured that perhaps it was Fedora 9's (64bit?) parted that was not detecting / not warning about the incorrect GPT (distros modify stuff right?) so I compiled it on my own and it is presenting me with the option to relocate the backup GPT and delete the old one.  I'm worried about deleting the old one because the first expansion I did on the drive DID expand it a little so I don't want it to erase anything

I'm going to experiment with using that disk image simulation from the bug report

EDIT: what I tried was, I overwrote the backup GPT with hex 11 11 ..... and ran parted, doing this:

./Desktop/parted-1.8.8/parted/parted testmod.img print
WARNING: You are not superuser.  Watch out for permissions.
Error: The backup GPT table is not at the end of the disk, as it should be.  This
might mean that another operating system believes the disk is smaller.  Fix, by
moving the backup to the end (and removing the old backup)?
Fix/Cancel? f                                                             
Warning: Not all of the space available to /home/henry/testmod.img appears to be
used, you can fix the GPT to use all of the space (an extra 204800 blocks) or
continue with the current setting? 
Fix/Ignore? i                                                             
Model:  (file)
Disk /home/henry/testmod.img: 210MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name  Flags
 1      17.4kB  105MB  105MB                          

When I inspected the file after, the area had been overwritten.  This is what I am worried about (if data expanded into that zone) I'm going to try to dd the device near where the end of the partition should be and see what turns up.  So long as the backup GPT label is there as it should be I will proceed, failing that I will shrink the drive away from that end then proceed.

EDIT2: good news, the backup is still there, so I will continue.  I forgot to mention last edit that, I even overwrote the magic number for the GPT backup and it STILL deleted it, which is why I was cautious... it probably should avoid doing that.
I'm glad the backup was still there, since it saved me 8 hours (each e2fsck takes 4....)

wish me luck, I'm going to apply the changes now