Je fais mes premiers pas sur raspberry et sur linux.
Je me suis acheté un raspberry pi zero 2W.
Je l’ai testé avec la carte SD et cela a fonctionné (raspberry pi os préinstallé)
J’ai également réussi a installer PI OS sur une clé usb (Corsair 8Go) et cela fonctionne également.
J’ai testé l’image de jeedom (jeedom-debian-buster-rpi-4.1.27.zip) et cela fonctionne sur la clé USB
J’en suis à l’étape de tester un disque dur (avant d’investir)
Sous la main, j’ai des vieux disques IDE (PATA) avec un adaptateur USB.
J’ai testé avec un IDE 2.5 de 10Go et un autre de 160Go.
Avec PI imager, je n’arrive pas a finaliser la copie de l’OS (il plante à la fin de l’écriture juste avant la vérif en disant qu’il y a un problème d’écriture)
Avec Etcher, la copie et la vérification se passe bien mais le démarrage de l’OS est laborieux (plein de FAILED dans les logs de démarrage).
La première erreur que j’ai cru apercevoir est liée au système de fichier (Kernel File System)
A noter que sous windows, les disques semblent OK (pas de problème rencontré)
Sous PI OS (carte SD), les disques sont bien reconnus en tant disques externes
Comment puis je avancer ?
Peut-on faire un démarrage en mode debug pour m’arrêter sur les premiers FAILED ?
Tes disques dur en IDE doivent daté de plusieurs années, alors c’est eux la faute, faudrais consulter les données du SMART mais je suis sur que tu as plusieurs secteurs défectueux.
Quand ont utilise une unité de stockage , comme les HDD, le système ne sais pas si les secteurs sont « ok », et il arrive 2 cas de figure en cas de problème. Ceci n’est pas applicable lors d’une copie d’une image sur un support, n’ayant pas de système de fichier sur qui compter.
Quand un système écrit sur un unité de stockage, il vérifie le secteur, si il a une erreur, ile tentera de l’écrire dans un autre secteur, ceci va ralentir le système et si il y a trop de secteur défectueux, causé des erreurs (I/O), une fois trouvé. une place ou écrire il marqueras tout les secteurs qu’il a testé en « bad ».
Quand il arrive pour lire, si il n’y arrive pas, il peut tenter à quelques reprise avant de mettre le secteur en « bad », la donnée présente dans ce secteurs est dont perdu et le système va arrêter de regarder/utiliser ce secteur.
Lecture de SMART
Offline_Uncorrectable / Uncorrectable_Error_Cnt = Secteur « bad » dont il tente de corriger en déplaçant les données dans un secteur « ok ».
Reallocated_Sector_Ct = Nombre de secteur corrigé et « sauvé ».
Seek_Error_Rate = Nombre de fois qu’il tente de ce positionner pour lire mais que le curseur (tête de lecture) est à la mauvaise position.
Ce sont des signes de la fin de vie du HDD.
Pour « fixer » le disque dur, sous WIndows, prent Minitool Partition Wizard, détruit les partition et refait le MBR, fait un test de surface et après install s’y un système de fichier dans 1 seul partition (par exemple NTFS), fait un formatage intégrale. Cet option permet durant le formatage de tester les secteurs et d’en noter les mauvais. Ce sera long, car vraiment chaque « bytes/sector » sera testé.
Un formatage rapide efface que l’index dans le MBR, sans toucher à la surface de stockage. (ne pas faire avec un HDD potentiellement défectueux)
sur ton système qui fonctionne tu peux branché le disque en IDE et déjà voir comment il le « digère » ds un terminal: tail -f /var/log/syslog
tu branches le disque et tu devrais voir les éventuelles erreurs…
je suppose que le disque est alimenté par une source exterieur , pas par le Rpi ?
Normal, vu la taille et la vitesse d’accès, se sera aussi long en formatage intégrale.
Noter que le test de surface est seulement pour tester la « lecture » et non l’usage normal d’un disque dur. Ce test ne vas nécessairement donner des « bad », mais si c’est le cas, c’est souvent du à un dommage physique des disques du HDD (égratignure).
Il existe des programme, comme « hwtest » ou « Hddtest » qui vont aller plus loin avec une écriture et une lecture en vérification, ces test plus long et qui détruise les données sont plus fiable, car ils testent tout les secteur en RW. Par exemple des 32GB SD de chine sont 100% ok en test d’écriture mais en lecture, seulement les 8Gb en premier le sont réellement et le reste est « perdu ».
Passage H2testw (lecture/écriture) en cours … (estimation 2h)
J’ai retrouvé un autre disque IDE dans un boitier USB.
PI imager s’est bien passé (écriture+vérif)
Au démarrage, on voit les led d’activité du disque s’allumer pendant 2-3sec puis plus rien (écran noir, la led du pi0 semble un peu clignoter mais il ne se passe rien).
Mais comme comme il n’est pas auto-alimenté, cela vient peut être de la.
Un disque dur au « Boot » demander 2x plus de puissance que en « idle », c’est ce que la majorité des appareils font également (pas le double mais un « peak »). Alors si il est auto-alimenté par le RPi, surtout le Zero v2, tu ne dois pas lui donner assez de puissance.
Après, ça peut être au délais « sync » entre le moment que le système cherche le OS et le temps de démarrage et réponse du disque dur. Les IDE sont vieux et leur vitesse lente, et avec l’âge, rien ne s’améliore.
Le plus simple et « safe » est d’utiliser les HDD en ta possession comme unité externe via le USB. Utilise une carte microSD, qui donne de meilleur performance que les disque dur IDE. Tu auras un meilleur OS et plus de fiabilité. Tes disque dur serviront alors de storage, avec LVM tu peux créer un lecteur logique groupant tes 2 disques dur (il s’additionne) et déplacer le /home sur eux.
Bonjour,
Le disque ne contenait aucune erreur.
Le test de lecture/ecriture a duré environ 5h sans détecter d’anomalie.
Mais au premier test avec PI imager, j’ai l’erreur "Erreur d’écriture dans le stockage (pendant l’exécution de fsync)
Donc, je pense que cela ne vient pas du disque mais de l’adaptateur IDE/USB
Les paramètres cités dans mon précédent message ne semblent pas faire mieux.
Pour tester, je me suis amusé à cloner la carte sd sur le disque avec etcher.
On progresse car il boot, je vois le logo de raspberry os pendant 2sec puis il reboot et plus rien.
SI le boot semble problématique, je dirait vite comme ça, le MBR est corrompu. Sinon oui, l’adapteur IDE@USB peut causer problème, dépend de comment il « s’affiche », Certain comme disque dur, d’autre comme lecteur USB, dépend de la qualité du produit.
Petite note; du USB 2.0 tombe en USB 1.1 si un problème de compatibilité, la vitesse et le voltage « drop ». Le USB 3.x c’est autre chose, si il n’est pas pris en charge en 3.0, il tombe en 2.0 (compatible mode), il ne peut pas être en 1.1.
De souvenir (dont a vérifier les détails)…
USB 1.0 c’est 12Mbps et 1.5v (clavier, souris, le reste rarement compatible)
USB 1.1 c’est 12Mbps à 5V
USB 2.0 c’est 480Mbps à 5V (max 1.8A)
USB 3.x c’est 5Gbps à max 20V (max 5A) (5V sur PC)
Je reviens juste donner un petit retour d’expérience.
Suite a nos différents échanges, je sais maintenant que le boot USB est fonctionnel mais pas sur du vieux matos.
Je tourne actuellement sur un CarteSD avec sauvegarde (externe) quotidienne.
J’ai prévu d’investir dans un SSD ou mSata prochainement.
J’ai un JEEDOM qui tourne sur ce PI 2W.
En terme de puissance, ca le fait.
Le bémol se trouve sur la mémoire. J’ai du désactiver des plugins pour le garder en vie et je suis à 70-75% d’occupation mémoire (avec des pointes à 90%)
Fait attention a ou tu prend la valeur de l’utilisation mémoire, j’ai remarqué que sur les dernières version de Linux (CentOS / Debian), le système prend 90% des ressources même si en utilise moins, comme si elle serais « réservé ».
Par exemple, mes deux serveurs domestique qui ne font que du Apache + Samba. En réalité il utilise moins de 512Mo de la mémoire.
Vieille version, certes, mais au début, il prenais que la ram nécessaire, depuis une MaJ voila … 1 ans dans les alentour de… la consommation à augmenté, j’ai examiné la situation et ce n’est pas tout les programme qui donne la même information. Ce serveur a déjà eu 6Go de ram, et il en utilisait dans les 5.6Go, pourtant aucun travail de plus à faire.
