pilote nvidia propriétaire et noyau 6.3

[F. Dubois]

Bonsoir,

Je suis en unstable, lors de la construction des modules du pilote 
nvidia (avec dkms), pour le tout récent noyau 
linux-headers-6.3.0-1-amd64 et linux-image-6.3.0-1-amd64 une erreur se 
produit.


Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j4 modules 
KERNEL_UNAME=6.3.0-1-amd64..(bad exit status: 2)

Error! Bad return status for module build on kernel: 6.3.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-tesla-470/470.182.03/build/make.log for 
more information.

dkms autoinstall on 6.3.0-1-amd64/x86_64 failed for nvidia-tesla-470(10)
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.3.0-1-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11

Pas de rapport de bug, d'info...

La fin de /var/lib/dkms/nvidia-tesla-470/470.182.03/build/make.log

/usr/src/linux-headers-6.3.0-1-common/scripts/check-local-export 
/var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia/nv-p2p.o
# cmd_gen_symversions_c 
/var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia/nv-p2p.o
  if nm /var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia/nv-p2p.o 
2>/dev/null | grep -q __ksymtab; then  gcc-12 -E -D__GENKSYMS__ 
-Wp,-MMD,/var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia/.nv-p2p.o.d 
-nostdinc -I/usr/src/linux-headers-6.3.0-1-common/arch/x86/include 
-I./arch/x86/include/generated 
-I/usr/src/linux-headers-6.3.0-1-common/include -I./include 
-I/usr/src/linux-headers-6.3.0-1-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-6.3.0-1-common/include/uapi 
-I./include/generated/uapi -include 
/usr/src/linux-headers-6.3.0-1-common/include/linux/compiler-version.h 
-include /usr/src/linux-headers-6.3.0-1-common/include/linux/kconfig.h 
-include 
/usr/src/linux-headers-6.3.0-1-common/include/linux/compiler_types.h 
-D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-6.3.0-1-common/= 
-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE 
-Werror=implicit-function-declaration -Werror=implicit-int 
-Werror=return-type -Wno-format-security -funsigned-char -std=gnu11 
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=branch 
-fno-jump-tables -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 
-mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup 
-mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare 
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern 
-mindirect-branch-register -mindirect-branch-cs-prefix 
-mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all 
-fpatchable-function-entry=16,16 -fno-delete-null-pointer-checks 
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow 
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races 
-Wframe-larger-than=2048 -fstack-protector-strong -Wno-main 
-Wno-unused-but-set-variable -Wno-unused-const-variable 
-Wno-dangling-pointer -ftrivial-auto-var-init=zero 
-fno-stack-clash-protection -pg -mrecord-mcount -mfentry 
-DCC_USING_FENTRY -falign-functions=16 -Wdeclaration-after-statement 
-Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation 
-Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized 
-Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 
-fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time 
-Werror=incompatible-pointer-types -Werror=designated-init 
-Wno-packed-not-aligned -g 
-I/var/lib/dkms/nvidia-tesla-470/470.182.03/build/common/inc 
-I/var/lib/dkms/nvidia-tesla-470/470.182.03/build -Wall -MD 
-Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE 
-DNVRM -DNV_VERSION_STRING=\"470.182.03\" -Wno-unused-function 
-Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel 
-DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0 
-DNV_KERNEL_INTERFACE_LAYER 
-I/var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia 
-DNVIDIA_UNDEF_LEGACY_BIT_MACROS -UDEBUG -U_DEBUG -DNDEBUG -DMODULE  
-DKBUILD_BASENAME='"nv_p2p"' -DKBUILD_MODNAME='"nvidia"' 
-D__KBUILD_MODNAME=kmod_nvidia 
/var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia/nv-p2p.c | 
scripts/genksyms/genksyms   -r /dev/null >> 
/var/lib/dkms/nvidia-tesla-470/470.182.03/build/nvidia/.nv-p2p.o.cmd; fi
make[2]: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:2050 : 
/var/lib/dkms/nvidia-tesla-470/470.182.03/build] Erreur 2

make[2] : on quitte le répertoire « /usr/src/linux-headers-6.3.0-1-amd64 »
make[1]: *** [Makefile:238 : __sub-make] Erreur 2
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.3.0-1-common »
make: *** [Makefile:80 : modules] Erreur 2

Cela est-il arrivé chez quelqu'un  ?

Librement,

Fabien

Re: puis-je faire confiance a ce disque ?

[Th.A.C]

Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :


Bonjour,

J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.


je confirme, tous les seagate (sans exception) que j'ai eu dans les 
mains ont ce comportement, et ça ne date pas d'aujourd'hui.


Thierry

Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[Eric DEGENETAIS]

Le ven. 16 juin 2023 à 16:36, Frédéric BOITEUX 
a écrit :

> Bonjour,
>
bonsoir

>
> > Quand /var/log/ se remplit de messages d'erreur (messages syslog et
> user.messages), ça sonne puisque plus rien qui utilise /var ne peut
> fonctionner !
> > Si root supprime les fichiers remplis de la même alerte, /var reste
> rempli à 100%.
>
> Oui, c’est un classique ! Tant que le [gros] fichier est ouvert par un
> processus, il existe encore et sa place n’est pas libérée. Ici, le truc
> c’est de relancer le service qui écrit dans les logs, probablement rsyslog
> : le processus en cours est terminé, et les fichiers supprimés sont alors
> réellement libérés…
>
> Tronquer les logs (c'est à dire réécire un fichier vide au lieu de le
supprimer) fonctionne probablement aussi. Il me semble d'ailleurs que
logrotate offre cette option (je n'ai pas les détails sous la main à
l'instant)

> Cdlt,
> Fred (pas trop barbu :-)
>

Éric Dégenètais

RE: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[Frédéric BOITEUX]

Bonjour,

> Quand /var/log/ se remplit de messages d'erreur (messages syslog et 
> user.messages), ça sonne puisque plus rien qui utilise /var ne peut 
> fonctionner !
> Si root supprime les fichiers remplis de la même alerte, /var reste rempli à 
> 100%.

Oui, c’est un classique ! Tant que le [gros] fichier est ouvert par un 
processus, il existe encore et sa place n’est pas libérée. Ici, le truc c’est 
de relancer le service qui écrit dans les logs, probablement rsyslog : le 
processus en cours est terminé, et les fichiers supprimés sont alors réellement 
libérés…

Cdlt,
Fred (pas trop barbu :-)

Re: RAID5 (Mdadm) non fonctionnel sous Debian 11

[NoSpam]

Bonjour. Pour gérer le RAID il faut savoir quel est est le controleur de 
la machine: sudo lpci|grep RAID puis chercher quel est le module chargé 
de sa gestion et le charger.


Le 16/06/2023 à 15:10, Romain P. a écrit :

Bonjour

Je suis passé de Debian 10 à Debian 11 et volume RAID5, géré par la 
carte mère, n'est pas reconnu.


Créé sous Windows 10, il fonctionnait sous Debian 10 juste en 
installant Mdadm.


Sous certaines distributions, Mdadm est inclus et mon RAID5 fonctionne 
sans paramétrage.


J'ai lu plusieurs pages Web à propos de Mdadm, mais il y est indiqué 
des commandes différentes. Je suis perdu.


Comment faire fonctionner mon RAID5 sans risquer de le détruite ?

Merci

Romain

mdadm.txt :
"
Les NOUVEAUX paquets suivants vont être installés :
  mdadm
0 paquets mis à jour, 1 nouvellement installés, 0 à enlever et 0 non 
mis à jour.
Il est nécessaire de télécharger 449 ko d'archives. Après dépaquetage, 
1 240 ko seront utilisés.
Prendre :  1 https://deb.debian.org/debian buster/main amd64 mdadm 
amd64 4.1-1 [449 kB]

 449 ko téléchargés en 0s (1 391 ko/s)
Préconfiguration des paquets...
Sélection du paquet mdadm précédemment désélectionné.
(Lecture de la base de données... 289552 fichiers et répertoires déjà 
installés.)

Préparation du dépaquetage de .../archives/mdadm_4.1-1_amd64.deb ...
Dépaquetage de mdadm (4.1-1) ...
Paramétrage de mdadm (4.1-1) ...
Generating mdadm.conf... done.
update-initramfs: deferring update (trigger activated)
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-4.19.0-14-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-14-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-13-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-13-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-12-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-12-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-11-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-11-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-6-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-6-amd64
Windows Boot Manager trouvé sur 
/dev/nvme0n1p3@/efi/Microsoft/Boot/bootmgfw.efi

Adding boot menu entry for EFI firmware configuration
fait
update-rc.d: warning: start and stop actions are no longer supported; 
falling back to defaults

Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
Traitement des actions différées (« triggers ») pour systemd 
(241-7~deb10u6) ...
Traitement des actions différées (« triggers ») pour initramfs-tools 
(0.133+deb10u1) ...

update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64
"

RAID5 (Mdadm) non fonctionnel sous Debian 11

[Romain P.]

Bonjour

Je suis passé de Debian 10 à Debian 11 et volume RAID5, géré par la 
carte mère, n'est pas reconnu.


Créé sous Windows 10, il fonctionnait sous Debian 10 juste en installant 
Mdadm.


Sous certaines distributions, Mdadm est inclus et mon RAID5 fonctionne 
sans paramétrage.


J'ai lu plusieurs pages Web à propos de Mdadm, mais il y est indiqué des 
commandes différentes. Je suis perdu.


Comment faire fonctionner mon RAID5 sans risquer de le détruite ?

Merci

Romain

mdadm.txt :
"
Les NOUVEAUX paquets suivants vont être installés :
  mdadm
0 paquets mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis 
à jour.
Il est nécessaire de télécharger 449 ko d'archives. Après dépaquetage, 
1 240 ko seront utilisés.
Prendre :  1 https://deb.debian.org/debian buster/main amd64 mdadm amd64 
4.1-1 [449 kB]

 449 ko téléchargés en 0s (1 391 ko/s)
Préconfiguration des paquets...
Sélection du paquet mdadm précédemment désélectionné.
(Lecture de la base de données... 289552 fichiers et répertoires déjà 
installés.)

Préparation du dépaquetage de .../archives/mdadm_4.1-1_amd64.deb ...
Dépaquetage de mdadm (4.1-1) ...
Paramétrage de mdadm (4.1-1) ...
Generating mdadm.conf... done.
update-initramfs: deferring update (trigger activated)
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-4.19.0-14-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-14-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-13-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-13-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-12-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-12-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-11-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-11-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-6-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-6-amd64
Windows Boot Manager trouvé sur 
/dev/nvme0n1p3@/efi/Microsoft/Boot/bootmgfw.efi

Adding boot menu entry for EFI firmware configuration
fait
update-rc.d: warning: start and stop actions are no longer supported; 
falling back to defaults

Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
Traitement des actions différées (« triggers ») pour systemd 
(241-7~deb10u6) ...
Traitement des actions différées (« triggers ») pour initramfs-tools 
(0.133+deb10u1) ...

update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64
"

Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[Thomas Trupel]

Bonjour,

Une piste avec 
https://manpages.debian.org/bookworm/systemd/tmpfiles.d.5.en.html ?

Cordialement,
Thomas

16 juin 2023 11:47:14 roger.tar...@free.fr:

> Bonjour,
> 
> Quand /var/log/ se remplit de messages d'erreur (messages syslog et 
> user.messages), ça sonne puisque plus rien qui utilise /var ne peut 
> fonctionner !
> Si root supprime les fichiers remplis de la même alerte, /var reste rempli à 
> 100%.
> Il y aurait bien un lsof puis un kill de tout ce qui est "deleted".
> 
> Comment faire pour libérer l'espace sans devoir redémarrer la machine ?
> Fiablement, sans effet boomerang.
> 
> Egalement, comment éviter que /var ( partition dédiée) bloque la machine 
> quand il est plein ?
> 
> Je pensais à un script qui surveille les logs et tronçonne les messages 
> répétés pour maintenir.
> Un service du système ou un paquet gère-t-il ça ?
> ça doit arriver tellement souvent...
> 
> Merci.

Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[Alain Vaugham]

Le Fri, 16 Jun 2023 11:46:49 +0200 (CEST),
roger.tar...@free.fr a écrit :

> Egalement, comment éviter que /var ( partition dédiée ) bloque la
> machine quand il est plein ? 

Pour éviter de remplir /var à cause de la pollution des logs, je créé
une partition dédiée /var/log.


-- 
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[plapla]

Le 16/06/2023 à 11:46, roger.tar...@free.fr a écrit :

Bonjour,

Quand /var/log/ se remplit de messages d'erreur (messages syslog et 
user.messages), ça sonne puisque plus rien qui utilise /var ne peut 
fonctionner !
Si root supprime les fichiers remplis de la même alerte, /var reste 
rempli à 100%.

Il y aurait bien un lsof puis un kill de tout ce qui est "deleted".

Comment faire pour libérer l'espace sans devoir redémarrer la machine ?
Fiablement, sans effet boomerang.



Salut,

j'ai eu ce problème une fois, et un barbu m'a filé ce truc. En fait tant 
que le fichier est en écriture par le système, il ne s'efface pas 
vraiment. Il faut l'effacer sur place avec un :


echo 0>/var/log/le_log.log

Ça efface tout le texte, qu'on perd donc ! Il faut être sûr qu'on ne 
veut pas étudier le fichier ensuite.


mes 0.02 c.

Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[elguero eric]

il faut aussi surveiller /var/tmp

j'y ai trouvé un jour des fichiers de plusieurs gigas.

e.e.







Le vendredi 16 juin 2023 à 11:47:12 UTC+2, roger.tar...@free.fr 
 a écrit : 





Bonjour,

Quand /var/log/ se remplit de messages d'erreur (messages syslog et 
user.messages), ça sonne puisque plus rien qui utilise /var ne peut fonctionner 
!
Si root supprime les fichiers remplis de la même alerte, /var reste rempli à 
100%.
Il y aurait bien un lsof puis un kill de tout ce qui est "deleted".

Comment faire pour libérer l'espace sans devoir redémarrer la machine ?
Fiablement, sans effet boomerang.

Egalement, comment éviter que /var ( partition dédiée) bloque la machine quand 
il est plein ?

Je pensais à un script qui surveille les logs et tronçonne les messages répétés 
pour maintenir.
Un service du système ou un paquet gère-t-il ça ?
ça doit arriver tellement souvent...

Merci.

Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[NoSpam]

Bonjour

Le 16/06/2023 à 11:46, roger.tar...@free.fr a écrit :

Bonjour,

Quand /var/log/ se remplit de messages d'erreur (messages syslog et 
user.messages), ça sonne puisque plus rien qui utilise /var ne peut 
fonctionner !
Si root supprime les fichiers remplis de la même alerte, /var reste 
rempli à 100%.

??? Jamais vu cela en ext2/3/4 ou xfs  Quel fs ?

Il y aurait bien un lsof puis un kill de tout ce qui est "deleted".

Comment faire pour libérer l'espace sans devoir redémarrer la machine ?
Fiablement, sans effet boomerang.

Egalement, comment éviter que /var ( partition dédiée) bloque la 
machine quand il est plein ?
var est nécessaire. Il existe des outils comme 
librenms/munin/cacti/zabbix/... qui alertent


Je pensais à un script qui surveille les logs et tronçonne les 
messages répétés pour maintenir.

Un service du système ou un paquet gère-t-il ça ?
ça doit arriver tellement souvent...
Cela a du m'arriver à mes débuts avec Linux. Depuis, je surveille les 
serveurs comme le lait sur le feu ...

[...]

Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage

[roger . tarani]

Bonjour, 

Quand /var/log/ se remplit de messages d'erreur (messages syslog et 
user.messages), ça sonne puisque plus rien qui utilise /var ne peut fonctionner 
! 
Si root supprime les fichiers remplis de la même alerte, /var reste rempli à 
100%. 
Il y aurait bien un lsof puis un kill de tout ce qui est "deleted". 

Comment faire pour libérer l'espace sans devoir redémarrer la machine ? 
Fiablement, sans effet boomerang. 

Egalement, comment éviter que /var ( partition dédiée ) bloque la machine quand 
il est plein ? 

Je pensais à un script qui surveille les logs et tronçonne les messages répétés 
pour maintenir. 
Un service du système ou un paquet gère-t-il ça ? 
ça doit arriver tellement souvent... 

Merci. 

Re: puis-je faire confiance a ce disque ?

[BERTRAND Joël]

hamster a écrit :
> Le 16/06/2023 à 11:21, BERTRAND Joël a écrit :
>> hamster a écrit :
>>> Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :
  Bonjour,

  J'en pense que c'est un Seagate. J'ai eu des tas de disques
 comme ça
 qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
 problème est un firmware buggué et que Seagate n'en a rien à faire.
 Tant
 que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
 je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.
>>>
>>> Voila une inoformation interessante. Comment tu fais pour savoir si le
>>> noyau rale ?
>> 
>> Regarder par exemple ce qu'il dit dans /var/log/syslog ou dans dmesg.
>> Normalement, ces erreurs sont aussi logguées dans le disque dur (mais là
>> encore, attention aux firmwares buggués de Seagate).
> 
> Heu… Ca je m'en etais douté. Mais il y a beaucoup de choses dans syslog
> et dmesg, pour trouver l'aiguille dans la botte de foin, il faut un
> minimum avoir idée d'a quoi ressemble l'aiguille.
> 
> Quels sont les indices que tu cherche dans syslog et dmesg ?

Des erreurs de type ataXXX. Désolé, je n'ai pas la syntaxe en tête.
Vous ne pouvez pas les rater, ça fait des gros pâtés.

Re: puis-je faire confiance a ce disque ?

[hamster]

Le 16/06/2023 à 11:21, BERTRAND Joël a écrit :

hamster a écrit :

Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :

 Bonjour,

 J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.


Voila une inoformation interessante. Comment tu fais pour savoir si le
noyau rale ?


Regarder par exemple ce qu'il dit dans /var/log/syslog ou dans dmesg.
Normalement, ces erreurs sont aussi logguées dans le disque dur (mais là
encore, attention aux firmwares buggués de Seagate).


Heu… Ca je m'en etais douté. Mais il y a beaucoup de choses dans syslog 
et dmesg, pour trouver l'aiguille dans la botte de foin, il faut un 
minimum avoir idée d'a quoi ressemble l'aiguille.


Quels sont les indices que tu cherche dans syslog et dmesg ?

Re: puis-je faire confiance a ce disque ?

[BERTRAND Joël]

hamster a écrit :
> Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :
>> Bonjour,
>>
>> J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
>> qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
>> problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
>> que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
>> je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.
> 
> Voila une inoformation interessante. Comment tu fais pour savoir si le
> noyau rale ?

Regarder par exemple ce qu'il dit dans /var/log/syslog ou dans dmesg.
Normalement, ces erreurs sont aussi logguées dans le disque dur (mais là
encore, attention aux firmwares buggués de Seagate).

Attention toutefois, il y a eu un noyau Linux buggué jusqu'à la moelle
qui provoquait des erreurs disques dans certaines configurations (raid
logiciel). Je ne me souviens plus de sa version, j'ai eu ça sur un
serveur de test.

Re: puis-je faire confiance a ce disque ?

[hamster]

Le 16/06/2023 à 06:05, Virgile Jarrige a écrit :

Bonjour,

 >qu'en pensez-vous ? est-ce que je peux continuer a faire confiance a ce
 >disque ou bien est-ce que je prévois d'avoir a le changer bientot ?
N'étant pas un expert, pour savoir quel message d'un rapport smart est 
critique je me réfère à : 
https://fr.m.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology  dans la section "attributs".
Si la valeur d'un attribut sur fond orange est mauvaise, alors il ne 
faut plus faire confiance au disque dur. À noter que sur la page 
anglaise ce ne sont pas tout à fait les mêmes qui sont en orange, donc 
je consulte systématiquement les deux.


Merci beaucoup pour cette astuce, elle va m'etre fort utile.

Re: puis-je faire confiance a ce disque ?

[hamster]

Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :

hamster a écrit :

j'ai un disque dur pour lequel badblocks s'est terminé sans erreurs,
l'auto-test de smart s'est aussi terminé sans erreurs, pourtant dans le
rapport de smart je vois 3 chiffres qui m'inquietent :
Raw_Read_Error_Rate 70428466
Seek_Error_Rate 371778543
149  ---  Number of Reported Uncorrectable Errors
mais j'ai un peu de mal a bien causer le jargon smart

rapport smart complet ici :
https://suna.fdn.fr/liens/rapport-smart.txt

qu'en pensez-vous ? est-ce que je peux continuer a faire confiance a ce
disque ou bien est-ce que je prévois d'avoir a le changer bientot ?


Bonjour,

J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.


Voila une inoformation interessante. Comment tu fais pour savoir si le 
noyau rale ?

Re: puis-je faire confiance a ce disque ?

[BERTRAND Joël]

hamster a écrit :
> j'ai un disque dur pour lequel badblocks s'est terminé sans erreurs,
> l'auto-test de smart s'est aussi terminé sans erreurs, pourtant dans le
> rapport de smart je vois 3 chiffres qui m'inquietent :
> Raw_Read_Error_Rate 70428466
> Seek_Error_Rate 371778543
> 149  ---  Number of Reported Uncorrectable Errors
> mais j'ai un peu de mal a bien causer le jargon smart
> 
> rapport smart complet ici :
> https://suna.fdn.fr/liens/rapport-smart.txt
> 
> qu'en pensez-vous ? est-ce que je peux continuer a faire confiance a ce
> disque ou bien est-ce que je prévois d'avoir a le changer bientot ?

Bonjour,

J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.

Bien cordialement,

JKB

PS: je n'utilise plus de Seagate que contraint et forcé. Trop de
dysfonctionnements même dans les gammes SAS/SCA/SCSI.