GNOME Bugzilla – Bug 623630
Move logical partition to right yields invalid partition table on /dev/sda -- wrong signature 0
Last modified: 2010-08-01 18:33:43 UTC
The partition table becomes invalid when a logical partition is moved to the right to butt up against another logical partition. Steps to recreate the problem: 1) Create an extended partition 2) Create a small logical partition at the start of the extended partition 3) Create a small logical partition at the end of the extended partition 4) If not yet done, apply all of the above steps 5) Select the small partition created in step 2, choose "Partition --> Resize/Move", and move the partition to butt up against the partition created in step 3. 6) Apply this operation and the error will be encountered In all of the above steps, the default "Align to MiB" setting was used. An MSDOS partition table was used.
Created attachment 165307 [details] Sample gparted_details.htm log file when partition table is invalidated / overwritten.
The first report of this problem with GParted 0.6.0 can be found in the following forum post: gparted-0.6.0: Invalid partition table, wrong signature 0 http://gparted-forum.surf4.info/viewtopic.php?id=14199
When creating a logical partition, an Extended Boot Record (EBR) is created in the space preceding the logical partition. The EBR is used to define the location of the logical partition, and also the location of the next EBR. EBRs are chained from one to the next for each logical partition. GParted uses libparted to edit partition tables. It appears that when GParted requests libparted to create a logical partition, libparted will try to place the EBR on an exact multiple of cylinder size in the free space preceding the logical partition. A cylinder is (255 heads) x (63 sectors/track) = 16,065 sectors. For devices with a sector size of 512 bytes, this equates to just less than 8 MiB. Hence the EBR could be anywhere within 8 MiB of the start of the logical partition. When the EBR is found further than 1 MiB earlier than the logical partition, moving a different partition can potentially overwrite the EBR. Thoughts on work arounds to avoid this problem are to: A) Use align to cylinder Or, B) Ensure that at least 8 MiB of unallocated space is left in front of each logical partition when moving a partition. This means that you would always leave at least 8 MiB Free space after in the Resize/Move or Copy dialog box.
In order to reduce the chances of this bug occurring, "align to MiB" will be disabled temporarily until this bug can be properly addressed. This will permit a timely release of the following commit to be included in the next release of GParted (0.6.1): http://git.gnome.org/browse/gparted/commit/?id=1e1ea1f09cd0bb15ed156d9dc018e779160588d1
For the test case I used in the first post, I created a 100 MiB disk device with: sudo modprobe scsi_debug dev_size_mb=100 sector_size=512 Then I used GParted to create: 1) An extended disk partition to span the disk device (99 MiB) 2) An 8 MiB ext2 partition at the start of the extended partition 3) A 40 MiB ext4 partition at the end of the extended partition. At this point the partition table was as follows: user@lucid:~$ sudo sfdisk -uS -l -x /dev/sdc Disk /dev/sdc: 200 cylinders, 32 heads, 32 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdc1 2048 204799 202752 5 Extended start: (c,h,s) expected (2,0,1) found (0,32,33) end: (c,h,s) expected (199,31,32) found (12,190,50) /dev/sdc2 0 - 0 0 Empty /dev/sdc3 0 - 0 0 Empty /dev/sdc4 0 - 0 0 Empty /dev/sdc5 4096 20479 16384 83 Linux start: (c,h,s) expected (4,0,1) found (0,65,2) end: (c,h,s) expected (19,31,32) found (1,70,5) - 112455 204799 92345 5 Extended start: (c,h,s) expected (109,26,8) found (7,0,1) end: (c,h,s) expected (199,31,32) found (12,190,50) - 2048 2047 0 0 Empty - 2048 2047 0 0 Empty /dev/sdc6 122880 204799 81920 83 Linux start: (c,h,s) expected (120,0,1) found (7,165,31) end: (c,h,s) expected (199,31,32) found (12,190,50) - 112455 112454 0 0 Empty - 112455 112454 0 0 Empty - 112455 112454 0 0 Empty user@lucid:~$ From the above information we can see that the Extended Boot Record for /dev/sdc6 is stored at sector 112,455 (~54.9 MiB from the start of the disk). The actual /dev/sdc6 partition does not begin until sector 122,880 (60.0 MiB from the start of the disk). This means that there is ~5.1 MiB between the EBR for /dev/sdc6, and the actual start of /dev/sdc6. Hence I think at least two approaches are required for this problem. 1) Before actually moving data, check to see if the moved data will overwrite any EBR. 2) When creating partitions aligned to MiB, see if the EBR can be placed much closer (< 1 MiB) in front of the actual logical partition. An interesting side note is that if I create another logical partition in the free space between the end of /dev/sd5 and the beginning of /dev/sd6 (50 MiB of unallocated space), the EBR for /dev/sdc is moved to sector 120,832 (59.0 MiB from the start of the disk). This means that there is now 1 MiB between the EBR for /dev/sdc6, and the actual start of /dev/sdc6.
Another interesting note is that when the newly created /dev/sdc7 is deleted, the EBR for /dev/sdc is moved back to sector 112,455 (~54.9 MiB from the start of the disk).
A fix for this problem has been committed to the GNOME git repository for inclusion in the next release of GParted (0.6.2) The relevant code changes can be viewed at the following links: Re-enable MiB partition alignment option http://git.gnome.org/browse/gparted/commit/?id=a92f2dad391959971330719e7da03e88fd02cdc5 Fix problem with logical partition move overwriting EBR (#623630) http://git.gnome.org/browse/gparted/commit/?id=c3a06ffd6c410463cca9d10472fcb8a9bcddefb6 Ensure original partition boundaries kept on rollback of failed move http://git.gnome.org/browse/gparted/commit/?id=a3d70a1fbfbf07aeba9d33049cf6824569e75a8b
These fixes have been included in the GParted 0.6.2 release. Closing this bug.