Re: libgparted bug.
- Date: Sat, 10 Feb 2018 09:10:40 -0500
- From: Gene Heskett <gheskett@xxxxxxxxxxx>
- Subject: Re: libgparted bug.
On Saturday 10 February 2018 03:57:57 Thomas Schmitt wrote:
> i wrote:
> > > your count=122070 was too small. It should have been 128912.
> Gene Heskett wrote:
> > the backup GPT table, if it exists, is actually at the end
> > of the disk, after another 50Gb of of 0000's. But how do I "fix" the
> > file?
> Partition editors suitable for GPT are supposed to be able to create
> a new backup GPT at the end of the storage medium. Of course this
> makes few sense in the image file, because it does not have the final
> medium size and also because yours is too short anyway.
> > Blame that on gparted which did not update the ending GPT table when
> > I shrank part 7 from 59.6 GB to about 7
> The backup GPT is always at the very end of the storage device. Not
> necessarily directly after the last allocated partition.
> (That's why GPT is less suitable for image files as would be MBR
> partition table, which has reference to the size of the final storage
> > gdisk /dev/sdd
> > x
> > e
> > w
> > seems to have fixed that, gparted is now as happy as a clam.
> Formally your GPT is ok now. But to my computation, the last ~ 450 MB
> of your partition 7 are not filled with bytes from the original card.
> This range rather contains bytes which were on the new card already
> before you copied the image file onto it. (Not really random, but
> quite surely not matching the data which were valid on the original
> You could test this with the image file, by mounting partition 7 and
> checking whether all its data files are fully readable:
> mkdir /mnt/partition7
> mount -o loop,offset=134217728 rock-img-shrunk.img /mnt/partition7
> tar cf /dev/null /mnt/partition7
> umount /mnt/partition7
> rmdir /mnt/partition7
> (134217728 = partition start 262144 * 512 bytes per block)
> If the directory tree of the filesystem in partition 7 refers to files
> in a missing end piece of the partition, then you should see an i/o
> error from tar while it copies all file content into /dev/null.
> This will not yield i/o errors on /dev/sdd, because there you have
> readable bytes at the end of the partition. They are just not those
> which should sit there, to my theory.
> But i seem to be out of sync with your endeavor:
> How did you now manage to get rock-img-shrunk.img onto the new
> /dev/sdd ? To my account, this was not yet achieved when you sent the
> mail with Date: Fri, 9 Feb 2018 12:22:54 -0500
> which reported an MBR partition table with partition 1 starting at
> block 32768 and containing "HPFS/NTFS/exFAT".
Have 3 identical 64gb samsungs laying here, its possible I wrote the 2nd
one twice, and that was in fact an unwritten new card. Writing to it
again was successfull.
But I have now used the src card to regenerate the file, which is now
844837683 bytes long, and perhaps a valid file. But not yet according to
=====Disk rock-img-shrunk.img: 16500736 sectors, 7.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125171678
Partitions will be aligned on 64-sector boundaries
Total free space is 108670973 sectors (51.8 GiB)
Number Start (sector) End (sector) Size Code Name
1 64 8063 3.9 MiB 8300 loader1
2 8064 8191 64.0 KiB 8300 reserved1
3 8192 16383 4.0 MiB 8300 reserved2
4 16384 24575 4.0 MiB 8300 loader2
5 24576 32767 4.0 MiB 8300 atf
6 32768 262143 112.0 MiB 0700 boot
7 262144 16500735 7.7 GiB 8300 root
gene@coyote:~/rock64.imgs$ /sbin/gdisk rock-img-shrunk.img
GPT fdisk (gdisk) version 0.8.5
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
BSD: not present
APM: not present
snip some gdisk blather
gxpert command (? for help): v
Caution: The CRC for the backup partition table is invalid. This table
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Warning! Secondary partition table overlaps the last partition by
You will need to delete this partition or resize it in another utility.
Identified 2 problems!
Expert command (? for help): disk is still unhappy:
And it won't write. Sigh.
> Have a nice day :)
And despite my emasculation of udev, disabling sdd, according to the
syslog, usbmount is still auto mounting these cards, all 3 of them. So
if I plan on working with these images on this machine with gparted, I
imagine I had better find usbmount and remove its execute bits. But
first make my baby some breakfast.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>