Forum

Bonjour,

Gros problème à l'instant sur mon PC de bureau : il s'est bloqué alors que j'étais sur wine (jeu de belote).
Pas possible de redémarrer Mageia.
J'ai trouvé un live CD de Gparted qui a bien démarré mais sur les 2 partitions du SSD ( / et /home) j'ai le message suivant :
Même message pour /dev/sda2

Y a-t-il une solution ?
Merci

Bonjour,
Aïe !
Il faudra exécuter un fsck /dev/sda1 et 2, depuis soit le disque Gparted s'il le permet, soit avec un autre disque Live.

Je viens de lancer une clé USB d'installation de Mageia 7, j'ai pris la ligne réparation, puis je suis passé en ligne de commande . Un fdisk - l ne m'a pas donné d'infos anormales.Puis j'ai rebooté sur le SSD et Mageia est repartie.Ouf ! mais inquiétant.....
Merci pour ta réponse, je pense qu'il va falloir que je me fasse une cle live de Gparted avec une version récente, car celle que j'ai sur CDROM est trop ancienne.

Édité par DéBé Le 26/03/2020 à 19h01

Bonjour,
les problèmes continuent :
J'ai téléchargé la dernière version de Gparted live ( https://downloads.sourceforge.net/gparted/gparted-live-1.1.0-1-amd64.iso ), que j'ai mis sur une clé USB (avec unetbootin comme conseillé), elle démarre bien sur le notebook Asus, mais rien à faire sur le desktop. Je n'arrive même pas à afficher grub . Je précise que Mageia fonctionne de nouveau sur ce dernier.

Est-ce un problème Uefi ? Le notebook est en Uefi, pas le desktop.

Édité par DéBé Le 27/03/2020 à 10h33

La réparation du grub n'est pas la réparation du file system...

Fais ce que t'a indiqué Papoteur.

Qui a dit que je voulais réparer Grub ?

D'accord, pas toi, mais tu n'as pas fait ce que t'a proposé Papoteur. C'est le file system qui déconne.

En lisant mieux mon message, tu aurais compris que, voulant tester ce que Papoteur m'a proposé, j'ai essayé de faire une clé usb live de Gparted, mais que celle-ci ne démarre pas sur le PC en question.
Par contre, @ Papoteur, j'ai fait une clé USB live de Mageia 7,qui, elle, a bien démarré, et j'ai passé les commandes suggérées, qui n'ont rien donné de suspect :

résultat identique pour /dev/sda2.

Comprenne qui pourra. Tant que ça re-fonctionne ....

Édité par DéBé Le 27/03/2020 à 17h20

Sans doute rien à voir avec l'obstacle que rencontre DéBé :
pour ne pas trop affoler leurs heureux possesseurs, il est possible de lire le lien que donne Marc Quinton le 26 courant dans linuxfr sur certains SSD (disques statiques) de marque HP.
Comme le lien est noté positif (2 actuellement), la cible est sans doute bonne à lire pour les heureux ci-dessus.
https://linuxfr.org/users/quinton/liens/vos-disques-hp-ont-ils-perdu-la-tete/

Ou plus directement :
https://www.bleepingcomputer.com/news/hardware/hpe-warns-of-new-bug-that-kills-ssd-drives-after-40-000-hours/

En quelques mots : à défaut de se dépêcher de modifier par mise à jour le microcode du disque avant 40000 heures d'utilisation, le contenu est définitivement perdu. Quarante mille heures divisées par (365 x 24) = 4,56621 ans ou encore 4 ans et 206 jours.

Il s'agit de disques professionnels bien sûr, mais de marque Sandisk (je raccourcis). Et comme je possède une clé usb de cette marque depuis 4 ou 5 ans achetée en magasin tout public, il n'est pas insensé de se renseigner pour ceux qui ont des SSD Sandisk, pros ou non. Pour la clé en question, le quota d'heures ne sera jamais atteint, mais un ssd 24/24 oui

Bonjour,

Merci pour le lien pour le nouveau bug concernant les 40000 heures...

Édité par nic80 Le 28/03/2020 à 14h41

Bonsoir Alp1,
merci pour les infos. Sur le PC concerné, la marque du SSD est Kingston.