Problème de superblock du à un probleme de taille de filesystem

Support Debian
#1

Bonjour,

J’etais dasn la situation suivante:
Disk 1: luks avec LVM
Boot parfait, tout était fonctionnel.
J’ai ajouté un disque sur lequel j’ai fait:
cryptsetup luksFormat => OK
cryptsetup luksOpen => OK
J’ai ajouté le disque dans /etc/crypttab
j’ai ensuite ajouté le disque_crypt dans PV
puis le PV dans le VG
puis j’ai etendu mon /home d’une taille qui le positionne sur les deux disques
jusque là tout va bien
j’ai fait un update-initramfs -c -k all
pas de messages d’erreurs
J’ai redemarré et les ennuis ont commencé:

Le système n’a pas pu ouvrir le deuxième disque après le code de dechiffrement, de fait la gestion de la partition chiffrée et du LVM a été impactée car un seul disque etait dechiffré.

Je suis passé en mode recover avec mon iso d’instalaltion.
A partir de là j’ai pu retailler la partition home pour qu’elle ne soit plus sur le deuxième disque.
J’ai retiré le disque du VG puis du PV et du /etc/cryptab.
Je ne me rapelle plus d’avoir resize2fs le HOME. Et c’est probablement là le problème.

Car pour la particion LVM HOME, j’ai un probleme de superblock, avec un filesystem size qui ne s’est pas mis à la bonne valeur qui est bien sur supérieur à la taille du disque physique.
LVM considère bien la taille redéfinie.

J’ai donc:

  • Le filesystem à l’ancienne taille
  • le LVM à la bonne taille
  • Le disque physisque d’une taille inférieur au filesystem.

le resize2fs ne marche pas car il detecte une incohérence : Block bitmap checksum does not match bitmap while trying to resize
Il me dit de faire un e2fsck -fy
mais là j’ai le message suivant:
filesystem size is taille1 the physical is taille2, et taille2<taile1.

j’ai malheureusement oublié de redéfinir la taille de /home avant d’enlever le disque. Jai pu dire à LVM de diminuer, mais pas moyen de faire le resize2fs.

Y-a-t-il un moyen de s’en sortir quelque part sans perdre les données.

Pour le moment je ne trouve que des solutions sans LVM.
Mon superblock est corrompu et je ne sais aps comment le remettre en etat. Il n’y a pas eu de changement sur les données donc elles sont toujours là.
Et comme l’ajout du nouveau disque avait pour but de permettre la reorganisation des sauvegardes je n’ai aps sauvegardé ma partition home (comme quoi li ne faut pas faire deux choses à la fois)
Il me faut donc récupérer l’accès à ma partition pour sauvegarder les données car sinon j’ai près de 50h de boulot perdu.

#2

Salut,

Sérieux problème et je ne vais pas t’apprendre que toute autre manip risque d’aggraver la situation.

A mon humble avis 50h, c’est rien par rapport au temps à passer pour essayer qqc sans succès assuré.

La première chose que j’essaierais et de voir comment faire un « hard copy » de l’ensemble pour faire les manip sur la copie et pas sur l’original.

Bon courage.

#3

J’y avais pensé aussi, mais le hard copy en question « pèse » environ 1,5 To si on considère les espaces définis par chaque partitions.
ceci dit, vu que le deuxième disque n’est pas utilisé, je peux directement cloner le 1er sur le second effectivement.
Resterais ensuite à faire les modifications de bas niveau impliquant de redéfinir la taille réelle. Mais difficile d’en avoir les informations sur internet malgré tout.
C’est d’ailleurs avec un tutoriel mal documenté que j’ai posé le socle de mon problème actuel.
Pour le moment je n’ai passé qu’environ 4 à 5h pour essayer de réparer mon problème :slight_smile:

#4

Pour ce faire il faut réduire la taille du filesystem à une taille acceptable, défini une taille proche de al limirte et test :

resize2fs -f /dev/sdXX **TAILLE QUE TU VEUX**

Et après :

fsck -f /dev/sdXX

Il te faudra je pense passer outre la vérification du filesystem lors du redimensionnement avec -f, autre détails assure toi d’avoir le paquet e2fsprogs

#5

J’ai une erreur avec cette commande (celle du premier message)
pour e2fsprog faut que je regarde car je n’ai pas vérifié ce point.
fsck => e2fsck -yf -v /dev… erreur là aussi à cause du superblock.

Ah j’oubliais pour @PmGs , le soucis c’est que dans ces données il y a ma VM PKI sur laquelle j’avais fait tous les renouvellements de certificats de mes environnements :slight_smile:

#6

e2fsck a une option -b , une -B
à part ça aucune idée

#7

la -b j’ai fait des tests, mais en fait le probleme de superblock c’est que la taille du filesystem ne correspond pas à la taille réelle.
facile à régler avec une partition classique, mais un peu plus difficile avec LVM.
LVM donne une taille pour laquelle le filesystem en a une autre.
J’ai oublié de faire un resize2fs avant d’enlever le second disque du VG/PV.
Je testerais bien de refaire le second disque pour le remettre à une taille plus grande que la taille attendue, mais ce n’est pas sans risque d’une part, et pas sur que ça marche d’autre part.

#8

Ca augmente les 50h mais ce n’est toujours que du travail … pas comme s’il y avait eu qq bitcoins :slight_smile:

#9

Certes, mais ça a un impact sécurité par contre.
Encore que, si je dois refaire les 3 VM fortement impactées, c’est plus de 50h en fait :slight_smile: c’est presque le double

#10

Première étape faite: j’ai cloné le disque nvme0n1 vers le disque nvme1n1.
Je vais aussi essayer de reproduire le problème avec une VM de test.

ainsi je pourrais essayer de voir comment modifier le superblock de la partition lvm over luks, c’est le numéro de block qui ne va pas semble-t-il.

Ajouter un 2ème disque chiffré à un LVM over LUKS
#11

Bon, je crois malheureusement que je vais abandonner. Il n’y a pas moyen de remettre la taille du filesystem à la taille de la partition lvm.

Toutes les manipulation trouvées sur internet échouent.
Il faudrait pouvoir quasiment aller modifier les métadonnées et les block de configuration à la main avec un éditeur hexa pour y arriver et encore.

Seul chose positive dans l’opération, c’est que mes recherche pour ajouter un disque chiffré dans un PV ont fonctionné (même si je suis obligé de donner le mot de passe pour chaque disque)

#12

Abandon fait, j’ai supprimé ma partition home dans LVM et recrée.