Salut,
Apparemment, il est très malsain de lancer un 'fsck.ext4' sur une partition dm-crypt. Je ne le savais pas. J'ai laissé tourné 20 minutes le fsck, qui me donnait beaucoup d'erreurs, et les corrigeait.
Du coup, mon mot de passe ne marche plus pour déchiffrer la partition. Quelqu'un sait-il si je peux espérer quelque chose de mieux que ne rien récupérer du tout ?
Quelqu'un sait-il pourquoi 'fsck.ext4' ne donne absolument aucune alerte pour empêcher les débiles de mon genre de faire ce que j'ai fait ?
Merci de votre aide !
Nucleos
Forum Linux.débutant fsck sur un partition dm-crypt
6
déc.
2016
# Re:
Posté par Cᴬᴾᵀ Samavor . Évalué à 2.
Sur la partition chiffrée ? Parce-que si c’est sur le volume déchiffré (/dev/mapper/<quelquechose>) je ne vois pas le problème.
Quelle ligne de commande ? Normalement fsck ne réalise pas d’opération dangereuses sauf avec l'option --force, dans ce cas fsck ne gueulera pas, c'est voulu, ça permet de "tenter" de récupérer un système de fichier endommagé au point de ne pas être directement reconnaissable.
[^] # Re:
Posté par Nucleos . Évalué à 1.
fsck -y /dev/sdd5
Je n'aurais jamais cru que mon système de fichier n'était absolument plus de l'ext4. (Maintenant que j'y réfléchis, c'est évident…) Et comme le dit le commentaire ci-dessous, c'est probablement parce que j'ai créé ce système LUKS sur un ancien système de fichiers ext4 que fsck.ext4 n'a rien vu d'anormal (si ce n'est beaucoup d'erreurs.)
# Pistes
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Oulà oui ! C'est à dire, si tu as lancé le fsck sur le périphérique physique sous-jacent, c'est très malsain en effet, parce que ce qu'il contient n'est pas du tout de l'Ext4, mais du LUKS qui contient, chiffré, un volume Ext4. Essayer de l'interpréter comme de l'Ext4, ça va donner du grand n'importe quoi. Imagine une voiture contenant un vélo, et un type en train d'essayer de la réparer comme si c'était un vélo, sans voir que ce qu'il doit réparer, c'est le vélo qui est dedans : « Oulà, votre vélo a deux roues de trop, il faut les retirer ! », etc.
Non, là j'ai bien peut que ce soit bel et bien fichu, après qu'fsck ait longuement réparer un truc qui n'était pas de l'Ext4 de façon à ce que ça ressemble à un Ext4 bien propre, le résultat n'a sans doute plus grand chose de récupérable en tant que LUKS…
Alors, j'ai une hypothèse à ce sujet. Un volume LUKS, ça a un en-tête qui commence au tout début, qui s'étend sur 592 octets, et qui est suivi de plusieurs emplacements de stockage de clefs de déchiffrement (qui sont chiffrées avec un mot de passe). Un système de fichiers Ext4, ça a un superbloc qui commence à l'octet 1024.
Du coup, je soupçonne ta partition d'avoir un jour contenu directement un système de fichiers Ext4, avec son superbloc à l'octet 1024, s'étendant sur une certaine longueur (les octets 0 à 1023 sont inutilisé par Ext4, pour laisser de la place à un éventuel chargeur de démarrage il me semble). Plus tard, tu as sans doute mis à la place un volume LUKS, avec son en-tête de l'octet 0 à l'octet 591, suivi par un emplacement contenant la clef de déchiffrement protégée par ton mot de passe, suivie par des emplacements réservés à d'autres clefs mais laissés vide dans ton utilisation. Le superbloc de ton ancien système de fichiers Ext4 est donc probablement resté intouché, dans la zone réservée pour ces éventuelles clefs supplémentaires.
Tu avais donc un une partition contenant un volume LUKS, identifiable à son en-tête à l'octet 0, mais également un ancien superbloc Ext4, éventuellement tronqué et sans données correctes pour sons système de fichiers, mais toujours reconnaissable. C'est à mon avis pour ça que fsck a bien détecté un système de fichiers Ext4 (sans cela, il se serait terminé immédiatement en t'indiquant que ce n'était pas de l'Ext4, ou que c'était abîmé au point d'être méconnaissable et irrécupérable) et a commencé à faire son boulot.
Pour éviter ce genre de truc, étant donné que les différentes utilisations d'un disque dur ou d'une partition (système de fichier FAT, Ext*, NTFS, volume physique LVM, volume RAID, volume LUKS…) placent leurs superblocs, leurs méta-données, bref leur point d'entrée et signature permettant de les reconnaître, à différents endroits, le plus sûr consiste, à chaque changement d'usage d'un périphérique, à le remplir de zéros. Ou au moins à remplir de zéros le début (disons quelques mébi-octets, pour être sûr) et la fin (parce que des tables de partitions GPT ont une copie de leurs méta-données à la fin ,et que certains volumes RAID ont l'intégralité de leurs méta-données à la fin !).
[^] # Re: Pistes
Posté par Tanouky . Évalué à 1.
À tout hasard, n'est-il pas possible de sauvegarder les 1024 premiers octets sur une clé USB afin de faire une "copie" en cas de problème ?
[^] # Re: Pistes
Posté par Marotte ⛧ . Évalué à 2.
Oui. Mais en l’occurrence ça n’aurait rien changé. Le fsck a « bousillé » le LUKS en pensant réparer un ext4, donc pas seulement au niveau des 1024 premiers octets.
[^] # Re: Pistes
Posté par Nucleos . Évalué à 1.
Merci beaucoup pour cette réponse précise ! Je suis bien triste d'avoir perdu des centaines de Go de photos, mais ça m'apprendra. Bonne soirée.
[^] # Re: Pistes
Posté par NumOpen . Évalué à 5.
Sauvegardes, sauvegardes, sauvegardes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.