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>
