Reprise du message précédent :
Le contenu de ce message a été effacé par son auteur

J'y connais rien, mais si tu dis que tu n'as pas mutt tu veux dire que c'est pas installé? Dans ce cas ça ne risque pas de fonctionner...
 
Aussi les 2FA, précisément les TOTP, ne sont valables que genre 30s, peut-être faut chercher par là?

Le contenu de ce message a été effacé par son auteur

 
tu lances bien ton script avec le bon utilisateur qui utilise la bonne configuration de ton programme de mail ?

Ben faut peut-être adapter le chemin vers l'endroit où se trouve le binaire mutt chez toi ?

Le contenu de ce message a été effacé par son auteur

 
Si j'ai bien compris :
 
- ton mutt fonctionnel et celui de ton user local ?
- ton script est lancé via root donc != de ton user local ?
 
Si oui ça me semble logique que cela ne fonctionne pas car ton script va chercher à lire la conf de /root/.mutt/muttrc  et non /home/tarkon/.mutt/muttrc.
 
En tout cas c'est ce que j'en comprend dans tes posts  

Le contenu de ce message a été effacé par son auteur

Ça fait 2 fois que je format un disque en xfs sous debian récent et que le truc n'est pas lisible sous centos7 il y a moyen de faire un format en utilisant la version d'avant de XFS par hasard ?

ext4, ca se lit partout et ca marche bien

Nan xfs for the win ca se lit partout aussi sauf que centos7 date de la guerre des druides

L'époque où ext3 était le défaut puis apparaît ext4 : "qu'est-ce je fais, qu'est-ce que je fais, je mets ext4 à l'install ou pas ??!   "

J'ai une carte SD qui est passé de 32 Go détecté à 30 Mo (!) après que je l'ai installée dans un Raspberry Pi pour son premier démarrage. Comme ça marchait pas, j'ai rebranché la carte sur un PC. Pas moyen de faire quoi que ce soit avec Gparted ou l'utilitaire Disques. Une idée ? Je crains bien de l'avoir flinguée je ne sais pas comment.

Tu peux toujours tenter d'effacer la clé avec dd (ce qui - logiquement - va effacer toutes les données) et voir si ensuite tu peux reformater, mais ça me paraît mal parti. ATTENTION ne te trompe pas de support surtout avec dd!!
 
Sinon, à tout hasard, si tu insères la carte il y a quelque chose (et notamment "error" bidule) dans dmesg?

Je vais tenter dd même si j'ai toujours la terreur de ce machin. Et je n'avais pas pensé à dmesg. Ce qui m'inquiète c'est que la carte er le lecteur chauffent très fort même quand je ne fais rien comme s'il y avait un truc qui tournait en boucle.

Ah oui, si ça chauffe très fort à mon avis c'est mort. Et à ta place je risquerais pas le lecteur/le port USB, ne sait-on jamais. Les cartes SD ne coûtent plus grand chose (enfin ça dépend).

 
Elle a quel âge ta carte ?
J'ai une SD qui a tourné environ 1 an et demi dans un raspi pihole, l'autre matin au boot elle n'était plus du tout détectée, morte. Ca vieilli mal ces cartes, surtout avec des écritures répétées.

Pour cette histoire de XFS, pour forcer le formatage en version4:
 

 
Mais le FS ne sera utilisable que jusqu'en 2038

 
Essaye de mettre la micro sd dans un tel/tablette, et voir si il permet de formater.
J'avais une sd qui ne voulais pas être formatée par gparted/gnome-disks-utility, et ca a fonctionné par l'utilisation d'un tel.

Elle a des années mais elle servait surtout de clé USB de secours quand il fallait installer des ROM custom sur des téléphones. Autant dire que je lui faisais prendre l'air une fois l'an

Poubelle et merci bonsoir

Drapal
 
Je m'essaie à Debian sans trop connaitre le monde Linux, un peu de culture ne fait de mal à personne

Firefox 115 est arrivé et à première vue pas de catastrophes genre réglages qui disparaîssent ou autre. (comme je l'ai eu plusieurs fois déjà lors d'une màj).

On est même à 118

Je parlais de la version par défaut soit ESR sous Debian 12 bien sûr.

Ah oui pardon ^^

J'ai un petit soucis sur mon serveur maison avec un RAID5 mdadm (3x1To sur HDD) sur Debian 10.

Depuis quelques semaines, je remarque que lors de la copie de gros fichiers de 5-10 Go (mais pas tout le temps) le débit s'écroule à moins de 1 Mo/s... il commence à copier à fond (1Gbps) puis ça tombe brutalement au bout de quelques secondes à quelques Mo/s puis à moins 1 Mo/s jusqu'à me faire planter l'explorateur côté client (en NFS). Et je n'ai pas d'autre choix que d'attendre qu'il ait fini car plus rien ne répond.

Côté serveur, la LED d’activité disque est allumée en permanence et les disques grattent à fond... Est-ce que ça pourrait venir du RAID qui est presque plein ? Il reste environ 120 Go.

Je ne sais pas où regarder exactement pour voir ce qui pourrait provoquer ça. Sur mon dernier transfert au bout d'un moment le débit est remonté au débit du LAN, mais c'est très fluctuant, ça "balance" par vague car il doit attendre que le système finisse d'écrire les données.

Ou alors... un des disques commence à flancher et ralentit les autres, mais SMART ne remonte rien.

Merci  

1/ vérifier l'état du raid:

2/ vérifier l'etat et les données SMART de chaque disque

peut être que le volume raid esst dégradé, ou qu'un de tes disques a un probleme et est en train de crever.

après, puisque tu parles de transfert LAN, le souci est peut être du à ton réseau ou à la machine en face, plutot que ton raid ?

Merci pour ta réponse.
 
Les disques vont bien. Pas de secteurs réalloué ni en attente, même s'ils ont bien tourné (12000h pour le moins sollicité à presque 28000h pour le plus vieux).  
 
Le seul truc c'est que j'ai de temps en temps sur un des 3 un problème de lien SATA qui se reset (j'avais déjà changé les câbles d'alim/données sans plus d’amélioration il me semble), mais ça le fait depuis plusieurs années sans que ça pose problème et c'est très aléatoire ça peut le faire plusieurs fois de suite en quelques jours (voir dans la même journée) ou rien pendant plusieurs mois... souvent il suffit que je débranche/rebranche physiquement les cables pour que ça disparaisse, peut-être un faux contact sur le disque lui-même... J'ai acheté un disque neuf au cas où.
 
Et je n'ai pas eu de déconnexion pendant ces transferts au ras des pâquerettes, j'en conclu que ça ne vient pas de ça. Côté config client, je pense pas non plus... Je copie depuis mon ryzen 3700X sur SSD et en filaire.  
 
Point important aussi : J'ai zéro soucis en lecture, le gigabit est saturé en permanence  
 
Pour le RAID, rien de bizarre à priori :  

Bon... plus inquiétant, je pensais que c'était un bug, mais non.

Je vois que mon uptime me donne une valeur incohérente alors que ça fait plusieurs semaines que je ne l'ai pas rebooté. C'est qu'il doit donc rebooter tout seul !

Là par ex, je suis à 10 jours d'uptime... sauf que je ne me suis pas rendu compte de l'indisponibilité alors qu'il a rebooté en fin d'après-midi à 17h le 20 septembre et que je devais sans doute être juste à côté.

SI j'en crois la commande last reboot, pas moins de 4 redémarrage qui ne sont pas de mon fait car toujours en still running...  

Ça sent la panne matérielle... La RAM ou l'alim peut-être ? Voir la CM    J'ai fouillé les logs en long en large et en travers, aucun truc qui me parait suspect... pas de kernel panic, rien. Enfin, je ne sais même pas si c'est loggé.

 
dmesg donne quoi ?  
Je suis en plein recovery de RAID pourris au boulot (bon c'était des raid0...) mais le dmesg donnait des infos d'erreur de disques. Et la smart aussi.
 
Pour la RAM, un memtest te donnera très vite l'info si le problème vient de là

dmesg n'indique rien de particulier concernant ces débits bizarres.

Par contre, hier, le RAID s'est mis en mode vérification et là... c'était le festival côté déconnexion SATA sur mon disque malade avec pour conséquence des mismatch sur pleins de secteurs, heureusement il est arrivé à les corriger.

L'extrait où ça commence à ch*er dans la colle ( le "failed command" est répété plus d'une vingtaine de fois avant ça) :

Demain, j'ai prévu de tout démonter, nettoyer, et changer les câbles histoire d'éliminer une bonne fois pour toute la piste du cable foireux (j'espère que ce n'est pas du côté CM... je n'ai plus de port de libre)

Juste pour info, il faut bien regarder le détail des données SMART et pas se fier au "PASSED" de smartmontools. Ce dernier disparaît uniquement quand le disque est pratiquement HS déjà (précisément - je pense - quand une des valeurs "pre-fail" passe en dessous du seuil fixé par le constructeur du HDD), mais il peut y avoir des soucis avant / un décès très spontané.

ils ont quel age tes disques ?
A ta place, je changerais en tout cas celui qui merde

Y'a des erreurs de bus sata au niveau du troisième disque !
 
Faut vérifier le câble/branchement.
Si ça vient pas de là, le disque, et dans le pire des cas, la carte-mère.

C'est dû aux nouveaux profiles de performance amd_pstate introduits récemments.

https://linrunner.de/tlp/settings/processor.html

J'ai ajouté "amd_pstate=passive" à mon /etc/default/grub et j'ai maintenant le contrôle du governor et il est prioritaire par rapports aux profiles amd.
Retour à un portable silencieux, ca fait du bien
J'ai même retrouvé les governors ondemand et conservative.

Faudra que je regarde cette histoire de plus près, mais pour auto cpufreq.

 
Je l'ai dit au début. Celui-ci a 27000h (moins pour les autres), mais côté smart tout va bien. Le pire c'est que j'ai relancé un check du RAID et cette fois aucune erreur, alors que je n'ai rien touché. Cette config est la reine de l'aléatoire    
 

 
Je vais démonter et changer le cable SATA (même si je crois l'avoir déjà fait l'année dernière, ça n'avait rien fait). J'ai acheté dernièrement un SSD au cas où. Je crois je vais le monter à la place pour voir.
 
 
 
 

Besoin d'un petite confirmation histoire de pas faire de connerie : Pour le remplacement du disque j'ai juste à faire :

-mdadm /dev/md0 --fail /dev/sdb --remove /dev/sdb
-éteindre
-retirer le disque
-brancher le SSD
-rallumer
-mdadm /dev/md0 --add /dev/sdb

Est-ce ok ?

Je vois que certains démontent et stoppent le RAID avant, est-ce nécessaire ou juste une sécurité en plus ? De même faut-il préparer le nouveau disque ou mdadm le formate tout seul comme un grand ? (me rappelle plus la première fois comment ça avait fait)

EDIT : Sécurité avant tout, backup en cours

C'est le plus important !!!
 
Pour le reste:
 
Essaie déjà de changer le cable sans toucher à l'array.
Si tu ne vois plus d'erreurs comme celle-ci:

 
en faisant "dmesg", ton problème est réglé.
 
Si ça ne suffit pas, la procédure classique consiste effectivement à indiquer au système que le disque doit être supprimé de l'array, avec mdadm --fail et --remove, puis d'ajouter le nouveau après l'avoir remplacé.
 
Les erreurs concernent ata3.
Fais "ls -l /dev/disk/by-path/", tu verras la liste des disques/partitions, et leur "identification".
Y'a pas mal de chances que le disque qui pose problème soit /dev/sdc.
 
Ensuite, quand tu fais "mdadm /dev/md0 --fail /dev/sdb", tu indiques un disque.
Or, ton array est construit sur des partitions, pas directement des disques:
En faisant "cat /proc/mdstat", tu as md0 : active raid5 sdc1[3] sdb1[1] sda1[0]
Pour reconstruire l'array de manière optimale, tu veux utiliser un disque identique aux autres, avec un partitionnement identique ...

Merci pour les précisions.

Du coup il faut que je crée au moins une partition linux RAID avant de l'ajouter, c'est ça ? (Me rappelle plus comment j'avais fait la première fois...)