Web lists-archives.com

Re: libgparted bug.




On Saturday 10 February 2018 03:57:57 Thomas Schmitt wrote:

> Hi,
>
> 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
> medium.)
>
> > 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
> card.)
>
> 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 
gdisk:
=====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

So:
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
the disk.
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:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged
======
snip some gdisk blather
======
gxpert command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table 
may
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
33 blocks!
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 :)
>
> Thomas

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>