framboise314.fr

Bonjour,
Je me posais une question toute bête. Est-il possible de modifier Raspbian pour une éxecution en ram ?
J'ai une application embarquée en extérieur (arrosage) et très peu besoin d'espace disque. Je ne veux pas utiliser de disque dur (et encore moins de SSD) mais je veux une fiabilité maximale (marre de griller des cartes SD à la pelle) parce que je ne veux pas angoisser sans arrêt et me demander si mon installation tourne toujours (arrosage la nuit).
Bref tout ça pour savoir s'il était possible de mettre la totalité d'une raspbian en RAM ? (pas d'interface graphique, la minimal quoi ) et surtout : COMMENT FAIRE ? Par ce que je suis une bille ...
J'ai bien vu quelques articles qui expliquent comment créer les partitions /tmp /var/tmp en mémoire et en utilisant ramlog pour gérer les logs en mémoire et les copier sur la SD moins souvent, mais est-ce que cette opération va accroitre de manière significative la durée de vie de ma SD ?

Merci de vos éclairages.

A+

Bonjour,

Personnellement, sur mon premier RPI B je suis seulement à la deuxième carte SD début 2013 qui est allumé H24.
Je fais en sorte de minimiser les écritures disque (pas de swap, pas de base de données locales, minimum de fichiers de logs)

Pour éviter l'écriture des fichiers de logs en local, si le PI est en réseau, il est possible de les envoyer sur un serveur de log en utilisant syslog.

Théoriquement, l'usure de la carte SD se fait par l'écriture, moins d'écriture => durée de vie plus longue.

A quelle vitesse les cartes SD sont-elles inutilisables ?

Au vu de ma compréhension de ramdisk, il est réservé à l'usage d'un filesystem vidé à chaque reboot du système. Je ne vois pas trop comment on peu avoir un OS sur ramdisk, par contre c'est bien indiqué pour un repertoire de log. De toute manière le filesystem hébergeant l'OS on très peu écriture théoriquement, il ne sont principalement modifié que lors des upgrade système.

A+

Bonjour,

Pour ma part, après avoir installé et configuré mon Pi pour les fonctionnalités dont il a besoin, je fait ensuite le necessaire pour que la carte soit en Read-Only.
C'est a dire que le système peut lire les fichiers, mais pas écrire sur la SD, tout ce qu'il doit écrire s'écrit en Ramdisk.
Sachant que se qui use les SD est l'écriture, et non la lecture, mes cartes dures bien plus longtemps qu'avant.

Pour cela, je me suis inspiré de l'article de Christophe BLAESS

Un peu de manipulation, mais ça vaut le coup.
Actuellement je teste un Rpi en boot USB sur un SSD de 64GO (25€ sur Amazon). Pour le moment ça tiens le coup, a suivre.....

Salut,

Je plusois ce qui est dit précédement : pas d'écriture sur disque, pas de pb.
Mon banana tourne depuis plus de 2 ans 24/24 et bidouille très souvent sur un second sans le moindre pb de SD.

jelopo a écrit : ↑

dim. 25 mars 2018 13:12

Au vu de ma compréhension de ramdisk, il est réservé à l'usage d'un filesystem vidé à chaque reboot du système. Je ne vois pas trop comment on peu avoir un OS sur ramdisk,

Il y a des distribs exprès pour ca, à commencer par l'excellent TinyCoreLinux ou tout est mis en RAM a grand renforts de squachFS.

Sinon, pour répondre à la question initial de ramirez22, à savoir le maximum de fiabilité, il risque d'y avoir des pb d'oxydation s'il est dans un environnement un peu humide.
La solution est alors :

• de le mettre dans une boite étanche et de faire bien attention aux passages des fils
• de privilégié plutot un SBC avec une flash ambarquée (certains modeles d'OrangePI, il me semble avoir vu que c'était aussi prévu sur un model de rPI-0 mais faudrait vérifier)
• passé plutot par un arduino ou, plutot un ESP8266
• eventuellement mettre un coup de vernis pour étanchéifier l'electronique

Le but est de s'affranchir de la SD dont les contacts s'oxyderont tot ou tard.

A+

destroyedlolo a écrit : ↑

lun. 26 mars 2018 11:35

...
[*]passé plutot par un arduino ou, plutot un ESP8266
...

Sur le fond tu n'as pas tort, même si on peut considérer que conseiller un ESP à quelqu'un qui pose une question Raspberry sur un forum Raspberry, c'est un peu comme aller au Buffalo grill pour vanter le restaurant végan d'à côté

Un ESP serait plus efficace (je joue avec un devkit 32) et présente plein d'avantages:
- GPIO avec des ports analogiques (détecteur humidité de la terre par exemple).
- faible consommation (pourrait fonctionner sur batterie + petit panneau solaire).
- Pas d'OS obèse.
- Pas de carte SD
- Démarrage immédiat
....

Sylvain

ramirez22 a écrit : ↑

dim. 25 mars 2018 10:03

...Je ne veux pas utiliser de disque dur (et encore moins de SSD) mais je veux une fiabilité maximale (marre de griller des cartes SD à la pelle) ...

je dis ca comme ca, mais W10 IoT Core permet d'utiliser la tech. UWF (Unified Write Filter) et c'est exactement fait pour ca.
Ce n'est ni plus ni moins que l'évolution d'EWF qui est utilisé dans l'industrie depuis les premiers XP Embedded et qui a très largement fait ses preuves.

spourre a écrit : ↑

lun. 26 mars 2018 11:55

Sur le fond tu n'as pas tort, même si on peut considérer que conseiller un ESP à quelqu'un qui pose une question Raspberry sur un forum Raspberry, c'est un peu comme aller au Buffalo grill pour vanter le restaurant végan d'à côté

C'est pour ca que j'ai aussi dit qu'éviter les écritures inutiles pouvait etre une solution (et surement la plus simple pour notre amis s'il ne connait pas les Arduino ... vu qu'il n'y a que 2 ou 3 config a changer).
Mais ca n'empeche pas de se pencher sur des solutions plus adaptées à ce genre de pb

Mais ca y est, j'ai griller ma premiere SD : celle de la go-pro qui a decidé qu'elle avait fait suffisamment de sorties de ski
Après quand même 4 ans d'usage intensif et sans doute plus une bonne centaines de sorties ... on ne va pas lui en vouloir

destroyedlolo a écrit : ↑

lun. 26 mars 2018 11:35

jelopo a écrit : ↑

dim. 25 mars 2018 13:12

Au vu de ma compréhension de ramdisk, il est réservé à l'usage d'un filesystem vidé à chaque reboot du système. Je ne vois pas trop comment on peu avoir un OS sur ramdisk,

Il y a des distribs exprès pour ca, à commencer par l'excellent TinyCoreLinux ou tout est mis en RAM a grand renforts de squachFS.
...

La remarque de Jelopo me semble pertinente. Pour monter le système en RAM, il faut bien le trouver sur un support bootable et, dans le cas du Raspberry, c'est principalement la SD carte.
Par curiosité, je suis allé sur le site de TinyCoreLinux que je ne connaissais pas et voila ce que je peux y lire:

Our goal is the creation of a nomadic ultra small graphical desktop operating system capable of booting from cdrom, pendrive, or frugally from a hard drive. The desktop boots extremely fast and is able to support additional applications and hardware of the users choice. While Tiny Core always resides in ram, additional applications extensions can either reside in ram, mounted from a persistent storage device, or installed into a persistent storage device.

Je pense qu'il n'est pas besoin de traduire. Pendrive est un mot "valise" qui, dans ce contexte, doit désigner l'USB. Il s'agit donc d'une distribution live, très légère, qui doit booter sur un support CDROM (y'en a pas sur le pi), USB (problématique) ou HD (le PO a été clair, il n'en veut pas). Comme toutes les lives, elle peut stocker des fichiers (ou des programmes) sur un support permanent (persistance).
Il ne faut pas oublier qu'au boot, le SOC du Raspberry démarre uniquement sur le GPU et ne sait pas faire grand chose.

Tout cela confirme que pour un usage "embarqué" aussi basique qu'un arrosage, le Raspberry n'est pas le meilleur choix (et là, je te rejoins).

Sylvain

spourre a écrit : ↑

lun. 26 mars 2018 18:01

Pendrive est un mot "valise" qui, dans ce contexte, doit désigner l'USB. Il s'agit donc d'une distribution live, très légère, qui doit booter sur un support CDROM (y'en a pas sur le pi), USB (problématique) ou HD (le PO a été clair, il n'en veut pas).

Avant tout, c'était pour répondre à la question de jelopo sur le fait de mettre un OS en RAMdisk. Je ne sais absolument pas s'il existe ne serait-ce qu'un portage sur rPI ou pas.

Ensuite, il ne faut pas confondre le contenant et le contenu.
Il est évidement qu'il faut un média quelconque pour le systeme (car il ne va évidement pas apparaitre de lui même en RAM par génération spontanée ). Cependant, contrairement aux autres distrib comme l’ancêtre DownSmallLinux, Slitaz et autre ToutouLinux qui sont livrés sur des ISO toutes faites, TCL est fait aussi (en plus des ISO) pour etre installé à la mimine sur n'importe quel média. Donc la procédure d'installation d'une clef s'applique très bien à une SD.
Il existe aussi une version encore plus légère nommée "Core" sans interface graphique. Ideale par exemple pour avoir une "clef de hacker" ou truc du genre.
L'un dans l'autre, c'est une distribution très puissante un peu dans la philosophie de Gentoo ou l'utilisateur (enfin, un peu plus quand meme ) installe uniquement ce qu'il veut. Les dépendances sont évidement respectées et les dites installes peuvent etre soit définitivement (modif du FS ou est installé TCL ou chargement automatique depuis le Net a chaque démarrage), soit pour la sessions (quand on reboot, c'est perdu).
Bref, on fait ce qu'on veut.

Utilisation typique que j'en ai eu :

• media center sur clef USB pour les long voyages TGV sans passer par les limites de l'OS de ma boite
• environnement jetable pour la "secrétaire" d'une garderie parfaitement refractaire a l'info : avantage, elle pouvait bien faire ce qu'elle voulait, il suffisait de rebooter pour retrouver un système saint. Et le tout sur une vielle bouse de 15 ans d'age sauvé de la déchetterie qui boutait en quelques secondes avec TCL.

Comme toutes les lives, elle peut stocker des fichiers (ou des programmes) sur un support permanent (persistance).

C'est une évidence : mais ici aussi, les choses ont été bien pensée et il y a plusieurs stratégies pour cette "synchro" ; l'une d'entre elle étant évidement de ne rien sauvegarder du tout (typiquement, pour un média center ou une clef "internet").

L'un dans l'autre, si TCL répond à la question d'"un OS en RAM", je ne suis pas sur qu'il serait adapté au genre d'automatismes demandés. Sans rentrer dans les détails (car je doute que ca passionne qui que ce soit sur ce forum), j'ai regardé pour l'installer sur des vieux P1 ou 486 pour s'en servir comme dashboard/terminaux de controle, mais son systeme de packaging est relativement complexe ... et vouloir y recompiler un kernel demanderait pas mal d'efforts pour justement comprendre ce mecanisme en profondeur et donc un temps que je n'ai pas. Gentoo était alors plus indiqué (ca a donné entre autre la tablette brickée recylée sous Linux qui me sert de dashboard pour ma domotique)

A+

Oula ! Je m'absente une semaine et le topic déchaine les passions

Premièrement, merci à tous pour vos interventions. J'avoue que j'ai pas tout suivi, je vais relire tout ça à tête reposée (newbie inside en plus).
J'ai bien compris que le raspi n'était peut être pas le plus optimum dans l'affaire, mais j'avoue que certaines applications déjà toutes faites m'intéressent particulièrement (Jeedom par exemple ou d'autre systèmes déjà tout fait pour de la domotique). C'est autant une question de temps disponible, que de fainéantise, je dois l'avouer .

S'il n'y avait pas l'avantage de l'interface web déjà développée, je serais volontiers parti sur un PIC. Là, pas de soucis puisqu'il n'y a pas d'OS à s'occuper, juste du programme en assembleur (et de ce côté, je n'ai pas de problème). C'est un gros automate quoi.

J'ai également à dispo un Arduino Uno avec une Ethernet shield (je sais même pas ce que c'est, j'ai touvé ça dans un coin, mais j'ai même pas eu le temps de me pencher dessus). Je vais peut-être regarder de ce côté.

En tout cas merci de vos interventions. Je vais sans doute commencer par un Raspberry avec quelques modifications de l'OS pour essayer de maintenir la SD le plus longtemps possible, et en parallèle, jeter un œil sur l'Arduino.

Cdt,
Ramirez22