Dernièrement, j'ai perdu un disque dur secondaire. L'analyse des données SMART étant effrayante, j'ai vérifié les autres disques pour, finalement, comprendre la cause possible d'un autre problème sur le disque où est installé mon système. Le remplacement m'a fait trébuché sur d'autres ennuis.
En fait, après un redémarrage impossible, j'ai réussi à isoler la panne qui provenait d'un disque dur défectueux. Dans un premier temps, le système me demandait d'effectuer un fsck (fsck /dev/sdXy) manuel et sans option pour réparer les erreurs. L'opération lancée en démarrant sur le LiveCD PartedMagic (car plus facile) a finalement échoué sans jamais solutionner. Je me suis même retrouvé avec un disque sans table de partition ! Peut-être ai-je fait une connerie ?! Quoi qu'il en soit, j'ai du redémarrer sur le LiveCD PartedMagic afin de commenter la ligne se rapportant à ce disque dans le fichier /etc/fstab.
Les disques durs de dernière génération bénéficient de la technologie SMART. SMART : un système intégré au disque dur dans le but d'informer sur son état de santé. Sous GNU/Linux, il existe l'utilitaire fenétré gsmartcontrol, une application passant par l'utilitaire smartmontools. Sous Windows, visualiser ces données SMART est encore plus facile.
Tous mes disques possèdent cette technologie SMART.
Sous GNU/Linux, je ne sais pas lire, interpréter les résultats SMART. J'ai donc du redémarrer sous Windows pour passer par Acronis Drive Monitor (gratuit) et découvrir un bien piètre résultat. Et le mot est faible avec 2% seulement d'état de santé ! L'agonie à en juger Acronis Drive Monitor.
Autant dire que je n'ai n'ai jamais pu récupérer quoi que ce soit sur ce disque (ne contenant que diverses données). Même pas avec TestDisk (fourni avec la grande majorité des distributions GNU/Linux mais aussi disponible pour Windows).
L'analyse avec l'utilitaire de Seagate échoue systématiquement.
Encore un disque à plateaux ne contenant que mes systèmes d'exploitation. Cette fois l'état de santé affiché par Acronis Drive Monitor est de 72%. Pas catastrophique mais qui invite déjà à prévenir la grosse panne. D'autre part, je n'ai jamais pu réaliser d'image de sauvegarde de SDA2, ni avec Norton Ghost 15, ni avec Acronis True Image 2012 et 2013, ni avec PartImage. J'avais du me rabattre vers la ligne de commande sauce Linux. Peut-être que ce 72% explique l'impossibilité de réaliser cette image de partition ?!
J'ai pris les devants en analysant ce disque avec l'utilitaire de Western Digital. Analyse qui échoue également !
Tout en contactant mon vendeur afin de faire jouer la garantie pour ces deux disques, j'ai commandé deux nouveaux disques.
Le plus facile. Après l'avoir formaté (vive GParted), il suffit de le changer puis de modifier le fichier /etc/fstab :
1) décommenter la ligne précédemment commentée
2) modifier la valeur UUID par la nouvelle.
Après avoir copié SDA1 (Windows), SDA3 (Fedora 19), SDA5 (Debian Wheezy 7), SDA7 (Manjaro) et SDA9 (Swap Linux), j'ai permuté le nouveau disque et l'ancien pour finallement installer directement Mageia 3 sur SDA2. En effet, sachant déjà qu'il m'était impossible de réaliser une image de SDA2, je savais bien qu'il serait aussi impossible de cloner. J'avais donc laissé la place SDA2 libre, à taille strictement exacte, le plus simple étant donc d'installer directement la nouvelle version sur une partition vierge. Passons sur une installation classique et sans encombre, avec un Grub legacy installé sur le MBR de SDA.
C'est le redémarrage qui est réellement intérressant. Impossible de démarrer sur ce disque SDA car je "tombe" directement sur SDB, le SSD. Or, j'avais tout remonté à l'identique. De fait, j'ai du aller dans le BIOS (UEFI) pour remettre en position 1 le disque VelociRaptor à la place du SSD. J'avoue ne pas avoir compris cette modification automatique du BIOS dans la mesure où je n'ai jamais démarré la machine sans le VelociRaptor (ancien comme neuf). Et là, enfin le Grub du VelociRaptor, celui fraichement installé.
Les ennuis ne sont pas vraiment terminés ! La distribution Mageia 3 sur SDA2 fonctionne mais pas les autres. L'explication vient de la valeur UUID qui a été modifiée lors du clonage. Je pensais (bêtement) qu'un clonage préserverait cette valeur : perdu ! Le Grub principal chaîne les distributions sans jamais utiliser de notion d'UUID. Par contre, les fichiers /etc/fstab de toutes les distributions utilisent cette notion d'UUID pour pointer vers les partitions. Il m'a donc fallu modifier les UUID pointant vers les racines du système et la partition Swap.
A voir aussi :
http://doc.ubuntu-fr.org/smartmontools
http://wiki.mandriva.com/fr/Smart_:_Analyser_et_%C3%A9valuer_l%27%C3%A9tat_de_son_disque_dur
http://wiki.debian-facile.org/commande:smartmontools
En fait, après un redémarrage impossible, j'ai réussi à isoler la panne qui provenait d'un disque dur défectueux. Dans un premier temps, le système me demandait d'effectuer un fsck (fsck /dev/sdXy) manuel et sans option pour réparer les erreurs. L'opération lancée en démarrant sur le LiveCD PartedMagic (car plus facile) a finalement échoué sans jamais solutionner. Je me suis même retrouvé avec un disque sans table de partition ! Peut-être ai-je fait une connerie ?! Quoi qu'il en soit, j'ai du redémarrer sur le LiveCD PartedMagic afin de commenter la ligne se rapportant à ce disque dans le fichier /etc/fstab.
1 - Causes
Les disques durs de dernière génération bénéficient de la technologie SMART. SMART : un système intégré au disque dur dans le but d'informer sur son état de santé. Sous GNU/Linux, il existe l'utilitaire fenétré gsmartcontrol, une application passant par l'utilitaire smartmontools. Sous Windows, visualiser ces données SMART est encore plus facile.
Tous mes disques possèdent cette technologie SMART.
1.1 - Disque dur secondaire (Seagate Barracuda 7200 tours)
Sous GNU/Linux, je ne sais pas lire, interpréter les résultats SMART. J'ai donc du redémarrer sous Windows pour passer par Acronis Drive Monitor (gratuit) et découvrir un bien piètre résultat. Et le mot est faible avec 2% seulement d'état de santé ! L'agonie à en juger Acronis Drive Monitor.
Autant dire que je n'ai n'ai jamais pu récupérer quoi que ce soit sur ce disque (ne contenant que diverses données). Même pas avec TestDisk (fourni avec la grande majorité des distributions GNU/Linux mais aussi disponible pour Windows).
L'analyse avec l'utilitaire de Seagate échoue systématiquement.
1.2 - Disque dur principal (Western Digital VelociRaptor de 300 Go à 10000 tours)
Encore un disque à plateaux ne contenant que mes systèmes d'exploitation. Cette fois l'état de santé affiché par Acronis Drive Monitor est de 72%. Pas catastrophique mais qui invite déjà à prévenir la grosse panne. D'autre part, je n'ai jamais pu réaliser d'image de sauvegarde de SDA2, ni avec Norton Ghost 15, ni avec Acronis True Image 2012 et 2013, ni avec PartImage. J'avais du me rabattre vers la ligne de commande sauce Linux. Peut-être que ce 72% explique l'impossibilité de réaliser cette image de partition ?!
J'ai pris les devants en analysant ce disque avec l'utilitaire de Western Digital. Analyse qui échoue également !
2 - Changement de disque
Tout en contactant mon vendeur afin de faire jouer la garantie pour ces deux disques, j'ai commandé deux nouveaux disques.
2.1 - Disque dur secondaire (Seagate Barracuda)
Le plus facile. Après l'avoir formaté (vive GParted), il suffit de le changer puis de modifier le fichier /etc/fstab :
1) décommenter la ligne précédemment commentée
2) modifier la valeur UUID par la nouvelle.
2.2 - Disque dur principal (Western Digital VelociRaptor)
Après avoir copié SDA1 (Windows), SDA3 (Fedora 19), SDA5 (Debian Wheezy 7), SDA7 (Manjaro) et SDA9 (Swap Linux), j'ai permuté le nouveau disque et l'ancien pour finallement installer directement Mageia 3 sur SDA2. En effet, sachant déjà qu'il m'était impossible de réaliser une image de SDA2, je savais bien qu'il serait aussi impossible de cloner. J'avais donc laissé la place SDA2 libre, à taille strictement exacte, le plus simple étant donc d'installer directement la nouvelle version sur une partition vierge. Passons sur une installation classique et sans encombre, avec un Grub legacy installé sur le MBR de SDA.
C'est le redémarrage qui est réellement intérressant. Impossible de démarrer sur ce disque SDA car je "tombe" directement sur SDB, le SSD. Or, j'avais tout remonté à l'identique. De fait, j'ai du aller dans le BIOS (UEFI) pour remettre en position 1 le disque VelociRaptor à la place du SSD. J'avoue ne pas avoir compris cette modification automatique du BIOS dans la mesure où je n'ai jamais démarré la machine sans le VelociRaptor (ancien comme neuf). Et là, enfin le Grub du VelociRaptor, celui fraichement installé.
Les ennuis ne sont pas vraiment terminés ! La distribution Mageia 3 sur SDA2 fonctionne mais pas les autres. L'explication vient de la valeur UUID qui a été modifiée lors du clonage. Je pensais (bêtement) qu'un clonage préserverait cette valeur : perdu ! Le Grub principal chaîne les distributions sans jamais utiliser de notion d'UUID. Par contre, les fichiers /etc/fstab de toutes les distributions utilisent cette notion d'UUID pour pointer vers les partitions. Il m'a donc fallu modifier les UUID pointant vers les racines du système et la partition Swap.
Remarque :
La commande (sous droit root) blkid donne en console les valeurs UUID de toutes les partitions, ce qui peut éviter d'ouvrir GPartedA voir aussi :
http://doc.ubuntu-fr.org/smartmontools
http://wiki.mandriva.com/fr/Smart_:_Analyser_et_%C3%A9valuer_l%27%C3%A9tat_de_son_disque_dur
http://wiki.debian-facile.org/commande:smartmontools
Commentaires
Enregistrer un commentaire