[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Refaire le fichier /var/lib/dpkg/available



Jean-Yves F. Barbier a écrit :
> giggz a écrit :
>> Jean-Yves F. Barbier a écrit :
>>> giggz a écrit :
>>>> Bonsoir,
>>> slut :)
>>>
>>>> Et bien tout est dans le titre :
>>>> J'ai un soucis avec /var/lib/dpkg/available. Un problem sur une ligne.
>>> pas vraiment bon ça, la dernière fois que ça m'est arrivé, c'était dû
>>> à une RAM qui avait dégagée (suite à un choc électrique)
>>
>> Ouais c'est vraiment bizarre...j'ai po mal de fichiers qui changent tout
>> seuls...enfin po mal...pour l'instant 2 ou 3. J'ai évidemment testé la
>> ram avec memtest mais il n'a rien trouvé...bizarre bizarre...
> 
> houla, pas bon DU TOUT!
> 
> les 2 solutions les plus probables:
> 
> 1- C'est quand même la RAM: teste pendant au moins une nuit (de toute
> façon,
>    l'ensemble d'une révolution de tests prend un certain temps), et
> n'oublie
>    pas que le pgm de test ne teste pas sa propre RAM... (vérifie que les
>    timings RAS/CAS du BIOS correspondent aux caractéristiques de la RAM,
>    s'il-y-a plusieurs barettes, teste les une par une ainsi que toutes les
>    combinaisons possibles)
> 
> 1b- justement, mon dernier PB de ce type ne donnait rien avec memtest+;
>     j'ai réinséré les barettes dans une autre carte mère; et là, grosse
>     surprise: j'ai eu des tas d'erreurs sur l'une d'elles (ça expliquait
>     que, comme toi, je n'avais que /var/lib/dpkg/available et 3-4 fichiers
>     corrompus: l'erreur ne devait se produire que très rarement sur la
> carte
>     d'origine)
> 
> 2- C'est le HD qui part en sucette: installe smartmontools (et commence par
>    un test long) & hddtemp; si ça ne donne rien, fait un backup et un
>    formattage avec tests destructifs (mke2fs -c -c -v /dev/hdN; et tu peux
>    prévoir la nuit, voire plus si c'est un gros HD)
> 
> Cas beaucoup plus rares (à peu près dans l'ordre):
> 
> * Ton HD ne supporte pas le bit 'umaskirq', ou bien si la carte est assez
>   ancienne le bit 'udma' (à changer avec hdparm),
> 
> * Le HD et le chipset ont un PB de cohabitation (PB type: Silicon Image
> CMD680
>   qui plante les HD si on ne les redescend pas en UDMA4 avec hdparm),
> 
> * Les connecteurs MOLEX d'alim de ton HD se sont desserés avec les
> vibrations
>   du HD & du boîtier (les resserrer en faisant pression avec un
>   micro-tournevis),
> 
> * Le(s) condo(s) électrochimique(s) de découplage(s) d'alim(s) sont en
> train de
>   claquer,
> 
> * Le chipset a pris une grosse pêche électrique,
> 
> * d° pour le CPU,
> 
> * Steve Balmer est penché sur ta photo qu'il a noyée dans du sang de
> poulet,
>   fraîchement égorgé, par une nuit de pleine lune, et il plante pleins
>   d'aiguilles dedans histoire de bien te montrer que Linux c'est caca et
>   que tu dois passer dare-dare à vista ;->
> 
> JY

Eh ben voilà un scénario peu encourageant ;)

J'ai aussi testé le disque avec smartmontools...test long, test court
plusieurs fois rien...bon c'est vrai que je n'ai pas testé une nuit la
ram...juste 3 heures...et les 2 barettes en même temps...

Pour les fichiers modifiés : ça m'est arrivé 2 fois ce mois ci (enfin je
veux dire octobre + novembre) . toujours avec icedove...étrange non ? et
là ce fichier de dpkg...

Je vais encore attednre un peu...si ça se dégrade je revends le pc :P
mais de toute façon je suis prudent...backup backup

Merci de tes conseils!!!

Ciao
GiGGz









Reply to: