Pb récurant avec des disques USB

[piper]

Bonjour, je rencontre un pb récurant depuis 10 ans lié à mes disques en USB :
Ma config : c'est un serveur de média (basé sur Emby et Samba) disposant de 4 disques dur en USB.
Mon Pi est Headless (pas de clavier, pas d'écran)
Quelque fois au boot (et seulement au boot) , certains disques ne sont pas accessibles. Du coup apache n'est pas opérationnel, le partage non plus, ssh non plus, Emby non plus, VSFTPD non plus.
Si je lance un IPScan sur le réseau je vois :
- ssh mais toute connexion plante
- apache avec "bad config"
- ftp avec "bad config"
En ce cas, une seule option : redémarrage (hard reboot) et dans 9 cas sur 10, tout rentre dans l'ordre.

J'avais ce pb avec un Pi3 sous Buster puis Bullseye, idem avec le Pi4 sous Bullseye, idem avec Pi4 sous Bookworm
J'ai été en boot complet sur carte SD : pareil, j'ai changé de carte SD : pareil
Actuellement /boot/ est sur la carte SD et rootfs sur un SSD en USB direct sur le Pi : pareil (sauf que c'est cette config qui donne la récurance de ce problème la plus faible)
Les disques sont des 3,5 pouces disposant de leur propre alimentation.
J'ai changé de boitier pour ces disques dur : pareil
J'ai changé de disques durs : pareil
Ces disques sont sur un USB husb ayant sa propore alimentation (ce qui n'a rien changé)
J'ai changé de hub USB (sans résultat)

Le soucis c'est que après un hard reboot, lorsque tout a bien démarré, je n'ai aucune trace de l'ancien boot (celui qui a échoué ne produit pas de log d'erreur)

A tout cela il n'y a que 3 point commun :
- ce sont des Raspberry Pi (au début un Piç3 , puis un Pi4)
- il y a 4 disques durs connectés en USB (cela a été en 10 ans des 500Go, puis 1To, puis 2To et maintenant 4To mais cela n'a rien changé)
- C'est une alimentation de PC 450W qui fournit le 12V pour chacun des boitiers de disques USB 3.5 pouces (1 disque par connecteur molex) : j'ai 4 adaptateurs de Molex vers le jack de ces boitiers.

Tout ce joli bazard dans une une armoire prévue pour et dédiée : porte en vitre, ventilée, j'ai le contrôle de la Temp (jamais plus de 50°C pour le CPU du Pi, j'amais plus de 40°C pour les disques, même en plein caniard)
Il n'y a pas de place pour un écran sniff... donc pour voir l'erreur au boot : galère ! sauf à trouver un long cordon hdmi et poser l'écran au sol.

Si vous avez une idée : une piste pour que je trouve l'origine du pb....
J'ai pensé à l'instant : après un crash, si j'éteint tout, je récupère le disque qui porte rootfs, je le connecte à mon Laptop (Linux Fedora), pourrais-je voir la log ?
Je crains que celle-ci soit dans la base de données de journalctl (inaccessible directement)
Ce serait cool, si je la trouvais dans /var/log/boot.log mais actuellement je n'y vois que les boot qui se sont bien passé.

[dyox]

Bonjour piper,
Ce qui est bien avec toi, c'est que ton problème est super détaillé

Voici quelles pistes de réflexion :
1. As-tu essayé de te connecter en ssh en UART (avec un laptop) directement pour lire les logs ? C'est pour t'affranchir du réseau
2. Si tu ne sollicites pas tes disques, tes disques se mettent en veille (la tête de lecture se met au repos) et met du temps à se réveiller ? Je ne sais pas si tu peux contrôler directement ce paramètre par firmware DD / app linux.
Sinon, il faut empêcher la mise en veille des DD.
3. As-tu essayé un autre OS ?

Pour ma culture personnelle, "caniard" ça se dit ? Ou tu voulez dire kenya ?

Je pense grandement au 2. En cherchant, j'ai trouvé ça. Il y a aussi la page en FR si tu préfères.
Donc pour désactiver la mise en veille des DD, ça serait du genre :
sudo hdparm -S 0 /dev/sd? et/ou sudo hdparm -B 255 /dev/sd?
Pour demander ta valeur actuelle de l'APM : sudo hdparm -B /dev/sd?

Bons tests

[piper]

Bonjour et merci de votre réponse : cangnard se dit, ça vient de l'occitanie , (j'ai écrit caniard par erreur) c'est une expression qui signifie en général en plein soleil sous entendu, un soleil d'été de plomb (pleine chaleur)

Je ne vois pas le rapport après une possible mise en veille :
En effet : pi parfaitement opérationnel, dissques accessibles, je reboote et paf le chien, le phénomènje se produit. Les disques ne se mettent pas en veille en 15 secondes d'inactivité non ?
De plus, une fois que cela s'est produit ; le pi est pinguable, ssh ne foncitonne pas (donc le réseau fonctionne)
Un scan des port m'annonce que http et vsftpd sont disponibles mais mal configurés, comme si les fichiers de configs étaient tout ou parti inaccessibles.
Je reboote et hop, ça remarche (ou pas et là, je reboot et ça fonctionne).

hdparm ne me fournis pas les infos du power managment alors j'ai utilisé smartctl
/ est sur /dev/sdc, j'ai 254, ce qui est aggressif (le PM est quasiment désactivé)
j'ai des médias sur /dev/sda qui est en PM 128 ("middle")
J'en ai aussi sur /dev/sdb et /dev/sdd mais là, smartctl ne ne fournis aucune info de power managment
Et pour ces 2 disques, hdparm dit carrément : APM_level = not supported
Donc j'ai mis /dev/sda en PM = 254 mais ce disque ne porte aucun fichier système donc, peu importe, d'ailleurs mon /etc/fstab contient un timeout ce qui fait que même si ce disque est débranché, ça n'empêche en rien de booter.

Je repose ma question :
Après un boot qui a échoué.
Si j'éteins tout, j'extrais les disques qui portent /bootfs et /rootfs
Pourrais-je trouvé lé log du dernier boot (celui qui a échoué) ?
C'est dans quel fichier ?
J'ai peur que ce soit dans une base de données de journalctl ce qui m'epêcherait de la consulter.

Pour info : c'est pas les PC sous Linux qui manquent à la maison, donc lire une partition Linux, que ce soit extfs, btrfs, xfs ou what ever : peu importe.

[dyox]

Pour répondre à la question, je dirai que c'est /var/log/messages.
Tu substitues le /var/log (backup avant) d'un linux existant et tu mets celui-ci puis un coup de "dmesg" pour les couleurs.

[piper]

Dans le temps ça aurait fonctionné
Mais /var/log/message n'existe plus, maintenant c'est journald et c'est du binaire