Forum

Bonjour,

Voilà trois fois que mon PC s'éteint brutalement et un peu aléatoirement.

Un petit historique s'impose.

1) La première fois, après deux extinctions brutales, j'ai redémarré sur Debian 8 (au lieu de Mageia 4) immédiatement et sans problème, y-compris la procédure de vérification des partitions. J'en ai profité pour vérifier que la partition Mageia était saine.

2) Redémarrage immédiat sous Mageia et sans problème.

3) Une jolie suite de démarrages réussis s'ensuit pendant plusieurs jours.

4) Rebelote ! Mageia 5 (5 au lieu de 4 parce que j'ai upgradé entretemps sans problème) démarre, commence sa procédure programmée fsck et plante. Machine éteinte !

5) Je redémarre sur PartedMagic (live CD) afin de pouvoir lancer un processus de vérification de chaque partitions puisque aucunes ne seront montées et utilisées. La commande fsck (sous PartedMagic en mode Live CD) n'a rien révélé. Toutes les partitions sont saines. Absolument toutes.

6) Pensant alors à un problème plus physique, j'ai pensé aux données SMART. Sous Linux, ces données SMART peuvent être relevées avec l'application gsmartcontrol. Et là, effectivement, je trouve un disque (SDE1) avec des données SMART inquiétantes. A priori, des clusters sont en train de lacher mais comme le disque est encore sous garantie, jai renvoyé au fabricant le disque dur ayant des erreurs SMART.

7) Ce disque dur problématique (SDE1) a été remplacé par un autre. Il va de soi que j'ai auparavant vérifié l'état du nouveau disque et ses données SMART sont excellentes. Le fichier fstab a été modifié en conséquence.

8) La machine a démarré correctement plusieurs fois.

9) Pourtant, le démarrage de Mageia 5 s'est mal passé aujourd'hui !

* En effet, un contrôle fsck était obligatoire sur deux disques (SDD1 et SDF1) car ils ont été montés déjà 20 fois.
* Donc, au démarrage de Mageia 5 (à jour), fsck se lance sur le premier disque dur à contrôler et plante après, environ, 33% puis la machine s'éteint.
* Je redémarre un nouvelle fois avec le même échec. A vrai dire, je m'y attendais mais j'espérais faire une photo de l'écran. Cependant, cette photo ne révèle rien : ni fichier journal, ni indication quelconque d'un problème.

10) Je redémarre sur PartedMagic en mode LiveCD et je lance plusieurs contrôles :
* contrôles fsck de toutes les partitions, y compris SDD1 et SDF1 : pas de problème
* relevé de nouvelles données SMART (gsmartcontrol) : aucun problème

11) Je redémarre sur memtest86 (sait-on jamais). Pas de problème .... bien que vue la longueur de l'opération je ne sois pas allé au bout. Et à vrai dire, je compte relancer ce test un matin (à cause de sa durée) mais quand il fera (si possible) un peu moins chaud.

12) En résumé :
* La tour est propre, sans poussière, partout.
* Le problème ne survient que lorsqu'il faut lancer le contrôle fsck depuis le système d'exploitation.
* Ce même problème n'apparait pas lorsque le contrôle fsck est lancé en mode LiveCD depuis PartedMagic, puisque la procédure fsck va au bout sans extinction de la machine. Même sur un disque de 2To où le contrôle fsck est vraiment long (près d'une heure de temps).

Une piste à suivre : démarrer plusieurs fois Debian 8 jusqu'à obtenir la nécessité du contrôle fsck dans le but de comparer ? Une idée ?

Merci par avance

Oui, effectivement, mais existe-il un risque à aller si loin ? Par exemple, puisque nous sommes en été, je pense à une coupure brutale du à une surtension. La machine ayant été éteinte brutalement, certains fichiers risquent d'être plus ou moins corrompus. Et attendre trop longtemps pour corriger cette corruption ne serait-elle pas risquée ?

En lisant ton 1er post, je pensais immédiatement à une surchauffe du proc. Ce phénomène crée un arrêt d'urgence immédiat et très brutal. Comme on est en été, tu devrais aller voir du coté des ventilos.
inxi -F
te donnera des indications. Au besoin
urpmi inxi

sensors

Chez moi le CPU est a 68 ° et le ventilo tourne bien.

Édité par thierryR Le 17/07/2015 à 17h13

Mille fois oui, thierryR; sans compter qu'il faut changer la pâte thermique entre processeur et ventillateur (ou le caloduc) tous les deux-trois ans.

Mais le pire (sans excès, bien sûr) c'est que si Debian8 et PartedMagic mènent leur fsck à destination, ça peut vouloir dire qu'il y a un problème acpi avec la mga 5. Il faudrait prendre un noyau debug pour voir à quel endroit ça coince pour ce matériel particulier

J'avais pensé à une surchauffe bien que tout l'intérieur de la machine soit maintenu propre. Et comme le processus fsck va au bout avec Debian et PartedMagic, je pensais aussi à un possible bug sous Mageia.



Voici les résultats :



En résumé, le processeur est à 41°, largement en deçà du seuil haut (95°) ou critique (105°) tandis que tous les ventilos tourent correctement.



Ma question était si le fait de rehausser l'intervalle entre deux contrôles fsck n'est-il pas dangereux avec un risque de corruption de fichier trop pénible à rectifier. Actuellement, le contrôle fsck se fait tous les 20 montages.



Je pense quand même tester avec Debian la procédure fsck, quitte à raccourcir temporairement le délai entre deux montages. Au moins pour vérifier.

Effectivement ce n'est pas critique actuellement. Il faudrait voir après une coupure.

Pour vérifier ton DD
Dans smartctl -a /dev/sdx ou x est ton DD
Peux tu donner les valeurs de :
3 paramètres à bien surveiller :
1. Reallocated_Sector_Ct doit être égale à 0
2. Power_On_Hours doit être inférieur à 50 000 Heures
3. "Load_Cycle_Count" est proche de 600000

Tu peux installer gsmartcontrol qui t'indiquera en rouge des erreurs critiques.

Je surveille régulièrement désormais avec gsmartcontrol et tous les disques sont au vert : aucune erreur critique.



Je rappelle que j'ai changé le disque dur où gmsmartcontrol me relevait en rouge des erreurs critiques. Ce disque dur a été renvoyé au SAV chez le fabricant.



Pour le moment, je surveille aussi le moment où les 20 montages arriveront pour faire une comparaison directement avec Debian 8. Je pourrais aussi raccourcir le délai entre 2 fsck pour précipiter l'analyse mais, vu la chaleur ambiante, je préfère patienter un peu.

Je confirme le bug du côté de Mageia.

Pour rappel, mon système est multi-boot :
* SDA2 : Mageia 5 Cauldron
* SDA3 : Fedora 22
* SDA5 : Debian 8.1
* SDB1 : Mageia 5 (système principal)

Je précise aussi que, quel que soit le système démarré, ce sont systématiquement les mêmes partitions qui sont montées. Par conséquent, chaque démarrage d'un quelconque système incrémente le compteur fsck à l'identique.

Si le contrôle fsck se fait sous Mageia 5 (lorsque programmé), c'est le plantage assuré. Actuellement, le résultat est le même avec Mageia 5 SDB1 (SSD) et Mageia 5 Cauldron (Velociraptor) puisque les deux versions sont encore identiques.

Par contre, aucun problème avec le même contrôle fsck sous Debian et Fedora.

J'en suis à pîster le moment où un nouveau contrôle fsck devra être effectué pour démarrer sur Debian ou Fedorra. Et j'attends aussi la montée en développement de Cauldron pour tester de ce côté.

Du nouveau :

Pour information, j'ai été amené à installer dernièrement une version minimale de Mageia 5 pour régler un autre problème. Ce matin, nouveau contrôle fsck obligatoire. Je redémarre donc sur cette toute fraîche installation Mageia 5 minimale qui me débute le contrôle fsck puis ..... plante comme les autres installations Mageia 5 plus ancienne et complète.

Je rappelle que, même si ces contrôle fsck portent sur de grandes partitions (2 To, ce qui est long à traiter), ce même contrôle ne pose strictement aucun problème avec Debian 8.2 et Fedora 22. Ca bugge chez Mageia ?!

Salut,
je n'ai vu aucun rapport de bogue avec un problème de ce genre. Ceci doit donc être lié à une configuration très particulière.
Désolé, çà va être difficile de t'aider.
As-tu comparé les versions entre Mageia et Debian ?

Pas encore mais principalement parce que je ne sais pas quoi comparer.

Je relance le sujet puisqu'il persiste encore et toujours !

Pour rappel :
* SDB1 : Mageia 5.1 (sur SSD) : plantage systématique fsck et extinction machine
* SDA2 : Mageia 5.1 (Velociraptor) : plantage systématique fsck et extinction machine
* SDA3 : Fedora 25 : fsck va jusqu'au terme de sa mission et le système se lance ensuite correctement
* SDA5 : Debian 8 : fsck va jusqu'au terme de sa mission et le système se lance ensuite correctement
* SDA6 : Manjaro 16.10 : fsck va jusqu'au terme de sa mission et le système se lance ensuite correctement
* SDC1 : Home où sont regroupés tous les profils de tous les systèmes (sous des noms différents)
* Ce problème n'existait pas dans les premiers temps de Mageia. Il n'est apparu que sous Mageia 5 et seulement en cours de vie de cette version.

Donc ce matin, en redémarrant Mageia SDA2, le contrôle fsck de la partition Home (SDC2) m'a éteint le PC sans même être allé au terme de sa mission. J'ai redémarré sur Manjaro dans la foulée et ce système (fraichement installé) m'a correctement fait son contrôle fsck.

C'est très pénible parce que chaque fois que je constate qu'un contrôle fsck se lance, je suis obligé de redémarrer sauvagement la machine (méthode bourrin, stupide et improductive à terme) afin de sélectionner dans mon multi-boot l'une des autres alternatives (Debian ou Fedora voire Manjaro) pour assurer un contrôle fsck correct et être tranquile pour 20 cycles de montage de partition.

Oui, je sais qu'on peut paramétrer la vérification des disques mais ce n'est pas la solution.

D'autre part, je ne vois rien dans ma configuration qui pourrait expliquer plus ou moins ce problème (puisque pas de problème avec les autres distributions qui pourtant ont toutes le même schéma de montage des partitions).

J'attends avec impatience la sortie de Mageia 6 en espérant mon problème solutionné

Edit :
GSmartControl me donne pour tes les disques aucune erreur.

Édité par teutates Le 25/02/2017 à 15h47

Je reviens (encore) sur le sujet. Suite à une discussion lors de la dernière réunion de l'association Linux Ariège, il semblerait que ce problème de contrôle fsck amenant l'extinction systématique de la machine ait sa source dans une bibliothèque perl. Reste à trouver laquelle .....