Derniers articles - La taverne de John-John : Informatique

Remise en route Packard Bell Club 300XER

Tue, 03 Mar 2026 08:56:00 +0100

Voici une mini-tour trouvée sur Le Bon Coin. C'est un 300XER, un modèle d'entrée de gamme en 1998. Les "Packard Poubelles" comme certains les appelaient.

Il est sale et il pue, stocké dans une cave ou au grenier, mais fonctionnel. Seul un léger jaunissement de la façade est à déplorer.
Un graveur Nomai IDE a été rajouté, un 2x2x6x.

Aucun anachronisme notable, tous les composants sont d'époque.
Petite carte modem RTC, petite carte ethernet Realtek de rajoutée. On remarque que le son et la vidéo sont intégrés à la carte mère.

On est sur du Cyrix MII donc du socket 7. Ici la RAM est en EDO (96Mo) pas de SDRAM, le chipset est un SIS 5598. Pas de doute on est sur une plate-forme low-cost.

Aucun condensateur de gonflé. Sur theretroweb la carte est identifiée comme la BCM IN5598.

La pile de la NVRAM est à remplacer (CR2032 classique).

Le Windows 98 est celui d'origine. Mais c'est une première édition.

Le ventirad est à remplacer, il fait un bruit affreux.

On admire le scotch métal (pour faire masse - collée au châssis) qui déborde sur la zone de pâte thermique. 😂
Ce Cyrix 300 tourne en fait à 3x75Mhz soit 225Mhz, el famoso "PR - Performance/Pentium Rating" : très bon sur les entiers mais lent en virgule flottante.

Nettoyage de l'alimentation Astec 95W. RAS.

Comme l'immense majorité des alimentations à cette époque le ventilateur 8cm intégré tourne à fond, il n'y a pas de régulation de type "Noise Killer". Utilisation d'une boite à décade low-cost pour trouver la bonne valeur de la résistance à installer. Il faut trouver un compromis entre flux d'air satisfaisant et le bruit.

Même chose pour le nouveau ventirad.

J'ai décidé d'y mettre une petite carte Compact Flash à la place du HDD.

J'ai pu tester le graveur avec un CD-RW, ça fonctionne.
Pourquoi sortir des cartes Matrox en PCI ?

Car la sortie vidéo VGA est floue, dès que l'on monte en définition le RAMDAC ne suit pas et la circuiterie doit être moyennement bien faite jusqu'au port VGA. Hélas cette implémentation SIS intégré est plutôt faite pour du 800*600. Au delà ça bave. 🤪

Et Matrox c'est la certitude d'avoir un signal vidéo de qualité. Le circuit VGA intégré est désactivable via un cavalier sur la carte mère.

Tout de suite c'est beaucoup plus net.

Les façades plastique des lecteurs sont parties au retrobrithage.

Toutefois par la suite j'ai décidé de remplacer le Sony CDU701 d'origine qui se révèle capricieux. Les lecteurs CD AOpen (Acer) sont des très bons lecteurs quelque soit leur génération. Ils n'ont pas la réputation des Plextor mais c'est de la bonne. 😵

Reste à passer la façade jaunie au retrobright... ça dénote avec le reste maintenant.

Voila c'est fini. L'étiquette a bien résisté au traitement.

Après on peut faire nettement mieux comme upgrade c'est juste une question de choix. Passage en AMD K6-2, lecteur/graveur DVD, ATI Rage, etc...

Découverte du boîtier JetKVM (KVM over IP)

Sat, 21 Feb 2026 13:08:00 +0100

C'est un boîtier qui permet d'ajouter (de simuler) la fonction "gestion hors bande" de l'IPMI sur un PC de bureau classique. On retrouve ces fonctions uniquement sur les serveurs généralement : IDRAC chez Dell, iLO chez HP... Après avoir vu quelques vidéos Youtube, j'ai décidé de m'en procurer un pour tester un peu sur mon PC-NAS. Il existe plusieurs modèles sur le marché avec des vidéos de comparatifs. Il doit y avoir environ 365787 vidéos sur Youtube à son sujet. Celui-ci semble être le plus cher parmi les solutions existantes, ce n'est pas donné (119$/108€ frais de port inclus chez WisdPi) mais l'appareil a une tronche sympathique.

Réception des colis, l'un comporte le KVM-IP lui-même et l'autre une carte officielle que l'on peut acheter en option qui se fixe sur une équerre PCI.
Les deux équerres Full-Height et Low-Profile sont fournies.

Elle sert à simuler l'appui sur les boutons de la façade (Power et Reset). Indispensable pour pouvoir rattraper le coup à distance si le PC freeze sur un BSOD ou Kernel Panic par exemple (appui long 4/10 secondes).

Dessus se trouve un microcontrôleur de la fondation Raspberry Pi RP2040 avec son quartz 12Mhz, une puce flash SPI Winbond, un régulateur AMS1117 et 4 optocoupleurs.

La boite du KVM en lui-même avec les cordons livrés dont le Y pour l'alimentation :

Assemblage de la carte interne, il y a des branchements à faire. Il s'agit tout simplement d'un repiquage en double-commande, les boutons et les DELs en façade doivent toujours fonctionner. Le contrôleur et ses E/S GPIO ont deux rôles : sonder l'état des DELs (méthode entrée) et en même temps fermer le circuit pour simuler la pression sur les interrupteurs (méthode sortie).

Les cordons fournis sont un peu courts pour amener le boîtier vers la façade.
A moins d'utiliser d'autres cordons, tant pis, il sera relégué à l'arrière. En même temps il n'y a pas besoin d'y toucher tous les quatre matins.

Je l'ai collé avec un patin double-face 3M, comme le disque dur externe USB de sauvegarde à coté de lui.

En place :

Testé OK, tout fonctionne correctement, l'interface est propre (traduction française incluse) et assez intuitive.

Je n'ai pas testé d'afficher un environnement de bureau graphique et encore moins du jeu-vidéo, je n'en ai pas l'usage.

Comment ne pas déverrouiller les HDD HGST (Cross-flash vendor-locked)

Sat, 14 Feb 2026 17:28:00 +0100

L'année dernière je suis tombé dans le rabbit hole des disques durs SAS bloqués logiciellement. Cette page résume mes aventures à tenter techniquement de les déverrouiller mais sans succès à ce jour. Tout part de l'achat de quelques disques durs 2,5 pouces SAS-2 et SAS-3 pas chers sur eBay qui sont issus d'appliances de marque NetApp, EMC ou Cisco décommissionnées.

Et s'ils ne sont pas chers c'est qu'il y a une raison. 😁

J'en ai malencontreusement pris quatre sur eBay sans savoir, sans trop me méfier, qui sont étiquetés NetApp. N'ayant jamais eu de tel matos OVER 9000 propriétaire à la maison ou au travail, comme par exemple des baies de disques EMC ou NetApp, je n'avais absolument pas connaissance de tout ce qui m'attendait. Voici les deux modèles de disques avec lesquels je suis concerné :

2x HGST HUC109090CSS600 (famille Cobra-E), dont un est décédé suite à mes essais
2x HGST HUC101890CS4204 (famille Cobra-F)

Tout va bien avec les Cobra-E mais ce n'est pas le cas avec les Cobra-F. Le disque ne fonctionne pas totalement de manière générique et correctement partout sur d'autres contrôleurs SAS d'autres marques (LSI, ServeRAID, PERC, ...). Il y donc une distinction à faire entre les firmware "custom" et les firmwares constructeur OEM, appelé "génériques" ou civils. civilian revenant souvent sur les forums spécialisés. On trouve de ces histoires à la pelle sur le net. Le sujet ne concerne pas un fabricant spécialement. La plupart ont pu faire fonctionner ces disques en l'état, tels quels, simplement en les reformatant avec une taille de secteur standard, en les passant de 520 à 512 octets, pour une utilisation en RAID logiciel du genre unRAID/TrueNAS sur une carte en mode HBA/IT.

Mais dans certains cas changer la taille de secteur à 512 octets en reformatant ne suffit pas à les rendre absolument compatible partout. Car dans mon cas souvient un autre problème de cold boot. Le blocage du disque se fait, selon moi, sur une séquence de démarrage après mise sous tension qui doit être absolument respectée (timing). Sinon à l'allumage les disques "buguent" et ne sont pas détectés correctement. Sur mon Dell PowerEdge T440, que la PERC soit en mode RAID ou HBA, c'est la même chose, la machine est bloquée au boot sur l'écran bleu, la seule solution étant de retirer les disques de la cage et de les remettre. Après cette manipulation ils fonctionnent correctement. Ce qui réclame d'être devant le serveur lors du boot : pas terrible. C'est comme si les disques attendaient une courte période de temps que le contrôleur (ou l'expander de la backplane) leur envoie quelque chose, juste après la mise en tension, sinon c'est trop tard, faut ré-appliquer une déconnexion électrique. Seulement comme la carte contrôleur et/ou la backplane elle aussi doit prendre le temps de démarrer, elle ne répond pas assez vite, ce temps est dépassé, les disques ne sont pas détectés. C'est assimilable à une race condition. C'est mon hypothèse. Même situation que cette personne : https://forums.servethehome.com/index.php?threads/hgst-netapp-sas-drives-most-of-the-time-dont-show-up-on-dell-r730xd-backplane.43001/.

Pour ceux qui auraient fait le rapprochement avec le problème de la broche 3.3V : que les disques reçoivent ce 3.3V ou pas c'est la même chose. Même avec des adaptateurs qui n'apportent pas cette 3ème tension c'est pareil. Le fil n'est pas présent, il n'y a que le 12V et 5V d'appliqués, donc ce n'est pas cela le problème.

Donc pour moi cela provient d'une modification du logiciel interne qui a été personnalisé pour un démarrage "spécifique". La solution est simple à première vue : remettre le firmware constructeur à la place, ce qui rendrait le disque conforme à son comportement d'origine. C'est là que les choses se gâtent. Si on essaye, et bien cela ne fonctionne pas. Même mettre le firmware originel du fabricant échoue. On pourrait penser que c'est quelque chose de légitime. Et bien non. C'est de la sécurité. C'est le début des investigations durant des nuits blanches de recherche et de casse tête cet été pour moi.

Les firmware d'origine

On peut les trouver sur le net, notamment sur l'espace de téléchargement du site hddguru.

La mauvaise idée : jouer avec la puce Flash

Ouais c'est facile, yaka (faukon) dessouder la SPI Winbond/Macronix du PCB, la mettre dans un programmateur et hop.

Hélas c'est une autre époque ou pour des techniques de récupération de données très spéciales. Sur les HDD modernes une partie du firmware est en effet dans la puce Flash mais une autre partie est située sur les plateaux du disque. Cette zone est appelée la SA (System Area). Elle est située dans de la zone LBA négative (LBA < 0) et pas obligatoirement de manière contiguë.

Pour garder un ensemble cohérent de firmware et éviter de bricker son HDD, il est donc bon de laisser au firmware installé le soin d'écrire les bonnes sections lui-même du nouveau firmware à la fois dans la flash et sur les plateaux si besoin. Des bouts du firmware global étant répartis de part et d'autre. Donc cette méthode barbare, on oublie.

La protection / Comprendre la logique

Il y en a comme moi qui ont essayés, ils ont eu des problèmes. 😂
Nous avons tenté des commandes à base de sg_write_buffer mais toutes échouent avec des Illegal Request comme réponse.

Déjà pourquoi ça ne fonctionne pas ? C'est simple : le firmware du HDD embarque un mécanisme interne de vérification du nouveau firmware à prendre en compte (lors d'une commande sg_write_buffer). C'est le disque dur (ou SSD) LUI-MÊME qui accepte ou refuse le fichier firmware .lod, .sed ou .bin proposé à l'implantation. Le nouveau firmware est accepté uniquement si sa signature condensée SHA256 correspond à une clé publique RSA-2048 déjà inscrite dans le firmware du HDD en place. Il faut donc être familier des principes de chiffrement asymétrique (clé publique / clé privée) et de condensât (checksums / digest).

Un disque qui embarque un firmware NetApp ne pourra être flashé qu'avec un autre firmware signé par NetApp.
Un disque qui embarque un firmware Dell ne pourra être flashé qu'avec un autre firmware signé par Dell.
Etc...

D'où le terme de "Vendor-locked" : les disques sont verrouillés et interdisent le cross-flashing, c'est à dire mettre le firmware d'un autre "vendor" (revendeur) à la place. D'où le fait aussi que les revendeurs (NetApp, Dell, EMC, Cisco,...) doivent repackager/recustomiser le firmware du fabricant (WD, HGST, Seagate...) à leurs clients lorsque le fabricant en sort un nouveau : exemple.

C'est une fonctionnalité proposée par les fabricants (WD, HGST, Seagate...) directement en usine, le firmware est personnalisé pour le client (Nom du fabricant, numéro de modèle, code PIN, clé publique RSA-2048...). Sur un HGST Ultrastar 10K900, il est facile reconnaître la provenance en lisant le numéro MLC. Il démarre toujours par CE pour Cobra-E (famille 10K900) suivi d'un 0 et enfin de 4 caractères alphanumériques (version du firmware).

Un disque NetApp aura donc un firmware noté CE0NAxx, CE0NA00, CE0NA01, CE0NA02, etc... Et cette information est apposée sur l'étiquette constructeur (valeur MLC en rouge), on peut donc en déduire que ces disques sont déjà personnalisés en sortie d'usine.

Un spécimen "civil", destiné à la revente au détail, aura un firmware générique, son MLC équivaut à CE0A5B0 sur l'étiquette de ce spécimen neuf illustré ci-dessous :

Remarque 1 : cette protection N'A RIEN A VOIR avec le chiffrage du disque en lui-même (SED) ou quelconque protection par mot de passe ATA.

Remarque 2 : Ne pas oublier que firmware contenu dans le binaire .lod n'est pas réellement 100% complet, des données variables sont propres au disque dans la Service Area et doivent le rester (calibration des têtes, listing des secteurs défectueux, numéro de série, etc... Ces données ne sont pas et ne doivent pas être mises à jour lors d'un upgrade firmware. Glossaire : https://blog.acelab.eu.com/glossary.

Comment déverrouiller un disque ? RTFM frère

Il faut passer par la case retro-ingénierie et accessoirement se palucher une tonne de documentation. Va falloir fouiner ! Certaines commandes de la norme SCSI sont publiques (T10). D'autres sont cachées (non documentées, documentation non accessible au public) que l'on appelle des VSC (Vendor Specific Commands) ou encore des VUC (Vendor Unique Commands). Elles sont ainsi spécifiques à chaque marque de disque dur, et les constructeurs peuvent faire ce qu'ils veulent avec. J'ai passé des heures à jouer avec les commandes sg_utils que ce soit coté Windows ou Linux avec mon petit PC Lenovo de test :

C'est en envoyant des commandes bien ciblées au disque qu'on arrive à le placer dans un certain état (spacial mode) qui désactivera la vérification de la signature du firmware. Une fois cette fonction désactivée, le HDD pourra ingurgiter n'importe quel firmware: OEM, HP, Dell, EMC, NetApp, etc... Et le cross-flash est donc possible. Hélas seuls des outils professionnels hors de prix peuvent faire ce cross-flash. Du genre le ACELab PC3000 ou chez MRT Lab.

The "Russian dude"

Il est surnommé tel quel par ce site (lug.mtu.edu). Son auteur est je pense assez blasé. J'en comprends la frustration.

E123 est une personne sur des forums qui propose un service de déverrouillage de ces disques à distance (via le bureau à distance de Windows). Un service monnayé contre quelques euros par disque. Ce E123 est très compétent, aucun doute là dessus. Il a dû y passer du temps, et le temps c'est de l'argent. Il ne souhaite pas partager ses secrets. Knowledge is money !

La vidéo ci-dessus est une démonstration de son service. En résumé : le disque connecté se présente comme un DKR5D, il lance un script .bat DOS "CMD" classique, qui démarre un deuxième Niagara en mode CLI (une deuxième instance de Niagara, pas celle que l'on voit à l'écran en graphique). Le script utilise Niagara pour envoyer des commandes au disque afin de le déverrouiller. C'est ici toute la magie, qui est monnayée, cachée dans ce script temporaire. Une fois ce script déroulé, dans un deuxième temps on peut injecter un autre firmware, ce qu'il va faire avec le Niagara déjà ouvert en GUI. Ce logiciel exploite derrière la commande sg_write_buffer. L'injection du nouveau firmware fonctionne. Il montre dans un troisième temps que le disque fraîchement mis à jour fonctionne bien sous le logiciel Victoria avec le nouveau firmware générique implanté. Le disque n'est plus un DKR5D mais un HITACHI générique tout en conservant le même numéro de série. Remarque : il existe une version Linux de Niagara.

Pourquoi partir dans cette direction ?

E123 a laissé quelques indices dans ce post sur le forum hddguru.

E123 :

To reflash HGST disks from one vendor to another, it is necessary to deactivate checks inside the hard drive itself, as provided by the manufacturer. Dig the code, look for keys, look for vendor commands. No free utility, let alone OEM flasher, will help in this case.

Grosso modo il faut analyser le code du firmware ARM (en dumpant les modules de la SA du disque) à la recherche de la routine qui désactivera cette vérification : ce qui signifie trouver les "clés" et des VSC à jouer. Des investigations à faire en solo quoi (hard way), comme lui a dû les faire de son coté. Mais ce n'est pas à la portée de tout le monde de bien savoir lire et décortiquer du code ARM décompilé. Je n'ai pas de licence pour le logiciel IDA. Peut-être demander à une IA ?

Le matériel nécessaire

Comme déjà dit, il faudra envoyer des commandes "sur mesure" au disque dur. Pour cela il est conseillé d'utiliser une carte HBA en mode IT (Initiator-Target). Certaines cartes comme la PERC H730P de mon Dell T440 peuvent basculer dans ce mode en jouant dans les paramètres. Sinon vous pouvez prendre une carte contrôleur SAS type LSI2008 déjà pré-flashée sur AliExpress pour quelques dizaines d'euros. Ce sont des cartes Dell, IBM/Lenovo ou HP recyclées dont le firmware d'origine a été re-flashé pour l'utiliser dans ce mode.

En gros, elle fonctionne comme un passe-plat. Les commandes SCSI transitent telles quelles de l'Initiator (hôte Linux/Windows/BSD) à la Target (disque dur) sans restriction/translation sur le chemin. Par opposition au mode RAID, qui comme son nom l'indique, embarque toute la couche de logique de gestion RAID (communications internes indépendantes entre la carte et ses disques, sans intervention de l'hôte/OS) et peut maquiller la communication. Vidéos de the-art-of-server sur Youtube :

Les logiciels nécessaires

Pour envoyer des commandes custom SCSI au disque SAS il faut passer par les outils sg_utils (paquet sg3_utils sur Linux). Pour les Windowsiens, il existe des versions exécutables pré-compilées qui font le travail même sous Windows 7.

Pour investiguer sur le plan logiciel

J'ai eu un temps utilisé un Dell Optiplex 380 mais après j'ai pris un Lenovo Edge 72. Un truc assez vieux qui accepte Windows 7 out of the box.

Dual boot Fedora 42 / Windows 7 (menu grub2 / os-prober), utilisation à distance (RDP/SSH)
Un petit script pour dumper la ROM du disque en modules (petit script de fzabkar)
Un éditeur hexadécimal
Les commandes linux de fouinage : binwalk, strings, file & vbindiff
Ghidra (explorer/désassembler/décompiler le code ARM 32bits LE du firmware et les dumps de ROM)

En aparté, pour gruger la timebomb du logiciel Niagara sous Linux. Avec Ghidra je suis parti à la recherche de la fonction qui affiche le message dans libtcluil.so. Petite trouvaille, on remarque que le logiciel essaye de détecter si on est sur le réseau d'HGST ou pas (usage en interne à l'entreprise) "onHGSTNetwork".

Pour gruger, il suffit de supprimer le test de retour de la fonction niagaraExpired. Ainsi la fonction niagaraExpired est toujours exécutée mais son résultat n'est plus pris en compte (return non exploité). Le logiciel démarre intégralement sans jamais expirer. Il me semble que j'avais tenter de gruger l'heure du PC sans succès. Avant :

Après :

Un Niagara débloqué sous Linux. Plus besoin de Windows 7.

Des documentations téléchargées du web...

Les premières tentatives, comment déverrouiller un disque ?

Au départ benoîtement, j'ai cru qu'il suffisait de lire la documentation constructeur. HGST implémente le protocole de sécurité "TCG Entreprise SCC". Ces fonctionnalités ne servent qu'aux disques dits "SED", chiffrés en interne. HGST propose deux modèles de disques, l'un chiffré (CSS601) et un autre non-chiffré (CSS600). Mes disques sont non-chiffrés. Mais en fait derrière le soft entre les deux modèles est peut-être identique ? Que ce soit un CSS600 ou 601 ce sont juste des paramètres qui changent dans le firmware. Pourquoi parler de ça ? Ce système de TCG embarque toute la logique de sécurisation globale du disque dur jusqu'au chiffrement des données sur les plateaux par zones (appelées bandes). Les données sur les plateaux sont découpées par bandes/zones et chaque zone à sa clé de chiffrement. C'est indiqué dans la documentation. HGST se sert du mécanisme TCG pour gérer l'aspect sécuritaire de deux autres fonctionnalités dont celle qui nous intéresse. Comme expliqué dans la documentation. Il est possible de désactiver cette vérification de signature de firmware. Ce qui ouvrirait la porte à notre "cross-flashing". Comme indiqué, ces fonctionnalités sont "un plus" qui sortent du cadre de la norme TCG.

En gros, il faut utiliser certaines fonctionnalités fournies par ce module TCG et aller modifier la table "Admin SP". SP pour Security Provider afin de désactiver la fameuse vérification de signature de firmware qui nous embête.

Les commandes TCG sont encapsulées via les commandes SCSI suivantes :
- SECURITY PROTOCOL IN (A2h) = IF-RECV
- SECURITY PROTOCOL OUT (B5h) = IF-SEND

Les fonctions liées à TCG sont lourdes à mettre en œuvre, il y a toute une négociation (aller-retour) à base de jeton (comID) à faire avec le disque dur avec une authentification et ça réclame un vrai programme dédié.

Il faudrait :

commencer par faire un "Level 0 discovery"
débuter une session et obtenir un comID
s'authentifier avec le MSID ou un code pin de 32 caractères
pour enfin envoyer la commande pour changer la valeur qui nous intéresse : passer Firmware_Dload_Port.PortLocked à False
à ce stade, le HDD est déverrouillé et ainsi prêt à accueillir n'importe quel firmware (civil ou non).

J'ai pu trouver sur GitHub un utilitaire génial fait en Go qui fait 95% du travail : https://github.com/open-source-firmware/go-tcg-storage/tree/main

Reste un peu à l'adapter... mais il y a un problème, il faut s'identifier auprès du disque avec le MSID ou un code PIN que l'on ne connaît pas. J'ai ressorti Ghibra à la recherche du mot de passe. Le code PIN TCG réclame que le longueur du mot de passe soit exactement de 32 caractères. Ni plus, ni moins. La longueur n'est pas variable. Sachant que le MSID par défaut est le numéro de série du disque établi sur 8 caractères répété 4 fois, donc 32 caractères. J'ai quand même trouvé du "Hello World!" dans le firmware. Hélas je n'ai pas les symboles pour tout comprendre.

Mais rien n'empêche le vendor d'avoir mis autre chose comme mot de passe. Mais hélas cette piste s'arrête là car les commandes TCG avec cet utilitaire en Go n'ont pas d'effets. La partie TCG semble complètement désactivée. Idem dans Niagara. Donc je pense que ce sont d'obscures commandes non-documentées qui gèrent cet aspect... et alors là pour les trouver... 😤🤯

La capitulation

Courant août j'ai abandonné. Trop complexe pour moi tout seul de rendre mes HGST OEM, c'est figé en l'état sur mon NAS.

J'en ai même perdu un sur les quatre durant mes essais, comme d'autres sur les forums, en bricolant partiellement les différents modules qui composent la Service Area avec sq_raw / sg_write_buffer. En octobre dernier, mr44er sur hddoracle poste de nouvelles informations issues d'une IA façon GPT, une lueur d'espoir. J'ai essayé certaines commandes qu'il a posté mais elles sont à moitié fausses. Le "special mode" je l'avais déjà tenté bien avant.

Nous sommes en février 2026 et donc je confirme que j'ai lâché l'affaire, trop de temps perdu même si j'ai appris pas mal. Comme d'autres avant moi, j'ai contacté ce fameux russe par courriel avec une petite vidéo faite en privée en anglais pour lui expliquer tout cela. Il est resté sur l'affaire des 520->512 octets et qu'après cela il n'y a pas de restrictions, que les disques fonctionnent bien en restant en firmware NetApp. Donc l'opération ne servirait à rien. Oui ça fonctionne, mais rien à propos de mon affaire de cold boot. Après une seconde demande quelques semaines plus tard, j'ai eu une réponse négative, grosso-modo ce n'est pas intéressant pour lui car je n'ai que trois disques à flasher, il en faudrait une dizaine pour que l'on parle sérieusement. Je pense qu'il traite plus en business/B2B qu'avec des simples particuliers ponctuels comme moi ça lui prendrait trop de temps. Finalement je sors la carte bleue et je me prends des SSD d'occasion Dell reconditionnés comme ça plus de problème.

Un jour peut-être on aura une solution gratuite mise en ligne publiquement. 😒
En attendant, beaucoup de ces disques iront finir leur vie en mode anticipé dans les DEEE. Merci la "sécurité".

Remplacement ventilateurs alimentation Delta pour IBM x3400 M3

Sat, 05 Apr 2025 11:22:00 +0200

Quelques photos du remplacement des petits ventilateurs Nidec 4cm sur les deux alimentations Delta d'un serveur IBM. Ils font un bruit de casserole.

Heureusement ils se trouvent encore en neuf.

Hélas il faudrait retirer le PCB pour sortir le ventilateur, méthode barbare alternative, tordre un peu de métal, ça passe. 😁

Attention au brochage

Mais c'est surtout à mettre en corrélation avec où les fils sont soudés coté ventilateur, quel fil porte quel signal/alimentation ?

Finalement il y a correspondance parfaite, juste la couleur des fils change, ici il y a juste à faire du plug and play, aucun fil à déplacer sur le connecteur 4 pin.
Sous l'étiquette, on a accès à l'axe du rotor pour la lubrification magique. Seulement généralement, pendant quelques temps le ventilateur a tourné avec des roulements usés qui ont auront pris du jeu. Les lubrifier ne sert à rien sur le long terme, aucune huile ou graisse ne pourra remédier à un roulement bruyant (usé).

Tout remis en place :

Petit essai de blocage afin de vérifier que le signal de non-rotation remonte bien à la puce de supervision. La diode orange de défaut s'allume bien, le problème est bien détecté. Nickel.

Les anciens à placer dans le bac des DEEE en déchetterie.

Montage interne avec les roulements.

Upgrade PC-NAS 2024

Thu, 14 Nov 2024 21:24:00 +0100

Hélas les images initiales de cet article ont été perdues suite à une mauvaise manipulation. 😒
Petit upgrade (CPU / Carte mère / RAM) de mon PC-NAS qui était encore avec un i5-4590S de génération Haswell (2014). J'ai succombé au renouvellement incessant. J'avais attendu la sortie des Ryzen 5 cet été et des nouveaux Intel Arrow Lake le mois dernier pour voir un peu. Compte tenu des tarifs et des avis des testeurs, aucune révolution en cours et aucun intérêt de prendre ces trucs neufs pour un usage NAS + divers. Le tout a donc été fait avec des pièces d'occasion issues du bon coin ou de retours clients Amazon (Warehouse / Seconde main). Mon choix s'est porté sur un petit i3, pas la peine d'aller chercher plein de cœurs pour une utilisation à 95% du temps en idle évidemment. Aucun intérêt d'aller sur de la 13ème ou 14ème génération sur l'entrée de gamme. D'après les benchmarks, 6% à 10% d'écart entre un i3 12100 et le 14100. Le ventilateur stock fourni s'avère largement suffisant. J'ai fait un petit upgrade du firmware de la carte mère qui a quelques versions de retard (F16 -> F19). L'ancienne était la AsRock H87M, dont j'avais remplacé la puce Ethernet il y a quelques années. Une Gigabyte B760M DS3H DDR5 la remplace. Bilan : 21 watts en idle sans les périphériques.

Quelques couacs rencontrés, loi de Murphy oblige, dans le SETUP UEFI, impossible d'activer le CSM, la carte mère le re-désactive d'elle-même au boot suivant, mon SSD de boot n'est donc pas listé. J'ai trouvé le pourquoi sur Internet : l'iGPU (si activé comme moi) réclame uniquement de l'UEFI.

Jusque là mon SSD de boot était en simple MBR (500Go) mon PC-NAS datant de quelques années déjà (16.04 ou 18.04). Bon, pas le choix faut passer en GPT/UEFI sinon évidemment pas de boot direct possible avec ce combo, il serait temps, la flemme tout ça... La procédure :

basculer la table des partitions du format MBR traditionnel à GPT, sans perte (minitool)
création de la partition supplémentaire de type ESP pour l'EFI avec minitool ou gparted / gedit
appeler grub-installer manuellement depuis le Live-DVD d'Ubuntu Desktop 24.04.1. Méthode avec les partitions /, /boot et /boot/efi séparées.
vérifier le /etc/fstab modifié (2 dernières lignes)

Code BASH :

jonathan@cerise:~$ cat /etc/fstab
# /etc/fstab: static file system information.
UUID=1699635b-c616-481b-9bf8-e6141d615841       /               ext4    noatime,errors=remount-ro       0       1
UUID=a28b8486-93c4-4fa2-9c69-f30fe228e546       /home           ext4    defaults                        0       2
UUID=0f6f1a0a-ef76-4b13-9a69-f4be8ddf1da8       /tmp            ext4    defaults                        0       2
UUID=0c0e568c-7159-4846-8eca-3c70cc7d42b5       /var            ext4    defaults                        0       2
UUID=5d6dd8cc-03d5-4f5a-ae0c-46c1a1474539       none            swap    sw                              0       0
UUID=b35137bd-9413-4958-9bc0-0d8b233baaeb       /nas            xfs     rw,user,exec                    0       2
UUID=fd2f2b3f-8a7e-4bb0-8c92-104e1e5f1b9b       /sauve_nas      xfs     rw,auto,nofail,user             0       2
UUID=0e24e8f3-427b-4008-80ac-7b871baef759       /sauve_sys      xfs     rw,auto,nofail,user             0       2
UUID=eafecb8b-de6d-4f26-9327-0e4d118cb3d0       /cctv           xfs     rw,auto,nofail,user             0       2
UUID=2ce833c8-c315-4176-84ee-7b22b942e3e3       /boot           ext4    defaults                        0       2
UUID=94B9-EAB5                                  /boot/efi       vfat    defaults                        0       1
jonathan@cerise:~$

Aucune donnée de perdue, pas de réinstallation système à faire, le noyau 6.8 prend déjà largement en charge cette plate-forme. J'avais déjà migré de la version d'Ubuntu Server 22.04 (jammy) à la 24.04 (noble) sans trop de casse en septembre. J'en ai profité pour sortir le SSD Crucial SATA et le remplacer par un NVME Samsung 990 Pro (caché sous le radiateur M2). Firmware à mettre à jour si besoin. Pas besoin ici, le mien était déjà livré en 4B2QJXD7, mais c'est une bonne chose à faire de mettre la dernière version avant une mise en service.

Code BASH :

jonathan@cerise:~$ sudo smartctl -a /dev/nvme0n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-48-generic] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 1TB
Serial Number:                      S6Z1NU0XXXXXXXX
Firmware Version:                   4B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 1 000 204 886 016 [1,00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       2.0
Number of Namespaces:               1
...

Clonage fait avec MiniTool disponible sur la clé USB Medicat (copie de disque à disque). Pour deux HDD internes et un externe USB (sauvegarde), la consommation au repos n'a pas bougé on reste sur une trentaine de watts. On aurait peut-être pu gratter plus avec un version suffixée T mais ils sont plus rares et aussi plus chers. Les particuliers ne les achètent pas, ils se tournent plutôt sur la version F qui dépourvue d'iGPU quand on a une carte graphique de gamer à coté. Donc les xxx00T d'occasion proviennent essentiellement de mini PC OEM USFF/Tiny de marque Dell/HP/Lenovo qui ont été dépouillés. Les températures sont très bonnes (CPU / carte mère et NVME) :

Code BASH :

jonathan@cerise:~$ sensors
gigabyte_wmi-virtual-0
Adapter: Virtual device
temp1:        +29.0°C
temp2:        +36.0°C
temp3:        +28.0°C
temp4:        +30.0°C
temp5:        +32.0°C
temp6:        +34.0°C
acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C
temp2:        +27.8°C
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +29.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:        +28.0°C  (high = +80.0°C, crit = +100.0°C)
Core 2:        +25.0°C  (high = +80.0°C, crit = +100.0°C)
Core 3:        +25.0°C  (high = +80.0°C, crit = +100.0°C)
nvme-pci-0100
Adapter: PCI adapter
Composite:    +33.9°C  (low  = -273.1°C, high = +81.8°C)
                       (crit = +84.8°C)
Sensor 1:     +33.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +37.9°C  (low  = -273.1°C, high = +65261.8°C)
jonathan@cerise:~$

Dell Latitude 5440

Sun, 28 Jul 2024 00:00:00 +0200

Voici mon nouveau PC portable, acheté d'occasion à un prix plus qu’honnête pour une machine aussi récente. La configuration est encore commandable en neuf sur le site de Dell. De quoi moderniser un peu mon vieux Thinkpad L460.

L'avantage ici étant que la RAM n'est pas soudée. Il était équipé de 8Go de RAM seulement, j'ai mis un couple de 2x8Go, soit 16Go au total, suffisant pour le moment.

Petite mise à jour de l'UEFI.

Le SSD de 256Go a été remplacé par un modèle de 1To.

Remplacement de la pâte thermique...

"Dual-Boot" (via UEFI) Windows 11 & Fedora 40 (KDE Plasma) chiffré BitLocker et LUKS. Avec quelques accessoires, il est prêt pour les vacances.

Y'a pas à dire, de nos jours les interfaces UEFI sont devenues vraiment jolies et intuitives.

Télécommande de présentation Logitech R400 (retrait soft-touch)

Fri, 19 Jul 2024 21:36:00 +0200

Une petite télécommande de présentation (PowerPoint/Impress) avec pointeur laser que j'avais acheté il y a plusieurs années. J'ai du m'en servir trois fois au début. Elle fonctionne, son seul problème : elle colle aux doigts et est ainsi inutilisable. A moins d’enchaîner les lingettes comme Monk. La faute au revêtement dit "soft-touch" qui souvent vieillit mal. Sont touchés souvent des appareils des années 90 et 2000 comme les baladeurs DCC de Philips (DCC134/170/175), le baladeur DAT Sony TCD-D3 ou encore certains tableaux de bord de voitures même des Maserati. Hélas souvent si on cherche à retirer cette couche on perd les inscriptions sérigraphiées de l'appareil. Ici ce n'est pas le cas.

Alimentée par 2 piles/accus AAA, elle possède un étui et elle a un dongle USB.

Avant de déclipser au mediator, deux vis sont à retirer dans le compartiment des piles.

Le laser est sur un PCB à part.

Après démontage, grattage avec polish et WD-40 au lavabo avec un éponge pourrie, dont l’abrasion est donc "plus douce" par rapport à une neuve.

Le résultat est nickel. J'ai sacrifié l'étiquette interne film plastique.

Remontage... le dongle USB se range dedans.

Remise en route serveur Lenovo x3500 M5 (5464)

Sun, 07 Jul 2024 20:20:00 +0200

Un serveur Lenovo modèle 5464-AC1 qui normalement devait fonctionnait (décommissionné fonctionnel). Malheureusement une fois sur mon bureau rien ne se passe au bouton en façade. Les alims tournent, ça clignote vert, mais pas de remise en route (pas de réaction). La petite remarque sur l'étiquette jaune et noir me fait tiquer : Removing air baffle will power off the system.

En gros il y a donc un capteur, un interrupteur quelque part qui vérifie la présence du guide d'air en plastique transparent sinon ça coupe.
Après recherche, ce capteur est planqué dans une cage en métal situé dans la partie haute.

Un ergot en plastique...

...appuie sur un petit mécanisme en plastique noir.

Derrière se trouve un interrupteur et une espèce de patin en caoutchouc un peu souple.

Ce patin avec le temps s'est fait écrasé par la tige de l'interrupteur (et son ressort). Cela n'appuie plus assez sur l'interrupteur pour détecter que le guide d'air est bien présent. La panne très conne quoi.

Solution : j'ai retiré l'ancien patin et j'en ai mis un légèrement plus épais. Depuis plus de problème.

On termine par un démontage pour nettoyage + remplacement de la pâte thermique pour les 2 CPU.

Maiwo K308SAS - Dock USB pour HDD/SSD SAS

Sat, 11 May 2024 00:00:00 +0200

Voici un modèle de dock spécifique capable de supporter les HDD/SSD au protocole et connecteur SAS. Pas utile au quotidien mais peut servir pour diagnostic ou recover. Disponible sur des sites chinois pour une centaine d'euros, nettement plus chers que les docks SATA usuels. Si les contrôleurs SAS peuvent prendre du SATA l'inverse n'est pas vrai. Et gare aux adaptateurs passifs. Morten Hjorth de la chaîne My Playhouse avait testé ce boîtier sous la marque INDMEM et il avait eu toutes sortes de des déboires avec.

Celui-ci y ressemble, la marque n'est pas la même mais le carton et l'apparence oui.

L'intérieur comporte une seule carte dont les soudures CMS sont de très bonne qualité.

On remarque d'ailleurs que me design semble dater du 16/11/2023. Le PCB a-t-il été revu depuis la vidéo de Morten datant de 2022 ? Le soft aussi ? Aucune idée.

Voici ce que l'on paye cher, la puce Initio INIC6711 (à gauche) qui fait la conversion SAS vers SATA. Impossible de trouver son datasheet.

La seconde puce (à droite) est un pont SATA vers USB classique Initio INIC-3639 que l'on retrouve dans certains boîtiers SATA <-> USB. Les deux ont un quartz de 25Mhz et une mémoire XTX XT25F04B (SPI Flash de 512Ko). Les broches du second port (S8 à S14) SAS sont absentes, aucune utilité pour un simple dock.

Le verso de la carte révèle par contre des soudures pas terribles faites à la main sur les composants traversants. C'est moche mais ça fonctionne.

Le bas du dock est lesté par une plaque de métal vissée pour alourdir un peu l'enrobage plastique.

Quelques essais avec des SDD/HDD.

Montage dangereux à ne pas reproduire. Cette cascade a été réalisée par un professionnel.

Certains dans les avis peuvent se plaindre que les disques SAS chauffent dans un tel boîtier, dans ce cas un simple ventilateur USB peut aider.

Utilisés sous Windows 11 avec HDSentinel 6.20 et HD Tune Pro 5.75.
Testé OK avec un SSD SAS Samsung. Les débits sont stables. Mais les deux logiciels ne ressortent pas les mêmes info SMART.

Avec la vidéo de Morten, je pensais à un problème de chauffe puisque les problèmes arrivaient souvent au bout d'un moment. J'ai sorti la caméra thermique, certaines puces montent un peu en température vers 65°C mais rien d'alarmant. Avec un HDD au format 2.5 pouces :

Même chose avec un HDD au format 3.5 pouces (plus consommateur d'énergie, donné pour 1A à 12V + 1A à 5V sur l'étiquette).

Rien à signaler lors de la torture d'un disque SATA de 1To pendant 4 heures.

J'ai pu faire gratter un vieux SAS-2 de 300Go 15Krpm pendant plus de 6 heures sans problème de déconnexion ou erreur.

Points négatifs :

Câbles fournis un peu courts.
Lecture limitée des données SMART (et température) avec les disques SAS, uniquement quelques valeurs retournées. RAS pour les HDD de type SATA c'est complet.

Remise en route serveur IBM X3400 M3 (7379)

Mon, 15 Apr 2024 21:45:00 +0200

Voici un vieux serveur System X (x86) de 2010, modèle peu optionné. Documentation en ligne : https://lenovopress.lenovo.com/tips0808
Celui-ci ne démarre pas intégralement. Du coup il a commencé à servir comme donneur d’organes par ses précédents propriétaires. Sa carte RAID SAS M1015 a été prélevée ainsi qu'une carte PCI classique (SCSI pour un streamer DAT, DLT ou LTO je suppose). La partie IMM fonctionne bien, image OK sur le port VGA mais au moment de laisser la main à la partie système PC x86... le serveur reste figé sur la ligne UEFI Platform Initialization.

C'est un problème récurrent sur ces modèles pour diverses raisons :

En premier on écarte d'éventuels paramètres BIOS foireux, donc j'ai retiré la pile CR2032 2 minutes + relance électrique comme évoqué sur cette page, du classique quoi, mais le problème était toujours là. J'ai ensuite utilisé le cavalier Boot Page Select pour démarrer sur l'image UEFI de recovery (genre de Dual-BIOS), dans le cas d'un firmware corrompu, hélas pareil.

On continue, la seule barrette de RAM de 4Go est bien sur le slot DIMM3, cela respecte la documentation, car il y a un ordre de peuplement à respecter. Ce n'est pas forcément la DIMM1 en premier à remplir.

Voici mon sauveur, le nettoyant contact.

J'ai retiré la barrette, badigeonné les slots avec cela (assimilable à de l'alcool), puis ré-installé la barrette...

Tadaa ! Le splash screen est là.
Ce plantage peut venir aussi d'un problème logiciel patché en version 1.11 sur d'autres modèles. Dans le setup la version relevée est la 1.05, le serveur n'a jamais été mis à jour depuis 2010.

Histoire d'éviter une potentielle chose similaire je le flashe avec la 1.17, dernière version disponible, en bootant sur un mini Windows 10 d'une clé USB Medicat.

Il faut mettre à jour aussi séparément l'IMM et les outils de diagnostic.
J'ai remis à zéro les paramètres de l'IMM, il a pris l'adresse 192.168.70.125 par défaut + remise à zéro couple login/mot de passe par défaut aussi : USERID/PASSW0RD.

Hélas pas de clé hardware enfourchée sur la carte mère pour avoir accès à la console à distance (46C7527/46C7528/46C7532). Il faut compter quelques euros sur Internet.

J'ai sorti la carte mère pour un dépoussiérage complet.

Donc réfection de la pâte thermique toute sèche par de la MX-4 suffisamment efficace.

Je ne sais absolument pas quoi en faire pour le moment.

Après MAJ de l'IMM en version 1.55...

j'ai eu le même problème que relaté sur ce topic (erreur 403 en XHR/Javascript, voir avec la console DevTools en F12). Impossible de se loguer. C'est OK en utilisant le mode de compatibilité Internet Explorer sous Edge.