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

Avell Diroll avelldiroll at yahoo.fr
Jeu 13 Déc 18:49:38 UTC 2007


Lami René wrote:
> Avell Diroll a écrit :
(snip)
>>> 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.
>>   
> Bonjour Ju,
> 
> Encore une fois, merci pour votre aide !
> 
> D'ajouter la ligne « # kopt_2_6=root=/dev/sda3 ro » après, ne fonctionne
> pas plus, la commande « update-grub », efface cette ligne et n'en tient
> pas compte.

Visiblement ubuntu modifie le comportement standard de update-grub par
rapport à Debian ... le bug étant déjà déclaré, il peut être utile de le
relancer si il n'a pas évolué depuis longtemps (en ajoutant son
expérience personnelle par exemple).

>>>> ...  
>>>>       
>>> 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?
>>   
> Oui, dès l'écran de connexion de Kubuntu le disque dur est sollicité à
> toutes 1 à 3 secondes.

Le problème est donc dû à un service qui n'est pas activé lorsque l'on
boot en rescue-mode (probablement).

>> Serait il possible de créer un nouvel utilisateur (test) et de se loguer 
>> en tant que test, pour voir si le probleme persiste?
>>   
> Il y a longtemps que j'y avais pensé et essayé cette solution, mais il y
> a le même problème. En fait, comme le problème est déjà présent lors de
> la connexion au système, tout ce qui est fait après la connexion traine
> le problème.

entièrement d'accord

>>>> ...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
>>   
> J'ai procédé à l'installation de xfce4 avec la commande « sudo aptitude
> install xfce4 » et tout s’est bien passé, KDE n'est pas perturbé, mais
> cela ne change rien que je me connecte avec mon compte rene ou mon
> compte test. Existe-t-il une commande équivalente pour installer Gnome,
> sans perturber KDE et xfce4 ?

C'est possible, mais ça ne résoudra probablement pas le problème. Je
tenterais un :
sudo aptitude install gnome

Sinon j'ai eu un peu plus de temps pour réfléchir et trouver un moyen
d'avoir un log plus détaillé des accès disques. Serait-il possible
d'executer les commandes suivantes dans un terminal puis de poster le
contenu du fichier diskaccess.log dans la réponse à ce mail (je peux
expliquer chaque lignes si elles ne parlent pas d'elles même):


sudo -s
echo 1 > /proc/sys/vm/block_dump
/etc/init.d/sysklogd restart

#Attendez 5 minutes en verifiant que le problème se pose bien pendant
#ce temps ... limitez au maximum le nombre de programme ouvert ainsi
#que l'utilisation de l'ordi (désactiver le screensaver peut être une
#bonne idée)

dmesg | awk '/(READ|WRITE|dirtied)/ {activity[$2]++} END {for (x in
activity) print x, activity[x]}' | sort -rn -k2 | head -50 > diskaccess.log

#Attention: les 3 lignes précédentes représentent une seule ligne
#de commande

echo 0 > /proc/sys/vm/block_dump
/etc/init.d/sysklogd restart



Le fichier diskaccess.log se trouve alors dans le répertoire courant (et
appartient à l'utilisateur root)

(ces infos sont inspirées de:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/17878
)

En esperant que ça puisse donner un peu plus d'info ...

Bonne continuation

Ju
-- 
There is room for all of the Universe's creatures....right beside the
mashed potatoes.




Plus d'informations sur la liste de diffusion ubuntu-fr