Forum

Reprise du message précédent

Bonjour sylvainsjc,

Ce que tu me dis me rassure !
Explication : quand j'ai un nouveau matériel, je le "charge" afin de tester des pbs cachés. Je prends un logiciel de sauvegarde (areca, très bien je trouve) et je lance des sauvegardes en parallèle. Il y a des centaines de GB qui circulent.
Ça fait 3 ans que j'ai le matos et on va dire que je touche du bois :-)
Et parano comme je suis, je contôle la charge système avec htop et aussi la température des disques !

Re Adrien.D,

Oui, je sais bien mais psychologiquement ça interpelle :-)
C'est déstabilisant et j'aimerais savoir si nous somme nombreux à avoir cela et aussi pourquoi c'est "là" :-D

Ça ne m'empêchera pas de vous dire à tous bon appétit.

Bonjour skulls,

Mille excuses, j'ai zappé le moment pour te répondre :-)

Et en fin de compte, ma bécane contient 6 GB de RAM, alors que le fichier /proc/kcore en fait 128 TO. Comme dit ça me dérange de voir ce fichier fantôme qui a la date du jour à chaque démarrage.
C'est comme une tôle froissée sur une Jaguar (des années 90' :-D ).

JLPicard68230



Aucuns soucis pour la réponse , peut-être que je me plante mais j'avais compris que "fictivement" le fichier fait certe 128To , mais la quantité utilisée est équivalente à la RAM installé, après mon lien n'est peut-être pasfiable ou plus probable encore mon anglais pas assez costaud







Édit : Mais je comprend tout à fait que cela te gêne dans le sens ou on ne connait pas son utilité

Édité par skulls Le 26/07/2013 à 10h58

Re skulls,

Non non tu as bien lu. Je me demande si le collègue n'a pas sous-entendu mémoire virtuelle disponible sur un système 64 bits ?
Et encore, ça ne donne pas le résultat attendu :-)

C'est sûr que ça va rester une énigme, à moins que quelqu'un dans la communauté connaisse la réponse ?

Bon ap en attendant !

Salut,

La taille du fichier virtuel /proc/kcore dans une architecture 64 bits correspond à la limite maximum de ram que le système peut allouer (bonjour le nombre de barrettes pour y arriver) - source -

Pour une architecture 32 bits, c'est par contre la taille réelle de la ram physique - ne me demandez pas pourquoi

Salut sylvainsjc,

Bon ben ok, je vais pouvoir dormir sur mes 2 oreilles alors :-)
Merci pour l'info. Elle doit servir de repère pour la gestion de la mémoire via le kernel, mais je n'irai pas plus loin dans la recherche, je vais faire chauffer la machine et actuellement ça tape en Alsace !

Bonne soirée à tous !

Hello à tous !

Juste ces quelque lignes pour vous dire que je viens d'installer un DD tout neuf, et gsmartcontrol me donne les messages "old age" et "prefailure" .....
Là, j'ai trouvé plus parano que moi :-)
Par contre la ligne 197 est à 0 au lieu de 43 dans le disque en cause.

Bonne continuation et bonnes vacances pour ceux qui y sont !

Hello à tous !

Que je vous dise ...... :
Je résume. J'ai donc réinstallé le système sur le disque neuf sdc. Pas de pb, jusqu'à la fin.
Je relance sur sdc via le BIOS comme toujours fait et là, écran noir avec le curseur comme seul compagnon ...

Je cherche, je me mets en mode rescue via le DVD pour refabriquer le lanceur, et voilà-t-il pas qu'il me demande si je veux réparer sur sdb1 et sur sdb13 !

Surprise vu que sdb est le disque problématique et qu'il y est allé alors que j'installais sur sdc ?!
Snif, je suis tout triste, aurai-je dû déconnecter le câble data du disque sdb ??!! Je ne pensais absolument pas qu'il y aurait eu une interférence comme celle-là.

qu'importe sur quel disque ou tu installe, lui il prendra en compte tout les disques branchés sur ton ordi alors si dans le lot tu en as un qui des problèmes il le verra



oui tu aurais du, c'est mieux de virer les disques douteux

l'as tu laisser réparer ton disque?



oui il vaut mieux débranché le disque douteux pour l'installation quitte a la rebranché apres



si tu as un dvd live mga3 sous la main, tu peux essayer

une fois dans kde tu ouvre une consolé te logue en root (pas de mot de passe avec les live)

et tu tapes

df -hT

ce qui va te donner la liste des partitions montées

et tu verifies bien que sdb1 et sdb13 n'y soient pas

par contre si tu vois ligne du style

/dev/sdb1 ext4 97G 9,2G 83G 11% /dodo

/dev/sdb13 ext4 97G 9,2G 83G 11% /toto



tu tapes

umount /dev/sdb1 /dodo

umount /dev/sdb13 /toto



et ensuite tu tapes

fsck -y -f -v /dev/sdb1

puis

fsck -y -f -v /dev/sdb13



ca peut être long voir très long c'est selon la taille des partitions a verifier



tu peux ouvrir une console avec un dvd d'installation normal et y faire la même chose mais je me souviens plus comment c'est pour la console avec le dvd d'install



tu as le failsafe dans le menu grub du démarrage aussi qui te donne une ligne de commande, enfin bref si tu peux éviter de tout reinstaller

Édité par Visiteur Le 29/08/2013 à 21h11

Salut MadTuX !

Suite à tous mes problèmes et à la lecture de ta réponse et de celles de ceux qui m'ont répondus, je peux dire qu'en fait Linux a tenté à chaque fois de réparer avec succès les partitions réputées flinguées et qu'à chaque fois je récupérais tout......

Mais bon, amha, j'ai bien l'impression que ce n'est pas la mécanique du disque qui a lâché, mais bien l'électronique.
Car enfin, le disque a claqué quasiment 2 ans après l'achat. Et il n'a été soumis à aucune contrainte mécanique ou autre, vu qu'il était dans une tour confortablement installée dans mon bureau. :-)
Si ça ce n'est pas de l'obsolescence programmée, qu'est-ce donc ?!!

Donc, après avoir retapé mes petites grises ces derniers jours, j'ai réinstallé Mageia v3 et maintenant, ça marche du tonnerre de Zeus !!!
Et quant aux disques, je lance automatiquement un contrôle toutes les deux semaines.

Encore merci à toi et à l'équipe qui m'avez guidé dans mes recherches !