Problem with GPT partition after LUN resized (parted-1.7.0)

[Darren Lavender]

Problem with GPT partition after LUN resized

parted-1.7.0  (platform ia64)



##### PROBLEM DETAILS #####


I observe several problems with parted v1.7.0 after having 
resized a LUN on ia64 (SLES8):


### PROBLEM #1:

An exception when parted recognises that the backup GPT header is not
in the correct place and tries to move it:


royce:~/parted-1.7.0/parted/.libs # ./parted /dev/sdd
GNU Parted 1.7.0
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
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? Fix                                                           
                                                                          

You found a bug in GNU Parted! Here's what you have to do:

Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:

Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:
...........

Assertion (n > 0) at exception.c:112 in function ped_log2() failed.

Ignore/Cancel? Ignore                                                     
                                                                          

You found a bug in GNU Parted! Here's what you have to do:
........


I ignored the assertion error (twice) and the operation appeared 
to complete successfully, the backup GPT header was correctly 
relocated to the new volume end.


****  It appears that this has previously been reported, refer to:

http://lists.gnu.org/archive/html/bug-parted/2006-06/msg00014.html

http://lists.gnu.org/archive/html/bug-parted/2006-07/msg00005.html





### PROBLEM #2:

Having relocated the GPT headers, I cannot utilise the additional
space made available in the resized LUN.


.....
Disk /dev/sdd: 25165823s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start      End        Size      File system  Name     Flags
 1      34s        7689555s   7689522s               primary       
 2      7689556s   15379111s  7689556s               primary       
 3      15379112s  23068600s  7689489s               primary       

(parted) mkpart pri 23068601 25165700                                     
Warning: You requested a partition from 23068601s to 25165700s.           
The closest location we can manage is 23068601s to 23068638s.  Is this still
acceptable to you?
Yes/No? no                                                                
(parted)

.....

I dumped out the GPT headers and it appears that parted did not completely 
update the header when the backup GPT header was relocated:


Before LUN resize:


royce:~/parted-1.7.0 # ./readit /dev/sdd
Signature EFI PART
Revision  65536
HeaderSize 92
HeaderCRC32 1240726608
MyLBA  1
Alt-LBA 23068671
FirstUsableLBA 34
LastUsableLBA  23068638      <------- note, value before
DiskGUID
PartitionEntryLBA  2
NumberOfPartitionEntries  128
SizeOfPartitionEntry  128
PartitionEntryArrayCRC32  3390199388


Signature EFI PART
Revision  65536
HeaderSize 92
HeaderCRC32 3668782699
MyLBA  23068671
Alt-LBA 1
FirstUsableLBA 34
LastUsableLBA  23068638      <------- note, value before
DiskGUID
PartitionEntryLBA  23068638
NumberOfPartitionEntries  128
SizeOfPartitionEntry  128
PartitionEntryArrayCRC32  3390199388
royce:~/parted-1.7.0 # 
royce:~/parted-1.7.0 # 


After LUN resize and parted relocated the backup GPT header:


royce:~/parted-1.7.0 # ./readit /dev/sdd
Signature EFI PART
Revision  65536
HeaderSize 92
HeaderCRC32 2807964988
MyLBA  1
Alt-LBA 25165823
FirstUsableLBA 34
LastUsableLBA  23068638        <------------- Not increased
DiskGUID
PartitionEntryLBA  2
NumberOfPartitionEntries  128
SizeOfPartitionEntry  128
PartitionEntryArrayCRC32  3390199388


Signature EFI PART
Revision  65536
HeaderSize 92
HeaderCRC32 210902711
MyLBA  25165823
Alt-LBA 1
FirstUsableLBA 34
LastUsableLBA  23068638        <------------- Not increased
DiskGUID
PartitionEntryLBA  25165790
NumberOfPartitionEntries  128
SizeOfPartitionEntry  128
PartitionEntryArrayCRC32  3390199388
royce:~/parted-1.7.0 # 


So although the header was relocated parted made no attempt to 
modify the LastUsableLBA field, hence the newly available space 
is not available for a new partition or resizing.  Should this 
not have been adjusted to 25165790 ?

Am I missing some technical reason for why this did not happen 
or is it simply an oversight/defect?


##### PROBLEM REPLICATION PROCEDURE #####

The problems are very easy to reproduce:

o present to the OS a disk/lun from a device that supports 
  resizing, eg: disk array of some description

o in parted, mklabel gpt

o create a couple of partitions to utilise the currently available space 
  via:  mkpart pri start end

o resize the lun and do whatever you need on your OS to see the
  newly reflected size (lun rescan or reboot perhaps)

o run parted against the lun, you will observe the assertion problem
  reported as problem #1 above

o after fixing the header, try and add a new lun in the newly available
  space