Journal Je veux bénéficier du bouclier fsckal !

Posté par  (site web personnel) .
Étiquettes :
10
14
sept.
2008

J'ai des soucis avec un de mes disques durs : régulièrement j'ai des applications qui refusent de se lancer. Si on regarde de plus près, elles plantent tout simplement au lancement, avec des erreurs variées (segmentation fault, illegal instruction, etc.). Et la cause est simple : les binaires sont corrompus sur le disque. Sur un système à base de paquets .deb, # debsums -s, et ça donne par exemple debsums: checksum mismatch iceweasel file /usr/lib/iceweasel/firefox-bin (à corriger avec un # aptitude reinstall iceweasel).

Qu'à cela ne tienne, il suffit de passer le système de fichiers par fsck pour qu'il trouve d'où peut bien venir ce comportement étrange de corruption de binaires du système, à la recherche de badblocks pour ainsi dire. Et comme tout bon geek, je suis bien sûr face à une solution simple : Debian Sid, un disque SATA II, avec chiffrement d'une partition étendue, qui contient un LVM, avec trois partitions à l'intérieur (/, /home, toutes deux en ext3, et le swap). 



# fdisk -l /dev/sda





Disk /dev/sda: 320.0 GB, 320072933376 bytes


255 heads, 63 sectors/track, 38913 cylinders


Units = cylinders of 16065 * 512 = 8225280 bytes


Disk identifier: 0x00098a37





   Device Boot      Start         End      Blocks   Id  System


/dev/sda1   *           1          31      248976   83  Linux


/dev/sda2              32       38913   312319665    5  Extended


/dev/sda5              32       38913   312319633+  83  Linux


(sda1 = /boot ; sda5 = chiffrement+LVM (/, /home et swap) 



# lvs


  LV     VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert


  home   anthra -wi-ao 288,58G


  root   anthra -wi-ao   6,68G


  swap_1 anthra -wi-ao   2,59G


Commençons par la partie facile, le /home. On redémarre en mode single, on démonte /home et on lance un fsck -c -c pour supprimer les blocs endommagés. Normalement tout aurait dû bien se passer... Mais Murphy était là, verdict sans appel, 12 (douze) heures plus tard : 96 badblocks (info donnée par dumpe2fs -b) , 42 blocs dédoublés, des décomptes faux, la routine... Sympa pour le /home.



Bon le swap maintenant. swapoff pour désactiver le swap, mais ensuite fsck.swap n'existe pas. Pas grave on le reformate en ext3, avec tests des blocs, et à la fin retour à un mkswap pour en refaire du swap, et swapon pour le réactiver. Pas de souci sur le swap. On ne peut pas toujours perdre.



La partie compliquée pour la fin : le fsck de la racine. Pas possible en mode multiutisateurs, ni en mode monoutilisateur, ni même en ayant la racine montée en lecture seule... Donc il faut démarrer sur un CD amorçable par exemple. Sauf que le CD de Debian Etch ne sait apparemment pas gérer un disque chiffré+LVM (pour le créer à l'installation OK, mais pour le dépanner, débrouille toi). Bon, passons à un CD SystemRescue, cool y a tout ce qu'il faut dessus pour gérer le chiffrement (cryptsetup) et le LVM. Suffit juste de faire un petit cryptsetup sda5_crypt /dev/sda5, de saisir le mot de passé et hop je dois avoir mon LVM. Ben non. Essais multiples et variés, strace me confirme que je sais taper mon mot de passe correctement... Et pourtant un petit dd if=/dev/mapper/sda5-crypt of=/tmp/TEMP count=100 ; md5sum /tmp/TEMP donne une somme de contrôle différente suivant si je démarre à partir du disque ou du CD amorçable.



Déduction : Debian n'a pas choisi les options par défaut pour le chiffrement, il faut les retrouver (et faudrait fournir un moyen plus convivial d'accès à un disque chiffré+LVM, si ce n'est pas déjà fait... ou me dire comment sinon). La réponse doit donc être la configuration initrd (dans /boot/initrd.img-2.6.26-1-686 en l'occurrence). On gunzip le fichier, on le cpio -i < et on obtient une arborescence de fichiers, dont scripts/local-top/cryptroot qu'il convient de lire, pour découvrir que la bonne commande à appeler est cryptsetup -T1 -c aes-cbc-essiv:sha256 -S256 -h ripemd160 create sda5_crypt /dev/sda5 (et non les choix par défaut aes-cbc-plain, 256, ripemd160 apparemment).



Ensuite un petit vgchange -ay et on retrouve les 3 partitions du LVM. Il devient alors possible de lancer un fsck -c -c sur la racine du disque. Pour apprendre à la fin, merci Murphy, qu'il n'y a aucun problème de badblocks dans cette partie du disque. Du coup, quel est donc le souci ?



Éh bien en fait, je ne sais toujours pas. Par contre :





# debsums -s


(...)


debsums: checksum mismatch libbonobo2-0 file /usr/lib/libbonobo-2.so.0.0.0


debsums: checksum mismatch libqt4-qt3support file /usr/lib/libQt3Support.so.4.4.0


(...)

(oui ça pète juste partiellement GNOME et KDE)

Conclusion : après un WE à geeker et à rechercher comment faire, je n'ai pas progressé dans la compréhension du vrai problème. Juste deux points : tant qu'à faire, autant noter comment j'ai fait et le faire partager, ça pourra toujours servir ; et sinon, n'y a-t-il pas des solutions plus simples pour gens normaux ? Parce que le chiffrement des disques n'est pas prêt de progresser chez les particuliers sinon... Des live-CD qui géreraient ça complètement ?



Pour finir de m'achever, NoNo m'a montré l'article SATA vs. SCSI reliability qui explique pourquoi vous allez aussi perdre des données...



(aparté : en parlant de Debian, le petit Sam est toujours attendu pour répondre à un entretien)

  • # memtest ?

    Posté par  . Évalué à 7.

    As-tu commencé par tester la mémoire avec memtest ?
    J'avais eu un problème il y a fort longtemps de corruption de fichier qui était dus à un défaut sur la RAM ( et j'avais cherché partout sauf là :p ).

    • [^] # Re: memtest ?

      Posté par  (site web personnel) . Évalué à 3.

      Non, je n'ai pas commencé par ça. Mais a posteriori, ce n'était pas ça non plus.

      • [^] # Re: memtest ?

        Posté par  . Évalué à 5.

        Si tu as fait un memtest suite au message de the_groumph, j'aurais tendance à dire que 4 heures, ce n'est pas suffisant pour savoir si de la RAM va bien ou pas...

        ... j'ai eu une Gentoo avec une barette à moitié flinguée (qui a fini par rendre l'âme complètement un peu plus tard, empêchant le boot un "beau" matin, sur la machine en rab dans laquelle je l'avais mise), qui avait bousillé tout le système, suite à une recompilation complète...

        Je n'ai pu identifier le problème qu'après 23 heures de burn sur la barette (quand elle fonctionnait encore à peu près), à partir d'un livecd... j'ai vu la même chose chez un pote qui était persuadé que sa mobo était à moitié morte, car il avait testé le proc sur une autre (pourtant, il avait une sale gueule : le genre de Barton aux coins pas nets qu'on trouvait chez les assembleurs-à-la-rache, à l'époque), et fait un memtest d'une heure... en rentrant d'un weekend où il avait laissé tourner le memtest pendant 36 heures, sur mon conseil de le faire beaucoup plus longtemps, le bilan était qu'une barette était bien défectueuse...

        Malheureusement, la RAM, c'est comme les HDD... ce n'est pas aussi simple que "c'est mort OU pas"... je ne dis pas que c'est forcément la RAM, mais en vérifier la bonne santé est beaucoup plus ardu qu'on ne pourrait le croire, dans maints cas.

  • # LUKS

    Posté par  . Évalué à 5.

    Ta partition n'a pas été chiffrée avec LUKS mais avec le cryptsetup "basique" (LUKS est aussi accessible par cryptsetup), mais LUKS offre des avantages : possibilité de changer le(s) mot(s) de passe sans re-chiffrer entièrement le disque, les options que tu as eu du mal à retrouver sont stockées dans un "entête" que LUKS ajoute à la partition. Il semble avoir d'autres avantages cryptographiques que je ne peux commenter par manque de connaissances.
    LUKS est utilisable avec la commande "cryptsetup", est supporté par "cryptmount" et est inclus de base dans Debian.
    http://luks.endorphin.org/

    • [^] # Re: LUKS

      Posté par  (site web personnel) . Évalué à 3.

      Tout a été mis en place à l'installation par Debian ; c'est bien pour ça que j'estime que Debian pourrait savoir relire ce qui a été créé à l'installation (quitte à aller piocher comme moi dans le /boot/initrd.img*). Mais c'est bien de savoir qu'il existe des solutions qui évitent ces problèmes.

    • [^] # Re: LUKS

      Posté par  . Évalué à 2.

      > un "entête" que LUKS ajoute à la partition

      Entête qui doit absolument être sauvegardée: en cas de perte* il est impossible de récupérer les données du disque, même en ayant la clé il serait plus rapide d'utiliser directement le brute-force.

      * un disque entier crypté, c'est vite fait d'écraser l'header en réinstallant grub sur le mauvais disque, etc.

  • # Vivement btrfs

    Posté par  . Évalué à 6.

    > Pour finir de m'achever, NoNo m'a montré l'article SATA vs. SCSI reliability qui explique pourquoi vous allez aussi perdre des données...

    Il a aussi été question de ce problème dans ces dépêches http://linuxfr.org/2006/07/23/21124.html et http://linuxfr.org/~herodiade/23833.html .
    Une des conclusion des développeurs est qu'il faudrait pour Linux, et rapidement, des systèmes de fichiers plus adaptés aux gros disques (d'autant que perdre des données est un chose, perdre un superblock en est une autre). Vivement en:btrfs !

    Ce qui est amusant, c'est que c'est précisément l'inverse pour les SSD : plus le disque est gros, moins on risque d'avoir des blocks corrompus.
    Du moins c'est ce qui devrait arriver, en théorie, lorsque les fabriquants implémenteront le wear-leveling correctement...
    Val Henson a parlé de ce problème sur les SSD hier : http://valhenson.livejournal.com/25228.html

    • [^] # Re: Vivement btrfs

      Posté par  . Évalué à 4.

      Petites précisions sur l'aticle mis en lien par Benoît : quand on va voir l'article original, on voit deux choses :
      - l'exemple des 56% de chances qu'un disque ne soit pas lu entièrement est faux, puisqu'il parle 56% de chances de ne pas lire _un array RAID entier de 7 disques d'1To_, donc forcément les probabilités de foirer de chaque disque se multiplient (et 7To c'est déjà beaucoup, tout le monde n'a pas ça chez soi)
      - le gars qui a écrit l'article bosse pour une boite qui vend une solution justement "mieux" que le RAID, avec sur leur site un petit "So good, it's patented !", donc bon, faut relativiser le ton alarmiste je pense.

      Même si ce qu'il dit n'est effectivement pas si faux que ça, c'est fou ce que les infos circulant sur le net se déforment vite.

  • # Réinstallation des paquets corrompus ...

    Posté par  . Évalué à 2.

    apt-gile search "fichier" pour trouver le paquet si tu le connait pas, puis aptitude reinstall.

    ou apt-get --reinstall install

  • # Commande badblocks

    Posté par  (site web personnel) . Évalué à 5.

    Bon le swap maintenant. swapoff pour désactiver le swap, mais ensuite fsck.swap n'existe pas. Pas grave on le reformate en ext3, avec tests des blocs, et à la fin retour à un mkswap pour en refaire du swap, et swapon pour le réactiver. Pas de souci sur le swap. On ne peut pas toujours perdre.

    Pourquoi ne pas avoir simplement utilisé la commande badblocks, qui, comme son nom l’indique, permet de scanner une partition en recherchant des blocs défectueux en faisant abstraction du système de fichier qui s’y trouve (et d’ailleurs, il me semble qu’il ne soit pas nécessaire de démonter la partoche).

    • [^] # Re: Commande badblocks

      Posté par  (site web personnel) . Évalué à 3.

      Parce que badblocks dit « Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important that the block size is properly specified, since the block numbers which are generated are very dependent on the block size in use by the filesystem. For this reason, it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs. ».

      Et que de toute façon il faut ensuite donner la liste des badblocks à fsck (ou mkfs) pour les exclure.

      • [^] # Re: Commande badblocks

        Posté par  . Évalué à 4.

        Euh, et t'as remis un swap derrière après ? parce que du coup, la liste de badblock elle doit sauter si tu effaces le fs ...

        Après recherche, dans mkswap t'as une option "-c" aussi

        • [^] # Re: Commande badblocks

          Posté par  (site web personnel) . Évalué à 3.

          > Euh, et t'as remis un swap derrière après ? parce que du coup, la liste de badblock elle doit sauter si tu effaces le fs ...

          En même temps y en avait pas de badblocks sur la partition de swap...

          Et je viens de revérifier une nouvelle fois avec swapoff, mkswap -c -c, swapon et y en a toujours pas de détecté.

          Par contre...
          debsums: checksum mismatch libgnomevfs2-0 file /usr/lib/libgnomevfs-2.so.0.2200.0

  • # zfs de sun

    Posté par  (site web personnel) . Évalué à 2.

    Des personnes font tourner sur des To de donnés sans jamais avoir vu d'erreurs de CRC de blocs.

    J'imagine que c'est la différence entre disque ATA peut utilisé et disque SCSI beaucoup utilisé.

    Un disque dispose de bloc de correction de donnés. Faut-il encore lire les données pour les vérifier. Des données "oubliées" dans un coin du disques peuvent se détruire toute seul.

    Si les bits ECC ne sont pas suffisant ou bien si le taux d'erreurs arrivent à un seuil élevé le bloc est marqué mauvais, et le disque en utilise un autre, faut-il qu'il reste des blocs de libre.

    Pour attraper toutes les erreurs, il faudrait faire un scrubbing du disque de temps en temps (dd if=/dev/sda of=/dev/null ?).

    Et un cas d'erreur, il faut le changer rapidement. Si les erreurs persistent, cela peut aussi venir d'un mauvais câble ou d'un mauvais branchement (les erreurs RAM aussi). Par exemple, sur les cables PATA, il n'y a pas de correction d'erreur. Une erreur à ce niveau là passe inaperçu. (idem pour le PCI pas express)

    "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.