Boot partiel (no ssh, apache= 503, no ftp)

[piper]

Bonjour, ce petit post pour parler d'un soucis que j'ai eu, que j'ai résolu mais dont la source était curieuse :
Voilà, j'ai un Pi4 : pas de sdcard, il boot sur un SSD.

Parmis les services en place, il y a vnc, le ssh , apache, vsftpd, samba et d'autres.

Il a 2 autres disques en usb 1 mécaniques (2To) et un autre SSD
ils sont automatiquement montés via fstab.
Tous passent par un hub usb disposant de SON alimentation.

Parmis les partitions je vais seulement parler de celles du disques de 2To (mécanique) qui comportait :
1 partition vfat de 32Go (partition historique non utilisée)
tout le reste en extf4

Donc depuis 2 ans que c'est comme ça, tout fonctionnait au poil (reboot, démarrage à froid etc...).

Et puis un jour, en pleine session ssh via putty, la commande ls me dit "unknown command", et toutes les autres commande pareil.
Il était toujours visible sur le réseau et pingable. VNC ne fonctionnait plus, si je ferme la session ssh, je ne peux plus en réouvrir
une connexion ftp me dit "mal configuré"
un tour sur une des pages web hébergées et apache me dit "http 503"

Je reboote, ça repart et puis pendant 3 jours tout est ok et puis ça a recommencé (mais pas en pleine session ssh : je m'en rend compte seulement lorsque je veux m'y connecté donc trop tard)
Un jour, j'arrive à voir sur dmesg un soucis sur une partion de boot
Bon je me dis ok, le ssd doit avoir un coup dans la tête.
Je le vérifie à partir d'un autre PC sous Linux : système de fichier parfait. What the F.... ?

Je remets le SSD, ça repart mais plusieurs après rebelotte (même message). Sauf que là, je me rends compte que j'étais allé un peu vite la 1ère fois :
je fais des vérifications avec parted et je vois que c'est la partition vfat inutilisée du disque mécanique qui est en cause (1er secteur).
Hors : je ne la monte jamais, elle n'est utilisée par aucun service.
Quel impact sur ssh ? pourquoi en pleine session ça me coupe la chique ?
Pourquoi cela empêche-t-il de booter normalement ? d'avoir accès aux commandes du shell , l'accès au ssh ? je ne boot par sur celle-là , elle n'est même jamais montée !

Bref, je déglingue la partition vfat pour la recréer (je ne m'en sers pas) à mais non, parted me dit qu'il ne peut pas parce qu'elle a un problème sur le 1er secteur.
Bon alors je la détruis et j'agrandi la partition ext4 pour récupérer la zone devenue libre. parted ne veut pas pour les mêmes raisons
Alors je recommence en laissant 1Mo devant que je n'utiliserais pas. Et là, parted veut bien.
Ensuite il repositionne mes 1,8To de fichiers (6h de traitement).

C'était il y a 15 jours, depuis : aucun problème.
Moralité : sur Raspi OS (Debian donc) , on dirait bien qu'un problème sur un disque externe (totalement externe : aucun des fichiers nécessaires à l'OS ne s'y trouvent : ni /boot, ni /) peut empêcher le bon fonctionnement de l'OS.
Je suis utilisateur de Linux depuis 25 ans (sur PC : principalement Fedora, Cent OS et RedHat) jamais je n'ai vu cela se produire.

Passons sur le fait que sur Raspi OS, ce n'est pas normal qu'un disque totalement externe, même abimé bloque le système.
Et regardons la santé du disque en question avec smartctl
Effectivement :

Code : Tout sélectionner

  1 Raw_Read_Error_Rate     0x000f   081   064   006    Pre-fail  Always       -       140992372
  3 Spin_Up_Time            0x0003   096   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   094   094   020    Old_age   Always       -       7048
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   075   060   045    Pre-fail  Always       -       28588971
  9 Power_On_Hours          0x0032   071   071   000    Old_age   Always       -       25597 (230 224 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0

Ceci n'annonce rien de bon
Pourtant, il n'a que 3 ans , certes allumé H24, mais j'ai des disques allumés aussi H24 depuis 12 ans avec de meilleurs stats.
Et pourtant c'est un seagate barracuda (comme d'autres disques de la même marque; que j'ai qui sont allumés H24 depuis plus de 10 ans)
Alors est-ce que Seagate n'aurait pas largement baissé en qualité ?
Chose curieuse : sa fin de garantie arrive dans quelques semaines.... obsolescence programmée ?

[destroyedlolo]

Tout ce que tu décris sur Apache et SSH démontrerait qu'il y a un FS sur ton disque mécanique qui met la grouille.

Avant d'incriminer le disque : VERIFIE l'ALIM.

J'ai ce genre de pb sur mon BananaPI : lorsque les alims à découpage commencent à être fatiguées, elles envoient de la merde, et les disques n'aiment pas du tout, surtout les mécaniques qui demandent plus de jus en pointe. Tu peux la tester en regardant la tension de sortie avec un oscyllo, le PI en fonctionnement : elle devrait être relativement stable (oscillations de quelques millivolts, mais pas plus sinon, elle est HS)

La solution que j'ai trouvée : j'ai remplacé l'alim par une 12V d'un portable HS, et j'ai mis un régulateur 5V derrière.

[piper]

Ce disque est dans un boitier 3,5 pouces avec sa prise d'alimentation externe
L'alimentation vient justement un bloc d'alim de tour de PC laquelle alimente ce disque , tout comme 3 ventilateurs de refroidissement de l'armoire.
Ce bloc d'alim a toujours bien fonctionné et à l'heure ou je parle c'est toujours le cas.
Le secteur qui a un soucis était dans une partition inutilisée et même pas montée : pas du tout logique
Le secteur détecté comme "abimé" est tout le temps le même.
Il empêchait le boot seulement 1 fois sur 2 : encore moins logique.
Et en fait, non, il ne l'empêchait pas : ssh , apache et vsftpd démarraient mais était inexploitables hors la partition ne contenait qu'un seul fichier (rien n'aurait permis de booter dessus)
Et tout fonctionne bien depuis que la zone abimée du disque est en dehors de toute partition.
(Ca tourne H24 et il y a eu plusieurs reboot depuis).
Vérifier l'alim ? à part tester la tension et l'intensité qui alimente le disque je ne vois pas quoi faire
Remplacer l'alim par une autre ? je n'en n'ai pas d'autres sous la main et comme ça fonctionne H24 depuis 7 jours je ne verrai pas de changement
J'essaierai si cela recommence

[Artemus24]

Salut à tous.

Quel est l'organisation du disque que tu utilises Piper ? BIOS/MBR ou GPT/EFI ?

J'ai bousillé un disque mécanique dans l'organisation MBR à cause d'une alimentation défectueuse.
Cela a provoqué l'atterrissage de la tête de lecture sur plusieurs pistes rendant les sauvegardes inutilisables.
Et il y avait tellement de pistes défectueuses que j'ai préféré mettre le disque à la poubelle.
Je me suis acheté un disque Western Digital 3,5" de 2 To avec alimentation externe de qualité et depuis plus aucun problème.

Il faudrait mettre ce secteur défectueux en inaccessible pour éviter que le problème revienne.
C'est un comportement bizarre car je ne comprends pourquoi Debian ne fonctionnerait pas à cause de ce disque externe.

Cordialement.
Artemus24.
@+

[piper]

Ni l'un ni l'autre

Le disque en question est externe au système (aucune données du système ni de boot dessus)
Il était en vfat pour la partie ayant 1 secteur défectueux (partition jamais montée, ne contenant qu'un seul vieux fichier à moi)
et une partition extf4 restée toujours saine
Le disque en question est justement un disque de qualité 3,5 pouces 2To avec son alimentation externe de qualité (quoi de mieux qu'une alimentation de PC 80+ ?)
Visiblement, cela n'a pas suffit