comment tronquer un fichier image disque d'espace inutilisé sans corrompre la table de partition GPT (pointeur de fin)
Beaucoup d'informations sur la prise d'une image d'un disque et sur la réduction de la partition du système de fichiers racine (bionique), puis sur la troncature de l'image pour supprimer la partie qui est devenue de l'espace libre. Comme https://softwarebakery.com//shrinking-images-on-linux
Il y a donc essentiellement trois étapes. Utilisez resize2fs pour réduire un système de fichiers sur une partition, puis réduisez également la taille de la partition. Enfin, supprimez l'espace désormais inutilisé dans le fichier image.
C'est la troisième partie avec laquelle j'ai un problème. Chaque fois que j'essaie dd ou tronque toutes les partitions de l'image sont supprimées comme si la table de partition GPT dans le fichier image était mise à la poubelle.
Voici l'image originale
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk rock64-base.img: 30310400 sectors, 14.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 159DCEDE-DBEA-4657-96D9-2CE178A96B7E
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 30310366
Partitions will be aligned on 64-sector boundaries
Total free space is 30 sectors (15.0 KiB)
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 30310366 14.3 GiB 8300 root
Puis après les deux premières étapes
Found valid GPT with protective MBR; using GPT.
Disk test.img: 30310400 sectors, 14.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 159DCEDE-DBEA-4657-96D9-2CE178A96B7E
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 30310366
Partitions will be aligned on 64-sector boundaries
Total free space is 23555002 sectors (11.2 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 6755394 3.1 GiB 8300 primary
vous pouvez voir que la partition du système de fichiers racine a été réduite à 3.1G
Je peux bien charger cette image. Je peux le remettre sur une carte SD et démarrer mon appareil. Les étapes 1 et 2 sont donc correctes.
MAINTENANT...
si je termine le processus en faisant `truncate --size = $ [(6755394 + 1) * 512] 'test.img'
et
GPT fdisk (gdisk) version 1.0.3
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
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk test2.img: 6755395 sectors, 3.2 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 159DCEDE-DBEA-4657-96D9-2CE178A96B7E
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 30310366
Partitions will be aligned on 64-sector boundaries
Total free space is 23555002 sectors (11.2 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 6755394 3.1 GiB 8300 primary
Clairement tronqué (ou dd d'ailleurs) ne joue pas bien avec GPT. L'exécution de gdisk sur ce fichier confirme que le gpt est supprimé
si j'exécute gdisk sur le fichier tronqué, il signale un GPT supprimé.
Alors évidemment, il me manque quelque chose ici. Apparemment, lorsque la fin du fichier disque change, le GPT est corrompu ou doit être corrigé (incompatibilité). Même s'il est correct/présent à la fin de l'étape 2. J'ai gâché gdisk et je n'ai pas pu le réparer. En plus de cela, je voulais une solution que je pourrais faire avec un script et avec ce GPT cela ne fonctionne pas.
Donc, parce que c'est un GPT, dois-je utiliser autre chose que tronquer ou dd ou dois-je "corriger" le GPT manuellement après avoir tronqué.
Voici les rapports de vérification de gdisk
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.
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Problem: Disk is too small to hold all the data!
(Disk size is 6755395 sectors, needs to be 30310400 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 30310366, but backup header is at
30310399 and disk size is 6755395 sectors.
The 'e' option on the experts' menu will probably fix this problem
Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.
GPT comprend à la fois une table de partition principale au début du disque et une table de partition de sauvegarde à la fin du disque. (Littéralement la fin du disque - les derniers secteurs du disque.) Ainsi, lorsque vous avez tronqué l'image disque, vous avez supprimé la table de partition de sauvegarde. De plus, certains des pointeurs et métadonnées de la table de partition principale sont devenus invalides, car ils pointaient au-delà de la fin du disque (virtuel). C'est l'essentiel de la plainte de la commande v dans gdisk.
Rien de tout cela ne signifie que le disque est complètement mis à la poubelle. Tant que les données de la table de partition principale sont valides, gdisk (et la plupart des autres outils de partitionnement GPT) peuvent récupérer. Dans gdisk, vous devez taper x pour accéder au menu des experts, puis taper e pour déplacer les données de la table de partition de sauvegarde à la nouvelle extrémité du disque, puis taper w pour écrire les modifications sur le disque. (Je recommanderais de taper v avant w au cas où j'aurais oublié un autre problème; voir aussi ci-dessous ....)
Notez cependant qu'il existe un autre problème: votre image disque a une taille de 6 755 395 secteurs, selon gdisk; mais le dernier secteur de la dernière partition est au secteur 6 755 394. Cela ne laisse pas assez d'espace pour la table de partition de sauvegarde (elle consomme 33 secteurs, par défaut). Si vous pouvez refaire tout le processus, vous devriez probablement réduire l'image du disque dans une moindre mesure. Sinon, essayez d'étendre l'image disque de 33 * 512 (16 896) octets avant de recréer la table de partition de sauvegarde avec gdisk.