Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> * steve [2005-11-30 11:41] :
>
> [...]
>
> > gettimeofday({1133346797, 410830}, NULL) = 0
> > gettimeofday({1133346797, 410870}, NULL) = 0
> > gettimeofday({1133346797, 410910}, NULL) = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> >
> >
> > Si ça vous dit quelque chose....
>
> Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est rare,
> mais cela peut arriver qu'un bit change de valeur sur un disque dur
> entraînant des effets indésirables). Tu peux le vérifier avec debsums
> par exemple.
j'ai fait un 'debsums -as'. Mais bon ça ne me dit pas grand chose à part que
certains fichiers de configuration ont été modifiés (ce dont je me doutais)
et que d'autres paquets n'en ont pas. De plus, il doit bien comparer ces
sommes par rapport à quelque chose et si ce quelque chose est lui-même
corrompu (ou hacké) ça me fait une belle jambe ;-) Donc pas très concluant
comme test.
>
> Soit tu as un problème matériel (probablement la mémoire, mais cela peut
> également être le processeur ou un autre composant qui surchauffe).
aïe ne me dis pas ça. Pas maintenant !
> Utilise memtest86 pour le vérifier.
D'après ce que j'ai compris, on ne peut pas faire cela lorsque la machine
tourne normalement, il faut booter sur une knoppix par exemple. Donc plus de
réseau, etc... . Je vais faire ça cette nuit donc.
Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> * steve <dlist@bluewin.ch> [2005-11-30 11:41] :
>
> [...]
>
> > gettimeofday({1133346797, 410830}, NULL) = 0
> > gettimeofday({1133346797, 410870}, NULL) = 0
> > gettimeofday({1133346797, 410910}, NULL) = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> >
> >
> > Si ça vous dit quelque chose....
>
> Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est rare,
> mais cela peut arriver qu'un bit change de valeur sur un disque dur
> entraînant des effets indésirables). Tu peux le vérifier avec debsums
> par exemple.
j'ai fait un 'debsums -as'. Mais bon ça ne me dit pas grand chose à part que
certains fichiers de configuration ont été modifiés (ce dont je me doutais)
et que d'autres paquets n'en ont pas. De plus, il doit bien comparer ces
sommes par rapport à quelque chose et si ce quelque chose est lui-même
corrompu (ou hacké) ça me fait une belle jambe ;-) Donc pas très concluant
comme test.
>
> Soit tu as un problème matériel (probablement la mémoire, mais cela peut
> également être le processeur ou un autre composant qui surchauffe).
aïe ne me dis pas ça. Pas maintenant !
> Utilise memtest86 pour le vérifier.
D'après ce que j'ai compris, on ne peut pas faire cela lorsque la machine
tourne normalement, il faut booter sur une knoppix par exemple. Donc plus de
réseau, etc... . Je vais faire ça cette nuit donc.
Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> * steve [2005-11-30 11:41] :
>
> [...]
>
> > gettimeofday({1133346797, 410830}, NULL) = 0
> > gettimeofday({1133346797, 410870}, NULL) = 0
> > gettimeofday({1133346797, 410910}, NULL) = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> >
> >
> > Si ça vous dit quelque chose....
>
> Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est rare,
> mais cela peut arriver qu'un bit change de valeur sur un disque dur
> entraînant des effets indésirables). Tu peux le vérifier avec debsums
> par exemple.
j'ai fait un 'debsums -as'. Mais bon ça ne me dit pas grand chose à part que
certains fichiers de configuration ont été modifiés (ce dont je me doutais)
et que d'autres paquets n'en ont pas. De plus, il doit bien comparer ces
sommes par rapport à quelque chose et si ce quelque chose est lui-même
corrompu (ou hacké) ça me fait une belle jambe ;-) Donc pas très concluant
comme test.
>
> Soit tu as un problème matériel (probablement la mémoire, mais cela peut
> également être le processeur ou un autre composant qui surchauffe).
aïe ne me dis pas ça. Pas maintenant !
> Utilise memtest86 pour le vérifier.
D'après ce que j'ai compris, on ne peut pas faire cela lorsque la machine
tourne normalement, il faut booter sur une knoppix par exemple. Donc plus de
réseau, etc... . Je vais faire ça cette nuit donc.
* steve [2005-11-30 12:22] :
> Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > * steve [2005-11-30 11:41] :
> >
> > [...]
> >
> > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > +++ killed by SIGSEGV +++
> > >
> > >
> > > Si ça vous dit quelque chose....
> >
> > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est
> > rare, mais cela peut arriver qu'un bit change de valeur sur un disque
> > dur entraînant des effets indésirables). Tu peux le vérifier av ec
> > debsums par exemple.
Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
est limité (de mémoire, environ 20 ou 30).
Pour tous les autres, cela te
permet de vérifier que le fichier présent sur le disque et la somme M D5
indiquée par le paquet sont identiques. Quand à la possibilité que les 2
soient modifiés en même temps, c'est très, très improbable
(ou alors tu
as une corruption généralisée de tes données).
> > Soit tu as un problème matériel (probablement la mémoire, mais cela
> > peut également être le processeur ou un autre composant qui
> > surchauffe).
>
> aïe ne me dis pas ça. Pas maintenant !
>
> > Utilise memtest86 pour le vérifier.
>
> D'après ce que j'ai compris, on ne peut pas faire cela lorsque la mac hine
> tourne normalement, il faut booter sur une knoppix par exemple. Donc pl us
> de réseau, etc... . Je vais faire ça cette nuit donc.
Oui, il est uniquement possible de le faire après un redémarrage de la
machine.
* steve <dlist@bluewin.ch> [2005-11-30 12:22] :
> Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > * steve <dlist@bluewin.ch> [2005-11-30 11:41] :
> >
> > [...]
> >
> > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > +++ killed by SIGSEGV +++
> > >
> > >
> > > Si ça vous dit quelque chose....
> >
> > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est
> > rare, mais cela peut arriver qu'un bit change de valeur sur un disque
> > dur entraînant des effets indésirables). Tu peux le vérifier av ec
> > debsums par exemple.
Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
est limité (de mémoire, environ 20 ou 30).
Pour tous les autres, cela te
permet de vérifier que le fichier présent sur le disque et la somme M D5
indiquée par le paquet sont identiques. Quand à la possibilité que les 2
soient modifiés en même temps, c'est très, très improbable
(ou alors tu
as une corruption généralisée de tes données).
> > Soit tu as un problème matériel (probablement la mémoire, mais cela
> > peut également être le processeur ou un autre composant qui
> > surchauffe).
>
> aïe ne me dis pas ça. Pas maintenant !
>
> > Utilise memtest86 pour le vérifier.
>
> D'après ce que j'ai compris, on ne peut pas faire cela lorsque la mac hine
> tourne normalement, il faut booter sur une knoppix par exemple. Donc pl us
> de réseau, etc... . Je vais faire ça cette nuit donc.
Oui, il est uniquement possible de le faire après un redémarrage de la
machine.
* steve [2005-11-30 12:22] :
> Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > * steve [2005-11-30 11:41] :
> >
> > [...]
> >
> > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > +++ killed by SIGSEGV +++
> > >
> > >
> > > Si ça vous dit quelque chose....
> >
> > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est
> > rare, mais cela peut arriver qu'un bit change de valeur sur un disque
> > dur entraînant des effets indésirables). Tu peux le vérifier av ec
> > debsums par exemple.
Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
est limité (de mémoire, environ 20 ou 30).
Pour tous les autres, cela te
permet de vérifier que le fichier présent sur le disque et la somme M D5
indiquée par le paquet sont identiques. Quand à la possibilité que les 2
soient modifiés en même temps, c'est très, très improbable
(ou alors tu
as une corruption généralisée de tes données).
> > Soit tu as un problème matériel (probablement la mémoire, mais cela
> > peut également être le processeur ou un autre composant qui
> > surchauffe).
>
> aïe ne me dis pas ça. Pas maintenant !
>
> > Utilise memtest86 pour le vérifier.
>
> D'après ce que j'ai compris, on ne peut pas faire cela lorsque la mac hine
> tourne normalement, il faut booter sur une knoppix par exemple. Donc pl us
> de réseau, etc... . Je vais faire ça cette nuit donc.
Oui, il est uniquement possible de le faire après un redémarrage de la
machine.
Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> * steve [2005-11-30 12:22] :
> > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > * steve [2005-11-30 11:41] :
> > >
> > > [...]
> > >
> > > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > +++ killed by SIGSEGV +++
> > > >
> > > >
> > > > Si ça vous dit quelque chose....
> > >
> > > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est
> > > rare, mais cela peut arriver qu'un bit change de valeur sur un disque
> > > dur entraînant des effets indésirables). Tu peux le vérifier avec
> > > debsums par exemple.
ben, par exemple :
debsums: checksum mismatch cron file /etc/crontab
debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf
debsums: checksum mismatch cxref file /etc/cxref/config
debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf
debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script
debsums: checksum mismatch initscripts file /etc/default/bootlogd
debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf
etc... Y'en a pas mal dans /etc. En fait la majorité.
J'ai aussi
debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids
mais ça me paraît normal, car j'ai dû faire un update-pciusb.
> Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
> est limité (de mémoire, environ 20 ou 30).
En effet:
debsums -l | wc -l
31
> Pour tous les autres, cela te
> permet de vérifier que le fichier présent sur le disque et la somme MD5
> indiquée par le paquet sont identiques. Quand à la possibilité que les 2
> soient modifiés en même temps, c'est très, très improbable
mais pas impossible, et comme je suis un peu parano, je me méfie de cette
méthode. D'ailleurs, man debsums dit :
debsums est d'une utilité limitée en tant qu'outil de sécurité, à moins
que le programme et tous les outils apparentés (dpkg, perl,
Digest::MD5, etc.) soient lancés d'un média reconnu comme sûr (comme un
cédérom de secours bootable, voir l'option --root) et que les
sommes de contrôle aient étés calculées à partir des fichiers .deb
(--generate=all) présents sur ce média ou certifiées en utilisant
l'option --md5sums.
> (ou alors tu
> as une corruption généralisée de tes données).
non, ça il ne me semble pas. En fait seul 'aptitude' merdouille.
> > > Soit tu as un problème matériel (probablement la mémoire, mais cela
> > > peut également être le processeur ou un autre composant qui
> > > surchauffe).
> >
> > aïe ne me dis pas ça. Pas maintenant !
> >
> > > Utilise memtest86 pour le vérifier.
> >
> > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la machine
> > tourne normalement, il faut booter sur une knoppix par exemple. Donc plus
> > de réseau, etc... . Je vais faire ça cette nuit donc.
>
> Oui, il est uniquement possible de le faire après un redémarrage de la
> machine.
donc ce soir, j'ai des gens qui bossent maintenant.
J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de l'utiliser
vu les warnings que l'on peut lire dans le README. Un retour sur son
utilisation serait la bienvenue. Dangereux ou pas ?
Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> * steve <dlist@bluewin.ch> [2005-11-30 12:22] :
> > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > * steve <dlist@bluewin.ch> [2005-11-30 11:41] :
> > >
> > > [...]
> > >
> > > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > +++ killed by SIGSEGV +++
> > > >
> > > >
> > > > Si ça vous dit quelque chose....
> > >
> > > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est
> > > rare, mais cela peut arriver qu'un bit change de valeur sur un disque
> > > dur entraînant des effets indésirables). Tu peux le vérifier avec
> > > debsums par exemple.
ben, par exemple :
debsums: checksum mismatch cron file /etc/crontab
debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf
debsums: checksum mismatch cxref file /etc/cxref/config
debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf
debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script
debsums: checksum mismatch initscripts file /etc/default/bootlogd
debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf
etc... Y'en a pas mal dans /etc. En fait la majorité.
J'ai aussi
debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids
mais ça me paraît normal, car j'ai dû faire un update-pciusb.
> Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
> est limité (de mémoire, environ 20 ou 30).
En effet:
debsums -l | wc -l
31
> Pour tous les autres, cela te
> permet de vérifier que le fichier présent sur le disque et la somme MD5
> indiquée par le paquet sont identiques. Quand à la possibilité que les 2
> soient modifiés en même temps, c'est très, très improbable
mais pas impossible, et comme je suis un peu parano, je me méfie de cette
méthode. D'ailleurs, man debsums dit :
debsums est d'une utilité limitée en tant qu'outil de sécurité, à moins
que le programme et tous les outils apparentés (dpkg, perl,
Digest::MD5, etc.) soient lancés d'un média reconnu comme sûr (comme un
cédérom de secours bootable, voir l'option --root) et que les
sommes de contrôle aient étés calculées à partir des fichiers .deb
(--generate=all) présents sur ce média ou certifiées en utilisant
l'option --md5sums.
> (ou alors tu
> as une corruption généralisée de tes données).
non, ça il ne me semble pas. En fait seul 'aptitude' merdouille.
> > > Soit tu as un problème matériel (probablement la mémoire, mais cela
> > > peut également être le processeur ou un autre composant qui
> > > surchauffe).
> >
> > aïe ne me dis pas ça. Pas maintenant !
> >
> > > Utilise memtest86 pour le vérifier.
> >
> > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la machine
> > tourne normalement, il faut booter sur une knoppix par exemple. Donc plus
> > de réseau, etc... . Je vais faire ça cette nuit donc.
>
> Oui, il est uniquement possible de le faire après un redémarrage de la
> machine.
donc ce soir, j'ai des gens qui bossent maintenant.
J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de l'utiliser
vu les warnings que l'on peut lire dans le README. Un retour sur son
utilisation serait la bienvenue. Dangereux ou pas ?
Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> * steve [2005-11-30 12:22] :
> > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > * steve [2005-11-30 11:41] :
> > >
> > > [...]
> > >
> > > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > +++ killed by SIGSEGV +++
> > > >
> > > >
> > > > Si ça vous dit quelque chose....
> > >
> > > Soit tu as une bibliothèque (ou un exécutable) de corrompue (c'est
> > > rare, mais cela peut arriver qu'un bit change de valeur sur un disque
> > > dur entraînant des effets indésirables). Tu peux le vérifier avec
> > > debsums par exemple.
ben, par exemple :
debsums: checksum mismatch cron file /etc/crontab
debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf
debsums: checksum mismatch cxref file /etc/cxref/config
debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf
debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script
debsums: checksum mismatch initscripts file /etc/default/bootlogd
debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf
etc... Y'en a pas mal dans /etc. En fait la majorité.
J'ai aussi
debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids
mais ça me paraît normal, car j'ai dû faire un update-pciusb.
> Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
> est limité (de mémoire, environ 20 ou 30).
En effet:
debsums -l | wc -l
31
> Pour tous les autres, cela te
> permet de vérifier que le fichier présent sur le disque et la somme MD5
> indiquée par le paquet sont identiques. Quand à la possibilité que les 2
> soient modifiés en même temps, c'est très, très improbable
mais pas impossible, et comme je suis un peu parano, je me méfie de cette
méthode. D'ailleurs, man debsums dit :
debsums est d'une utilité limitée en tant qu'outil de sécurité, à moins
que le programme et tous les outils apparentés (dpkg, perl,
Digest::MD5, etc.) soient lancés d'un média reconnu comme sûr (comme un
cédérom de secours bootable, voir l'option --root) et que les
sommes de contrôle aient étés calculées à partir des fichiers .deb
(--generate=all) présents sur ce média ou certifiées en utilisant
l'option --md5sums.
> (ou alors tu
> as une corruption généralisée de tes données).
non, ça il ne me semble pas. En fait seul 'aptitude' merdouille.
> > > Soit tu as un problème matériel (probablement la mémoire, mais cela
> > > peut également être le processeur ou un autre composant qui
> > > surchauffe).
> >
> > aïe ne me dis pas ça. Pas maintenant !
> >
> > > Utilise memtest86 pour le vérifier.
> >
> > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la machine
> > tourne normalement, il faut booter sur une knoppix par exemple. Donc plus
> > de réseau, etc... . Je vais faire ça cette nuit donc.
>
> Oui, il est uniquement possible de le faire après un redémarrage de la
> machine.
donc ce soir, j'ai des gens qui bossent maintenant.
J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de l'utiliser
vu les warnings que l'on peut lire dans le README. Un retour sur son
utilisation serait la bienvenue. Dangereux ou pas ?
* steve [2005-11-30 13:17] :
> Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> > * steve [2005-11-30 12:22] :
> > > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > > * steve [2005-11-30 11:41] :
> > > >
> > > > [...]
> > > >
> > > > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > > +++ killed by SIGSEGV +++
> > > > >
> > > > >
> > > > > Si ça vous dit quelque chose....
> > > >
> > > > Soit tu as une bibliothèque (ou un exécutable) de corrompue ( c'est
> > > > rare, mais cela peut arriver qu'un bit change de valeur sur un
> > > > disque dur entraînant des effets indésirables). Tu peux le v érifier
> > > > avec debsums par exemple.
>
> ben, par exemple :
>
> debsums: checksum mismatch cron file /etc/crontab
> debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf
> debsums: checksum mismatch cxref file /etc/cxref/config
> debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf
> debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script
> debsums: checksum mismatch initscripts file /etc/default/bootlogd
> debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf
>
> etc... Y'en a pas mal dans /etc. En fait la majorité.
>
> J'ai aussi
>
> debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids
>
> mais ça me paraît normal, car j'ai dû faire un update-pciusb.
Tu as lancé un "debsums -a" ? D'après la page de manuelle de la versi on
de testing (v2.0.19), les fichiers de configuration sont ignorés si on
ne le demande pas.
> > Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
> > est limité (de mémoire, environ 20 ou 30).
>
> En effet:
>
> debsums -l | wc -l
> 31
Ceci pour les paquets que tu as installés, il y en a un peu plus pour
tous les paquets de l'archive.
> > Pour tous les autres, cela te
> > permet de vérifier que le fichier présent sur le disque et la som me MD5
> > indiquée par le paquet sont identiques. Quand à la possibilité que les
> > 2 soient modifiés en même temps, c'est très, très improbable
>
> mais pas impossible, et comme je suis un peu parano, je me méfie de c ette
> méthode. D'ailleurs, man debsums dit :
>
> debsums est d'une utilité limitée en tant qu'outil de sécurit é, à
> moins que le programme et tous les outils apparentés (dpkg, perl,
> Digest::MD5, etc.) soient lancés d'un média reconnu comme s ûr
> (comme un cédérom de secours bootable, voir l'option --root) et qu e les
> sommes de contrôle aient étés calculées à partir de s fichiers
> .deb (--generate=all) présents sur ce média ou certifiées en ut ilisant
> l'option --md5sums.
Si tu es parano, tu fais une 2e install à l'identique de celle que tu as
et tu compares les fichiers entiers des 2 machines, pas seulement les
sommes MD5 (après tout, il y a forcément des collisions dans le calcul
des sommes MD5). Franchement, je ne crois pas qu'il soit bien nécessaire
de continuer sur cette voie avant d'être certain que ton matériel n'e st
pas en cause.
> > (ou alors tu
> > as une corruption généralisée de tes données).
>
> non, ça il ne me semble pas. En fait seul 'aptitude' merdouille.
Tu n'avais pas d'autres programmes qui plantaient à un moment donné ?
Est-ce qu'une compilation lourde (genre glibc, openoffice.org, noyau ou
autre) passe sans problème ?
> > > > Soit tu as un problème matériel (probablement la mémoire, m ais cela
> > > > peut également être le processeur ou un autre composant qui
> > > > surchauffe).
> > >
> > > aïe ne me dis pas ça. Pas maintenant !
> > >
> > > > Utilise memtest86 pour le vérifier.
> > >
> > > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la
> > > machine tourne normalement, il faut booter sur une knoppix par
> > > exemple. Donc plus de réseau, etc... . Je vais faire ça cette n uit
> > > donc.
> >
> > Oui, il est uniquement possible de le faire après un redémarrage de la
> > machine.
>
> donc ce soir, j'ai des gens qui bossent maintenant.
>
> J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de
> l'utiliser vu les warnings que l'on peut lire dans le README. Un retour
> sur son utilisation serait la bienvenue. Dangereux ou pas ?
D'après la description du paquet, oui. Le programme n'est intéressant
que si tu veux vérifier qu'un système de test tient la charge.
* steve <dlist@bluewin.ch> [2005-11-30 13:17] :
> Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> > * steve <dlist@bluewin.ch> [2005-11-30 12:22] :
> > > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > > * steve <dlist@bluewin.ch> [2005-11-30 11:41] :
> > > >
> > > > [...]
> > > >
> > > > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > > +++ killed by SIGSEGV +++
> > > > >
> > > > >
> > > > > Si ça vous dit quelque chose....
> > > >
> > > > Soit tu as une bibliothèque (ou un exécutable) de corrompue ( c'est
> > > > rare, mais cela peut arriver qu'un bit change de valeur sur un
> > > > disque dur entraînant des effets indésirables). Tu peux le v érifier
> > > > avec debsums par exemple.
>
> ben, par exemple :
>
> debsums: checksum mismatch cron file /etc/crontab
> debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf
> debsums: checksum mismatch cxref file /etc/cxref/config
> debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf
> debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script
> debsums: checksum mismatch initscripts file /etc/default/bootlogd
> debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf
>
> etc... Y'en a pas mal dans /etc. En fait la majorité.
>
> J'ai aussi
>
> debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids
>
> mais ça me paraît normal, car j'ai dû faire un update-pciusb.
Tu as lancé un "debsums -a" ? D'après la page de manuelle de la versi on
de testing (v2.0.19), les fichiers de configuration sont ignorés si on
ne le demande pas.
> > Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
> > est limité (de mémoire, environ 20 ou 30).
>
> En effet:
>
> debsums -l | wc -l
> 31
Ceci pour les paquets que tu as installés, il y en a un peu plus pour
tous les paquets de l'archive.
> > Pour tous les autres, cela te
> > permet de vérifier que le fichier présent sur le disque et la som me MD5
> > indiquée par le paquet sont identiques. Quand à la possibilité que les
> > 2 soient modifiés en même temps, c'est très, très improbable
>
> mais pas impossible, et comme je suis un peu parano, je me méfie de c ette
> méthode. D'ailleurs, man debsums dit :
>
> debsums est d'une utilité limitée en tant qu'outil de sécurit é, à
> moins que le programme et tous les outils apparentés (dpkg, perl,
> Digest::MD5, etc.) soient lancés d'un média reconnu comme s ûr
> (comme un cédérom de secours bootable, voir l'option --root) et qu e les
> sommes de contrôle aient étés calculées à partir de s fichiers
> .deb (--generate=all) présents sur ce média ou certifiées en ut ilisant
> l'option --md5sums.
Si tu es parano, tu fais une 2e install à l'identique de celle que tu as
et tu compares les fichiers entiers des 2 machines, pas seulement les
sommes MD5 (après tout, il y a forcément des collisions dans le calcul
des sommes MD5). Franchement, je ne crois pas qu'il soit bien nécessaire
de continuer sur cette voie avant d'être certain que ton matériel n'e st
pas en cause.
> > (ou alors tu
> > as une corruption généralisée de tes données).
>
> non, ça il ne me semble pas. En fait seul 'aptitude' merdouille.
Tu n'avais pas d'autres programmes qui plantaient à un moment donné ?
Est-ce qu'une compilation lourde (genre glibc, openoffice.org, noyau ou
autre) passe sans problème ?
> > > > Soit tu as un problème matériel (probablement la mémoire, m ais cela
> > > > peut également être le processeur ou un autre composant qui
> > > > surchauffe).
> > >
> > > aïe ne me dis pas ça. Pas maintenant !
> > >
> > > > Utilise memtest86 pour le vérifier.
> > >
> > > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la
> > > machine tourne normalement, il faut booter sur une knoppix par
> > > exemple. Donc plus de réseau, etc... . Je vais faire ça cette n uit
> > > donc.
> >
> > Oui, il est uniquement possible de le faire après un redémarrage de la
> > machine.
>
> donc ce soir, j'ai des gens qui bossent maintenant.
>
> J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de
> l'utiliser vu les warnings que l'on peut lire dans le README. Un retour
> sur son utilisation serait la bienvenue. Dangereux ou pas ?
D'après la description du paquet, oui. Le programme n'est intéressant
que si tu veux vérifier qu'un système de test tient la charge.
* steve [2005-11-30 13:17] :
> Le Mercredi, 30 Novembre 2005 13.04, Frédéric Bothamy a écrit :
> > * steve [2005-11-30 12:22] :
> > > Le Mercredi, 30 Novembre 2005 11.54, Frédéric Bothamy a écrit :
> > > > * steve [2005-11-30 11:41] :
> > > >
> > > > [...]
> > > >
> > > > > gettimeofday({1133346797, 410830}, NULL) = 0
> > > > > gettimeofday({1133346797, 410870}, NULL) = 0
> > > > > gettimeofday({1133346797, 410910}, NULL) = 0
> > > > > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > > > +++ killed by SIGSEGV +++
> > > > >
> > > > >
> > > > > Si ça vous dit quelque chose....
> > > >
> > > > Soit tu as une bibliothèque (ou un exécutable) de corrompue ( c'est
> > > > rare, mais cela peut arriver qu'un bit change de valeur sur un
> > > > disque dur entraînant des effets indésirables). Tu peux le v érifier
> > > > avec debsums par exemple.
>
> ben, par exemple :
>
> debsums: checksum mismatch cron file /etc/crontab
> debsums: checksum mismatch cupsys file /etc/cups/cupsd.conf
> debsums: checksum mismatch cxref file /etc/cxref/config
> debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient.conf
> debsums: checksum mismatch dhcp3-client file /etc/dhcp3/dhclient-script
> debsums: checksum mismatch initscripts file /etc/default/bootlogd
> debsums: checksum mismatch libldap2 file /etc/ldap/ldap.conf
>
> etc... Y'en a pas mal dans /etc. En fait la majorité.
>
> J'ai aussi
>
> debsums: checksum mismatch usbutils file /var/lib/usbutils/usb.ids
>
> mais ça me paraît normal, car j'ai dû faire un update-pciusb.
Tu as lancé un "debsums -a" ? D'après la page de manuelle de la versi on
de testing (v2.0.19), les fichiers de configuration sont ignorés si on
ne le demande pas.
> > Le nombre de paquets n'ayant pas de somme MD5 pour ses fichiers
> > est limité (de mémoire, environ 20 ou 30).
>
> En effet:
>
> debsums -l | wc -l
> 31
Ceci pour les paquets que tu as installés, il y en a un peu plus pour
tous les paquets de l'archive.
> > Pour tous les autres, cela te
> > permet de vérifier que le fichier présent sur le disque et la som me MD5
> > indiquée par le paquet sont identiques. Quand à la possibilité que les
> > 2 soient modifiés en même temps, c'est très, très improbable
>
> mais pas impossible, et comme je suis un peu parano, je me méfie de c ette
> méthode. D'ailleurs, man debsums dit :
>
> debsums est d'une utilité limitée en tant qu'outil de sécurit é, à
> moins que le programme et tous les outils apparentés (dpkg, perl,
> Digest::MD5, etc.) soient lancés d'un média reconnu comme s ûr
> (comme un cédérom de secours bootable, voir l'option --root) et qu e les
> sommes de contrôle aient étés calculées à partir de s fichiers
> .deb (--generate=all) présents sur ce média ou certifiées en ut ilisant
> l'option --md5sums.
Si tu es parano, tu fais une 2e install à l'identique de celle que tu as
et tu compares les fichiers entiers des 2 machines, pas seulement les
sommes MD5 (après tout, il y a forcément des collisions dans le calcul
des sommes MD5). Franchement, je ne crois pas qu'il soit bien nécessaire
de continuer sur cette voie avant d'être certain que ton matériel n'e st
pas en cause.
> > (ou alors tu
> > as une corruption généralisée de tes données).
>
> non, ça il ne me semble pas. En fait seul 'aptitude' merdouille.
Tu n'avais pas d'autres programmes qui plantaient à un moment donné ?
Est-ce qu'une compilation lourde (genre glibc, openoffice.org, noyau ou
autre) passe sans problème ?
> > > > Soit tu as un problème matériel (probablement la mémoire, m ais cela
> > > > peut également être le processeur ou un autre composant qui
> > > > surchauffe).
> > >
> > > aïe ne me dis pas ça. Pas maintenant !
> > >
> > > > Utilise memtest86 pour le vérifier.
> > >
> > > D'après ce que j'ai compris, on ne peut pas faire cela lorsque la
> > > machine tourne normalement, il faut booter sur une knoppix par
> > > exemple. Donc plus de réseau, etc... . Je vais faire ça cette n uit
> > > donc.
> >
> > Oui, il est uniquement possible de le faire après un redémarrage de la
> > machine.
>
> donc ce soir, j'ai des gens qui bossent maintenant.
>
> J'ai aussi découvert le paquet cpuburn. Mais cela me fait peur de
> l'utiliser vu les warnings que l'on peut lire dans le README. Un retour
> sur son utilisation serait la bienvenue. Dangereux ou pas ?
D'après la description du paquet, oui. Le programme n'est intéressant
que si tu veux vérifier qu'un système de test tient la charge.
Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
> D'après la description du paquet, oui. Le programme n'est intéressant
> que si tu veux vérifier qu'un système de test tient la charge.
c'est-à-dire ?
Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
> D'après la description du paquet, oui. Le programme n'est intéressant
> que si tu veux vérifier qu'un système de test tient la charge.
c'est-à-dire ?
Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
> D'après la description du paquet, oui. Le programme n'est intéressant
> que si tu veux vérifier qu'un système de test tient la charge.
c'est-à-dire ?
Hello la liste,
drôle de comportement ce matin avec plusieurs commandes:
# aptitude updte
Lecture des listes de paquets... Fait
Erreur de segmentatione des dépendances... 0%
(Remarquez comment segmentatione est écrit, avec un e à la fin..)
Si je fais un aptitude, puis un u, l'insulte est:
Ouille! J'ai reçu un SIGSEGV, je termine...
Erreur de segmentation
Ensuite si je fais un
less /var/log/syslog
Erreur de segmentation
(Tient, ça remarche d'un coup, le less)
Mais le update me sort toujours la même chose.
Une idée ?
Grazie
ps : je suis en Sarge
--
steve
jabber :
Hello la liste,
drôle de comportement ce matin avec plusieurs commandes:
# aptitude updte
Lecture des listes de paquets... Fait
Erreur de segmentatione des dépendances... 0%
(Remarquez comment segmentatione est écrit, avec un e à la fin..)
Si je fais un aptitude, puis un u, l'insulte est:
Ouille! J'ai reçu un SIGSEGV, je termine...
Erreur de segmentation
Ensuite si je fais un
less /var/log/syslog
Erreur de segmentation
(Tient, ça remarche d'un coup, le less)
Mais le update me sort toujours la même chose.
Une idée ?
Grazie
ps : je suis en Sarge
--
steve
jabber : sdl@jabber.org
Hello la liste,
drôle de comportement ce matin avec plusieurs commandes:
# aptitude updte
Lecture des listes de paquets... Fait
Erreur de segmentatione des dépendances... 0%
(Remarquez comment segmentatione est écrit, avec un e à la fin..)
Si je fais un aptitude, puis un u, l'insulte est:
Ouille! J'ai reçu un SIGSEGV, je termine...
Erreur de segmentation
Ensuite si je fais un
less /var/log/syslog
Erreur de segmentation
(Tient, ça remarche d'un coup, le less)
Mais le update me sort toujours la même chose.
Une idée ?
Grazie
ps : je suis en Sarge
--
steve
jabber :
* steve [2005-11-30 14:02] :
> Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
[...]
> > D'après la description du paquet, oui. Le programme n'est intéres sant
> > que si tu veux vérifier qu'un système de test tient la charge.
>
> c'est-à-dire ?
C.-à-d. qu'il ne va pas s'arrêter automatiquement (ou pire) s'il subit
une charge de 10 ou plus pendant quelques minutes, i.e. le CPU
surchauffe ou est surcadencé.
* steve <dlist@bluewin.ch> [2005-11-30 14:02] :
> Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
[...]
> > D'après la description du paquet, oui. Le programme n'est intéres sant
> > que si tu veux vérifier qu'un système de test tient la charge.
>
> c'est-à-dire ?
C.-à-d. qu'il ne va pas s'arrêter automatiquement (ou pire) s'il subit
une charge de 10 ou plus pendant quelques minutes, i.e. le CPU
surchauffe ou est surcadencé.
* steve [2005-11-30 14:02] :
> Le Mercredi, 30 Novembre 2005 13.55, Frédéric Bothamy a écrit :
[...]
> > D'après la description du paquet, oui. Le programme n'est intéres sant
> > que si tu veux vérifier qu'un système de test tient la charge.
>
> c'est-à-dire ?
C.-à-d. qu'il ne va pas s'arrêter automatiquement (ou pire) s'il subit
une charge de 10 ou plus pendant quelques minutes, i.e. le CPU
surchauffe ou est surcadencé.
On 11/30/05, steve wrote:
> Hello la liste,
>
> drôle de comportement ce matin avec plusieurs commandes:
>
> # aptitude updte
> Lecture des listes de paquets... Fait
> Erreur de segmentatione des dépendances... 0%
le E viendrait pas de la "Construction de la basE des dependances" ?
> (Remarquez comment segmentatione est écrit, avec un e à la fin..)
Sinon passe un memtest, on sait jamais
On 11/30/05, steve <dlist@bluewin.ch> wrote:
> Hello la liste,
>
> drôle de comportement ce matin avec plusieurs commandes:
>
> # aptitude updte
> Lecture des listes de paquets... Fait
> Erreur de segmentatione des dépendances... 0%
le E viendrait pas de la "Construction de la basE des dependances" ?
> (Remarquez comment segmentatione est écrit, avec un e à la fin..)
Sinon passe un memtest, on sait jamais
On 11/30/05, steve wrote:
> Hello la liste,
>
> drôle de comportement ce matin avec plusieurs commandes:
>
> # aptitude updte
> Lecture des listes de paquets... Fait
> Erreur de segmentatione des dépendances... 0%
le E viendrait pas de la "Construction de la basE des dependances" ?
> (Remarquez comment segmentatione est écrit, avec un e à la fin..)
Sinon passe un memtest, on sait jamais
Résultat du memtest de cette nuit :
test 1 : 9 erreurs
test 5 : 16 erreurs
test 6 : 743 erreurs
Donc c'est bien la RAM qui pose problème. C'est quelque part, une bonne
nouvelle... je préfère cela à la carte-mère ou le CPU.
Résultat du memtest de cette nuit :
test 1 : 9 erreurs
test 5 : 16 erreurs
test 6 : 743 erreurs
Donc c'est bien la RAM qui pose problème. C'est quelque part, une bonne
nouvelle... je préfère cela à la carte-mère ou le CPU.
Résultat du memtest de cette nuit :
test 1 : 9 erreurs
test 5 : 16 erreurs
test 6 : 743 erreurs
Donc c'est bien la RAM qui pose problème. C'est quelque part, une bonne
nouvelle... je préfère cela à la carte-mère ou le CPU.
Salut,
steve a écrit :
> Résultat du memtest de cette nuit :
>
> test 1 : 9 erreurs
> test 5 : 16 erreurs
> test 6 : 743 erreurs
>
> Donc c'est bien la RAM qui pose problème. C'est quelque part, une bon ne
> nouvelle... je préfère cela à la carte-mère ou le CPU.
Pas forcément, et ne crie pas victoire trop vite.
Ça peut être en fait
n'importe quel élément matériel impliqué dans la communication en tre la
RAM et le CPU, y compris la RAM, le CPU mais aussi le chipset et les bus
mémoire et CPU de la carte mère. La cause peut aussi être indirecte,
comme une tension d'alimentation hors tolérance (défaut de
l'alimentation générale ou d'un convertisseur de tension de la carte
mère, lissage de la tension insuffisant à cause de condensateurs de la
carte mère défectueux) ou des timings mémoire trop agressifs (ce qui
revient à faire de l'overclocking). Tensions et timings sont parfois
ajustables dans le BIOS de la carte mère.
Salut,
steve a écrit :
> Résultat du memtest de cette nuit :
>
> test 1 : 9 erreurs
> test 5 : 16 erreurs
> test 6 : 743 erreurs
>
> Donc c'est bien la RAM qui pose problème. C'est quelque part, une bon ne
> nouvelle... je préfère cela à la carte-mère ou le CPU.
Pas forcément, et ne crie pas victoire trop vite.
Ça peut être en fait
n'importe quel élément matériel impliqué dans la communication en tre la
RAM et le CPU, y compris la RAM, le CPU mais aussi le chipset et les bus
mémoire et CPU de la carte mère. La cause peut aussi être indirecte,
comme une tension d'alimentation hors tolérance (défaut de
l'alimentation générale ou d'un convertisseur de tension de la carte
mère, lissage de la tension insuffisant à cause de condensateurs de la
carte mère défectueux) ou des timings mémoire trop agressifs (ce qui
revient à faire de l'overclocking). Tensions et timings sont parfois
ajustables dans le BIOS de la carte mère.
Salut,
steve a écrit :
> Résultat du memtest de cette nuit :
>
> test 1 : 9 erreurs
> test 5 : 16 erreurs
> test 6 : 743 erreurs
>
> Donc c'est bien la RAM qui pose problème. C'est quelque part, une bon ne
> nouvelle... je préfère cela à la carte-mère ou le CPU.
Pas forcément, et ne crie pas victoire trop vite.
Ça peut être en fait
n'importe quel élément matériel impliqué dans la communication en tre la
RAM et le CPU, y compris la RAM, le CPU mais aussi le chipset et les bus
mémoire et CPU de la carte mère. La cause peut aussi être indirecte,
comme une tension d'alimentation hors tolérance (défaut de
l'alimentation générale ou d'un convertisseur de tension de la carte
mère, lissage de la tension insuffisant à cause de condensateurs de la
carte mère défectueux) ou des timings mémoire trop agressifs (ce qui
revient à faire de l'overclocking). Tensions et timings sont parfois
ajustables dans le BIOS de la carte mère.
