Récupérer une partition EXT4 à partir d'un redimensionnement interrompu
monde! [c'est drôle, il supprime automatiquement les "hello" s]
J'installe Ubuntu sur l'ordinateur portable d'un ami et j'ai rencontré un problème lors du redimensionnement de la partition Ubuntu. Je l'étendais à gauche (déplacer et redimensionner), mais le processus a été interrompu pendant la copie des données. GParted indique que la partition est corrompue et que le système de fichiers ne peut pas être lu. Maintenant, je ne suis pas inquiet de la réinstallation. Le problème est que j'avais déjà copié certains des fichiers de la partition Windows.
Comment puis-je reprendre le processus de copie? Voici ce que GParted en dit:
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: [tl;dt]
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal_ext_attr_resize_inode dir_index filetype extent flex_bg sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1155072
Block count: 4619008
Reserved block count: 230950
Free blocks: 764535
Free inodes: 968259
First block: 0
Block size: 4096
Fragment size: 4069
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
...
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
...
Journal superblock magic number invalid!
Unable to read the contents of this filesystem!
...
Une chose particulière qui m'intrigue est l'attribut has_journal_ext_attr_resize_inode sous Filesystem features. C'est comme si on savait que c'était au milieu d'un redimensionnement. Juste une supposition.
Vous ne pouvez pas; le système de fichiers est toast.
Pour reprendre le déménagement, vous devez savoir exactement où vous en étiez lors de l'interruption.
En ce qui concerne les fonctionnalités, je pense que vous avez inséré des traits de soulignement là où il n'y en a pas. has_journal, ext_attr et resize_inode sont des fonctions distinctes. Le premier est le journal ext3/4 qui enregistre les mises à jour des métadonnées dans le fs afin qu'il puisse récupérer rapidement après un crash. Le second signifie que les attributs étendus sont activés et le troisième permet de faire croître le fs tant qu'il est encore monté. Aucun d'entre eux n'a rien à voir avec le déplacement de la partition de gparted.
Votre seul espoir est photorec, qui pourra peut-être récupérer certains fichiers sur un autre disque, mais sans leur nom ou autres métadonnées.
Je ne sais pas exactement ce que vous avez fait là-bas. Avez-vous simplement développé le système de fichiers ou avez-vous également déplacé la partition? Avez-vous copié le fichier dans cette partition pendant le redimensionnement? C'est une très mauvaise idée. S'agit-il de fichiers d'une partition Windows que vous tentiez de supprimer en même temps? C'est vraiment déroutant.
Si vous essayez simplement de restaurer le système de fichiers et que celui-ci ne contient qu'un superbloc défectueux, commencez par effectuer une sauvegarde du lecteur et une sauvegarde du système de fichiers endommagé, pour ne pas aggraver les choses. Alors essayez ceci: Linux: Trouver des superblocs alternatifs