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