L'activité de mon disque dur m'inquiète !

[Avell Diroll]

Lami René wrote:
> Avell Diroll a écrit :
>> Lami René wrote:  
>>> Avell Diroll a écrit :
>>>> Lami René wrote:

(snip :uuid)

> Bonjour Ju,

Bonjour,

(snip)


>>>> linux-386 est destiné aux pentium I et 486, tous les processeurs plus
>>>> récents devraient utiliser linux-generic.
>>>>       
>>> Donc, jugerez-vous de tout simplement retirer les entrées concernant le
>>> 386, j'utilise dans les faits un processeur Pantium III 933 MHz d'Intel ?
>>>     
>> A priori ces entrées ... et les paquets associés ne correspondent pas à
>> votre matériel, supprimer les paquets correspondant dans synaptic
>> devrait retirer ces "entrées" du menu.lst automatiquement.
>>   
> Alors, je procède à la suppression complète avec Synaptic des paquets
> linux-headers-2.6.22-14-386, linux-image-2.6.22-14-386,
> linux-restricted-modules-2.6.22-14-386 et
> linux-ubuntu-modules-2.6.22-14-386.

Exactement, car ceux-ci sont inutiles sur votre machine, ils prennent de 
la place et ne doivent pas être utilisés.

>>>>> En y pensent bien, je me demande pourquoi utiliser cette commande 'sudo
>>>>> update-grub', j'ai bien modifié le fichier manuellement et les
>>>>> modifications sont prises en compte, dès le redémarrage, sans que j'ai
>>>>> eu a l'utiliser. À la lecture du manpage, je comprends que je n'en ai
>>>>> pas besoin, du fait justement que je le modifie manuellement.    
>>>>>         
>>>> update-grub sert à sauvegarder les choix à utiliser lors des mises à
>>>> jour des differents éléments nécessaires au boot (noyaux grub).
>>>>       
>>> Si je comprends ce que vous écrivez, je n'ai qu'a change dans menu.lst
>>> la ligne :
>>>
>>> # kopt=root=UUID=f03a5ea6-0043-4ed8-a3af-12b2a9d02d82 ro
>>>
>>> pour :
>>>
>>> kopt=root=/dev/sda3 ro
>>>
>>> Et lors des mises à jour de distribution ou de l'utilisation de la
>>> commande update-grub, les UUIDs ne seront plus réactivés ?
>>>     
>> Pas tout à fait, il faut remplacer la ligne:
>> # kopt=root=UUID=f03a5ea6-0043-4ed8-a3af-12b2a9d02d82 ro
>> par la ligne:
>> # kopt=root=/dev/sda3 ro
>> (notez la présence du #)
>> Puis exécuter la commande "sudo update-grub", ce qui permettra de
>> configurer la partie sans # du menu.mst et d'être pris en compte par la
>> suite.
>>   
> Cela ne fonctionne pas, j'ai remplacé la ligne, mai avec la commande
> "sudo update-grub", dans le fichier menu.lst la ligne :
> 
> # kopt=root=/dev/sda3 ro
> 
> est  remplacé automatiquement par :
> 
> # kopt=root=UUID=91126105-c7a3-499a-8d4f-9ee57a50dab9 ro
> 
> Un bogue peut-être !

On est pas loin d'un bug :
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/62195

C'est effectivement un comportement qui diffère de la documentation de 
grub (et cette manip fonctionne sous debian ... dans l'autre sens).

Il faudrait essayer de laisser la ligne kopt tranquille, mais de 
rajouter celle-ci en dessous:
# kopt_2_6=root=/dev/sda3 ro
Certaines discussions rapportent que le update-grub d'ubuntu ne 
modiefierais pas cette option, et celle-ci serait prioritaire par 
rapport à kopt ... mais je ne peux rien certifier.


>>>>> Ne m'oubliez pas, j'ai toujours les problèmes d'accès disques permanents !    
>>>>>         
>>>> J'ai survolé le fil de discussion et j'aurais aimé avoir quelques
>>>> précisions:
>>>>
>>>> 1- Pour se faire une idée de la génération de l'ordi, serait-il possible
>>>> d'avoir le résultat des commandes:
>>>> lspci
>>>> cat /proc/cpuinfo
>>>> cat /proc/meminfo
>>>> (et au passge un 'sudo fdisk -l', ça permettrai de regrouper les infos
>>>> au même endroit)
>>>>   
>>>>       
>>> Les voici :
>>>
>>> rene at PIII800:~$ lspci
>>> 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and
>>> Memory Controller Hub (rev 02)
>>> 00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
>>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 02)
>>> 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 02)
>>> 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller
>>> (rev 02)
>>> 00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1
>>> (rev 02)
>>> 00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus Controller (rev 02)
>>> 00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1
>>> (rev 02)
>>> 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97
>>> Audio Controller (rev 02)
>>> 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2
>>> MX/MX 400] (rev b2)
>>> 02:02.0 USB Controller: OPTi Inc. 82C861 (rev 10)
>>> 02:03.0 Communication controller: ESS Technology ES2838/2839 SuperLink
>>> Modem (rev 01)
>>> 02:04.0 SCSI storage controller: Advanced System Products, Inc ABP940-U
>>> / ABP960-U (rev 03)
>>> 02:05.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]
>>> (rev 43)
>>> rene at PIII800:~$
>>>
>>> rene at PIII800:~$ cat /proc/cpuinfo
>>> processor       : 0
>>> vendor_id       : GenuineIntel
>>> cpu family      : 6
>>> model           : 8
>>> model name      : Pentium III (Coppermine)
>>> stepping        : 10
>>> cpu MHz         : 937.868
>>> cache size      : 256 KB
>>> fdiv_bug        : no
>>> hlt_bug         : no
>>> f00f_bug        : no
>>> coma_bug        : no
>>> fpu             : yes
>>> fpu_exception   : yes
>>> cpuid level     : 2
>>> wp              : yes
>>> flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
>>> cmov pat pse36 mmx fxsr sse up
>>> bogomips        : 1877.25
>>> clflush size    : 32
>>> rene at PIII800:~$
>>>
>>> rene at PIII800:~$ cat /proc/meminfo
>>> MemTotal:       515840 kB
>>> MemFree:         13864 kB
>>> Buffers:          8088 kB
>>> Cached:         247852 kB
>>> SwapCached:        128 kB
>>> Active:         385260 kB
>>> Inactive:        74576 kB
>>> HighTotal:           0 kB
>>> HighFree:            0 kB
>>> LowTotal:       515840 kB
>>> LowFree:         13864 kB
>>> SwapTotal:     1076344 kB
>>> SwapFree:      1041504 kB
>>> Dirty:             568 kB
>>> Writeback:           0 kB
>>> AnonPages:      203768 kB
>>> Mapped:          83848 kB
>>> Slab:            27860 kB
>>> SReclaimable:    13936 kB
>>> SUnreclaim:      13924 kB
>>> PageTables:       2004 kB
>>> NFS_Unstable:        0 kB
>>> Bounce:              0 kB
>>> CommitLimit:   1334264 kB
>>> Committed_AS:   604556 kB
>>> VmallocTotal:   507896 kB
>>> VmallocUsed:     26024 kB
>>> VmallocChunk:   478708 kB
>>> rene at PIII800:~$
>>>
>>> rene at PIII800:~$ sudo fdisk -l
>>> [sudo] password for rene:
>>>
>>> Disque /dev/sda: 250.0 Go, 250059350016 octets
>>> 255 heads, 63 sectors/track, 30401 cylinders
>>> Units = cylindres of 16065 * 512 = 8225280 bytes
>>> Disk identifier: 0x032224e9
>>>
>>> Périphérique Amorce    Début         Fin      Blocs    Id  Système
>>> /dev/sda1   *           1        2591    20812176    c  W95 FAT32 (LBA)
>>> /dev/sda2            2592        2725     1076355   82  Linux swap / Solaris
>>> /dev/sda3            2726        4292    12586927+  83  Linux
>>> /dev/sda4            4293       30401   209720542+   5  Extended
>>> /dev/sda5            4293       17347   104864256   83  Linux
>>> /dev/sda6           17348       30401   104856223+   7  HPFS/NTFS
>>> rene at PIII800:~$
>>>     
>> Merci pour les infos, il est souvent preferable d'en avoir trop que pas
>> assez.

(snip: partage de connexion ... HS)

>>>> 2- Serait-il possible d'avoir un historique détaillé des installations
>>>> successives subies par l'ordi ... win, quelle est la première version
>>>> d'ubuntu à avoir été installée, y a t il eu des changement de versions,  
>>>>       
>>> J'ai reparti à zéro à l'époque de la dernière version STS de Kubuntu, la
>>> 6.04 je pense et j'en suis à la version 7.10 mise à jour
>>> quotidiennement. J'utilise la version Windows Xp SP2.
>>>     
>>>> ce sont ils passé sans encombre ...
>>>>       
>>> Il n'y a qu'une fois ou la migration c'est bien passé, toutes les autres
>>> m'ont donnée des difficultés avec la carte graphique et ses pilotes
>>> propriétaire où avec le fichier menu.lst et fstab, mais en apparence,
>>> pas d'autre problème.
>>>     
>>>> Y a-t-il eu des depots/paquets/logiciels non officiels installé sur cet
>>>> ordi?

(snip sources.list standard + medibuntu)

>>>
>>> Je ne saurais vous en dire bien plus.
>>>     
>> C'est tout ce que j'attendais, mais au vu du problème rencontré, il est
>> toujours préférable d'essayer d'éliminer des causes probables pour ne
>> pas se dire après coup "et si ce n'était ..."
>>   
>>>> 3- Ce disque ne présentant pas une activité particulière sous win, on
>>>> exclu tout problème materiel (pour l'instant). Il reste alors 2
>>>> possibilités, soit le materiel n'est pas reconnu correctement par
>>>> ubuntu, soit un logiciel est mal configuré.
>>>>       
>>> J'ai eu ces problèmes avec deux cartes mères différentes, trois
>>> processeurs différents et des disques durs Quantum, Maxtor et
>>> présentement Seagate, alors je ne pense pas que le problème soit
>>> matériel. Je présume davantage un problème de configuration. J'ai
>>> revérifié avec un CD de Kubuntu 7.10 et sous Windows Xp SP2 et il n'y a
>>> pas de sur activité de disque dur, alors je penche vraiment pour un
>>> problème de configuration.
>>>     
>> C'est probable effectivement, mais le test depuis un live cd n'apporte
>> rien dans ce cas précis, car le système est alors installé sur le cdrom
>> et la partie de la ram qui est alors configurée comme un disque dur
>> (attention je viens de faire un odieux raccourci sémantique). Si il y
>> avait une activité anormal sur le livecd, celle ci serait sur le cd ou
>> sur la ram ...
>>   
>>>> Le problème est il apparu au fil du temps, ou dès la première
>>>> installation d'ubuntu?
>>>>       
>>> Dans les six mois suivant la première installation.
>>>     
>> Ce qui fait penser à l'arrivée d'un logiciel ou d'une configuration
>> indélicate. Un souvenir des nouveaux logiciels expérimentés à l'époque?
>> celà correspond il à une mise à jour?
>>   
> Je ne saurais le dire !

Je m'y attendais, vous l'auriez sûrement signalé entre temps ...

>>>> Le problème persiste-t-il lorsque l'on boot en 'recovery-mode'?  
>>>>       
>>> Je ne connais presque rien de ce mode, mais voici ce que j'ai fait :
>>>
>>> Démarrage avec le Recovery-mode et lorsque demandé Ctrl+D pour
>>> poursuivre, cela ne change rien.
>>>
>>> Démarrage avec le Recovery-mode et lorsque demandé entrer le mot de
>>> passe root pour poursuivre, alors là on est sur une bonne piste, car je
>>> n'ai plus d'accès disque permanents !
>>>
>>> Docteur, qu'est-ce que cela veut dire ? J'ai démarré le serveur X avec
>>> la commande startx et toujours pas d'accès disque permanent ! Quelles
>>> sont les différences entre le démarrage normal et le mode « recovery » ?
>>> Une petite question entre parenthèses, dans le recovery mode, je me
>>> retrouve dans mon compte utilisateur habituel « /home/rene » et j'aurais
>>> voulu poursuivre la rédaction du présent courriel, mais Thunderbird
>>> semble ne pas être configuré ! Je partage mes comptes de courriel avec
>>> Thunderbird entre Kubuntu et WindowsXP. Existe-t-il une procédure simple
>>> pour corriger cela ? Cette question n'est pas prioritaire !
>>>     
>> Docteur ... pas encore mais j'y travaille :)
>> C'est une bonne nouvelle, c'est effectivement un logiciel du système qui
>> produit ces accès permanent, et celui-ci n'est a priori pas capital au
>> fonctionnement du système.
>> Le recovery-mode permet un démarrage de la machine en n'activant que le
>> strict essentiel pour pouvoir intervenir dessus, souvent en ligne de
>> commande. Bien qu'il soit possible de démarrer le mode graphique dans ce
>> mode, c'est souvent déconseillé, ici ça nous apporte une info importante
>> : même avec un serveur X chargé en mémoire le système se comporte
>> normalement.
>> Thunderbird n'y est pas configuré car l'utilisateur logué en recovery
>> mode est root (et non "rené" l'utilisateur standard de votre système
>> dont les comptes mail sont configurés).
>> Ce mode n'est à utiliser que pour régler des problèmes, il est fortement
>> déconseillé de l'utiliser au quotidien.
>>   
> Après vérification, effectivement c'est le compte root qui est utilisé.
> Méprise de ma part.
>>>> Si c'est possible, installer à neuf une gutsy sur un disque vierge (en
>>>> retirant tous les autres disques) et voir si le problème persiste? (je
>>>> conçois que tout le monde n'a pas un stock  de pièces détachées ...)
>>>>       
>>> Si je n'ai toujours pas solutionné le problème d'ici la réception du
>>> nouveau disque dur de remplacement, je ferai cette installation à neuf,
>>> mais entre temps, comme une remise à neuf d'une Kubuntu me demanderais
>>> au moins une semaine de travail complète pour tout réinstallé et tout
>>> reconfigurer, je souhaiterais, si possible faire autrement, d'autant
>>> plus, que nous venons de trouver une bonne piste pour solutionner mon
>>> problème.
>>>     
>> Une semaine me paraît bien long, surtout si on ne touche pas à /home
>> (j'ai cru comprendre qu'il était sur une partition séparée). Il faut
>> alors sauvegarder /etc /opt (c'est là qu'il est conseillé d'installer
>> tous les logiciels propriétaires) et de faire un "dpkg -l" afin
>> d'obtenir la liste de tous les paquets actuellement installés. Mais il
>> est toujours préférable de prendre son temps, je vous rejoins sur ce point.
>>   
> De plus, si le problème est de configuration, il n'est pas dit qu'après
> installation fraiche de Kubuntu, le problème soit toujours dans ma
> configuration : /home/rene/. et donc rien de résolut ! Alors, une
> installation avec un home reformaté sera requise.

Pas nécessairement, il suffit de renommer avant l'installation 
/home/rene en /home/rene_save, et de faire l'installation en créant un 
utilisateur rene, qui arrivera avec une configuration vierge. On peut 
alors ajouter les differents réglages un par un.

J'aurais une question supplémentaire:
Les accès intempestifs se produisent ils sur l'écran de login?
Serait il possible de créer un nouvel utilisateur (test) et de se loguer 
en tant que test, pour voir si le probleme persiste?

>>>> 4- Alors que le problème survient et qu'il y a un minimum d'applications
>>>> lancées, que donnent les commandes suivantes:
>>>> ps -ef
>>>> sudo lsof -U /dev/sda*  
>>>>       
>>> Avec la commande « ps -ef » dans une konsole et Thunderbird d'ouvet,
>>> rien d'autre, cela donne :

(snip: sortie de ps -ef)

>>>     
>> Parmi ces process qui tournent actuellement sur votre machine, certains
>> ne me semblent pas utiles, voir ne me plaisent pas:
>>
>> /bin/sh /usr/bin/mysqld_safe
>> /usr/sbin/mysqld
>> /usr/bin/dirmngr
>>
>> MySQL et dirmngr devraient être desinstallés ... au moins pour tester si
>> ils ne sont pas responsable de ces accès disques intempestifs
>>
>> /usr/bin/speech-dispatcher
>>
>> Si il n'y a pas d'utilisation de synthèse vocale sur cette machine, je
>> conseille de le desinstaller également
>>
>> beagled /usr/lib/beagle/BeagleDaemon.exe --replace --bg
>>   
> Les résultats de la commande « ps -ef » date de vendredi ou samedi et
> les résultats de la commande « sudo lsof -U /dev/sda* » date dimanche
> minuit. Entre temps, beagle et bien d'autres paquets furent supprimés
> complètement. J'aurais dû vous en aviser (voir mes autres courriels) !

Je n'avais pas fait attention au dates ...

>> Beagle est toujours là, alors qu'il devrait être désinstallé ...
>> surprenant ... c'est donc une piste à creuser:
>> executer :
>> killall beagled
>>   
> Comme prévu, la commande killall beagled donne :
> 
> beagled: aucun processus tué
> rene at PIII800:~$
>> puis, pour verifier qu'un mecanisme interne ne le relance pas
>> automatiquement, executer :
>> ps -ef | grep beagled
>>   
> Mais la commande ps -ef | grep beagled donne :
> 
> rene     12291 12272  0 20:05 pts/0    00:00:00 grep beagled
> rene at PIII800:~$
> 
> Il y a donc un résidu ?

Non beagle est bien supprimé ...
la commande "ps -ef | grep beagled" liste tous les processus (ps) puis 
transmet le resultat à un filtre (grep) qui n'affiche que les lignes 
contenant le mot beagled.
Ainsi ps se liste egalement lui-même ainsi que la commande grep qui 
contient forcement la valeur de son propre filtre.
Cette ligne est donc une indication que beagle ne tourne pas, car elle 
est seule et qu'il n'y a pas de ligne du genre:
beagled /usr/lib/beagle/BeagleDaemon.exe --replace --bg

>> si la ligne contenant beagled /usr/lib/beagle/BeagleDaemon.exe --replace
>> --bg ne réapparait pas et que les acces cessent, c'est que le coupable
>> est démasqué ...
>>
>> -:0
>> Ne me plait pas du tout! j'espère que c'est une erreur de formatage du
>> mail ... en tout cas, comme cette machine a exposé des serveurs à
>> internet (apache , mysql ... et peut etre d'autres), et ayant vu des
>> tutoriaux pour héberger soit même son site qui ne s'inquiète que très
>> peu de la sécurité des dits sites, il serait interessant de tester la
>> présence de rootkit sur cette machine!
>> http://doc.ubuntu-fr.org/tutoriel/que_faire_en_cas_de_serveur_compromis?s=rootkit
>> (notemment la partie "Vérification des rootkits")
>> Il est peu probable que ce soit ça, les réglages par defaut d'ubuntu
>> étant correctement sécurisé, mais il est toujours interessant de vérifier.
>>   
> Je vais regarder de près cette page après l'envoi de ma présente réponse !
>>> Avec la commande « sudo lsof -U /dev/sda* > lsof.txt », car je ne
>>> pouvait tout recopier, dans une konsole et rien d'autre, cela donne :
>>> (voir le fichier sur le Web : webestrie.com/lsof.txt)
>>>     
>> J'ai regardé le fichier en détail. On ne retrouve pas d'accès disques
>> controlés par beagle ... ce n'est peut être pas lui le coupable après
>> tout. On ne retrouve pas non plus d'accès de la part de -:0 , ce qui est
>> une bonne nouvelle ...
>> Je connais mal kde (je l'essaie une fois par an environ), tout semble
>> normal, je suis juste surpris par la quantité d'accès demandé par kde.
>> Serait-il possible de tester un DE plus léger, xfce par exemple (en
>> installant le paquet xubuntu-desktop, ou en l'installant à la main pour
>> ne pas gêner kubuntu-desktop) pour voir si le problème est toujours
>> présent quand les utilitaires kde ne tournent pas (je pense en
>> particulier au thumbnailer).
>>   
> Oui, je vais procéder prochainement, j'attends le nouveau disque dur.
> S'il y a un tuto pour l'installation manuelle de xfce, je l'utiliserai,
> si non, j'utiliserai xubuntu-desktop !

sudo aptitude install xfce4
install xdce snas toucher à une configuration existante, xfce est alors 
disponible sur l'écran de login

>>>> 5- J'ai vu dans un des messages précédents que beagled tournait sur
>>>> cette machine. Si son index n'est pas complet, il est normal que le
>>>> disque soit utilisé en permanence.
>>>> Que se passe-t-il quand on arrête beagled? (il doit y avoir un
>>>> utilitaire graphique dans les préférences)
>>>> beagled qui prennait des largesses avec les ressources disponibles a été
>>>> avantageusement remplacé par trackerd dans gutsy gibbon ... est il
>>>> envisageable de mettre à jour cet ordi?  
>>>>       
>>> Les modules « beagled » ne sont plus dans mon système, même dans
>>> Synaptic, il n'est plus listé. Mais il est peut-être à l'origine de mes
>>> problèmes. Notez que pour ce qui est de « beagled », je ne savais même
>>> pas à quoi cela servait, peut-être une dépendance de Drupal que je
>>> n'avais pas réussi à installer correctement. Je voulais moderniser mon
>>> site Web personnel, ce qui est en attente comme projet pour moi.
>>>     
>> Je ne pense pas que beagle soit une dependance de drupal, il a pu être
>> installé lors d'une mise à jour de kubuntu (je ne me rappelle plus si il
>> était installé par défaut sous feisty ... je préfère en général être
>> organisé sur mon disque plutôt que de consacrer des ressources à gérer
>> le désordre que j'aurais créé ...)
>>   
> De là, ma sauvegarde avant mes tests, mais il faut croire qu'il y en a
> qui ont passés.
>>>> J'ai cru comprendre que le processeur était un pentiumm III 800 MHz, si
>>>> c'est le cas je pense que les ressources consommées par un service
>>>> d'indexation ne sont pas compensées par le gain de productivité qu'il
>>>> fourni ... mais ceci reste mon oppinion.
>>>>       
>>> J'apprécie grandement tous les efforts que vous déployez pour m'aider.
>>> Merci !
>>>
>>> Je souhaite avoir été aussi complet dans mes réponses que ce que vous
>>> souhaitiez !
>>>     
>> Vous l'avez été, désolé de répondre un peu tard, ce we et ce début de
>> semaine ont été agités ...
>>
>> A l'instar d'autres sur cette liste (je suis sûr pour Sun Wukong) je
>> suis tenté de penser que bien qu'il soit plaisant de pouvoir identifier
>> un problème, les ressources investies pour le résoudre ne doivent pas
>> dépasser celles à conscrer à une réinstallation du système ... mais si
>> une réinstallation équivault à une semaine de travail, je comprends le
>> peu d'enthousiasme sucité par cette suggestion :)
>>
>> Bonne continuation!
>>
>> Ju
>>   
> Je partage votre opinion, et il n'est pas exclu que je procède à une
> installation fraiche, mais pas avant le retour de mon disque dur #2 pour
> que je sauvegarde la configuration actuelle.
> 
> 
> Encore merci Ju !
> 
> L'ami René

Bon courage

Ju
-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
     -Henry Spencer