framboise314.fr

bonjour je cherche un système qui ce lancerais directement dans la mémoire (ram ) du pi
je souhaite que le système puisse subire des déconnections électrique sans dommage pour celui si

Salut,

Le systeme lui-même n'a pas besoin d'être en RAM, il suffit que tous les FS dynamique soit en tmpfs, à savoir :

• /home
• évidement /tmp et /var/tmp. Pour les autres répertoires de /var, ça dépend de ta distribution, donc ca se fait au cas par cas (typiquement, j'utilise Gentoo qui y stock la liste des packages installés)
• évidement aussi, désactive la swap (qui de toutes facons n'a rien a faire sur une SD
• Idéalement, il faut aussi que ton réseau soit en IP statique sinon il va écrire des chose dans /etc

Ensuite, inotifywatch qui se trouve dans un package qui devrait se nommer inotify-tools indiquera si des choses sont passées à travers.

A+

Bonjour,

J'ajouterai de mettre le /var/log en tmps,
Pour le DHCP, il faut créer en /etc/resolv.conf un lien symbolique vers /run/resolv.conf car c'est dans ce fichier que le système enregistre les DNS à chaque démarrage.

Yo,

Pour le /var/syslog, on peut aussi voir dans la configuration de syslog : ainsi, on peut ne conserver sur SD que les infos vraiment critique (genre un disque ou une alim qui est en train de lacher grrrr, ) et supprimer tout le reste.

A+

Bonsoir,

Je ne suis pas du tout certain, mais alors pas du tout, que vos réponses correspondent aux besoins du PO.
Il faut reconnaître, à votre décharge, que son expression est clair comme du jus de boudin.

Qu'entend-il par système ? Est-ce le système d'exploitaion complet, juste le kernel, le RFS ?
Vous, vous répondez en Files System (FS).

Je ne suis pas persuadé que mettre le home en tmpfs réponde à son critère

je souhaite que le système puisse subire des déconnections électrique sans dommage pour celui si

Je ne comprend pas non plus cette affirmation:

destroyedlolo a écrit :Salut,
....
Le systeme lui-même n'a pas besoin d'être en RAM, il suffit que tous les FS dynamique soit en tmpfs, à savoir :

Si on parle bien du système d'exploitation donc, au minimum, du kernel, d'un gestionnaire de fichiers et des drivers (modules), il me semble que tout ce beau monde ne peut s’exécuter qu'en RAM et qu'il doit y être chargé (chaque programme y est chargé par le loader qui doit, entre autres choses, faire la translation d'adresses, réserver la pile, demander un espace de mémoire virtuelle...).

Je ne vois pas de solution pour mettre directement en RAM puisque, même les bonnes cartes embarquées qui disposent de mémoire NAND pour sauvegarder le système, n'échappent pas à ce mécanisme de chargement en RAM.
Le seul avantage de ces cartes, est qu'elle répondent bien au critère du PO et acceptent un arrêt électrique brutal (évidemment , non sans risque pour les fichiers en cours d'écriture mais le RFS peut être monté en "read only".

Sylvain

spourre a écrit :Le seul avantage de ces cartes, est qu'elle répondent bien au critère du PO et acceptent un arrête électrique brutale (évidemment , non sans risque pour les fichiers en cours d'écriture mais le RFS peut être monté en "read only".

De mon coté, mettre le FS en "read only", c'est la solution que j'adopte sur mes Raspberry en production. Pour ce faire, je prend pour base ce tuto de Christophe Blaess.
De cette façon, risque diminué pour crash du système, c'est peut-être une des solutions possibles pour ton utilisation, mais un peu plus complexe à mettre en oeuvre, que mettre les activités système en RAM, si nous avons bien compris ta question initiale.

domi a écrit : De mon coté, mettre le FS en "read only", c'est la solution que j'adopte sur mes Raspberry en production. Pour ce faire, je prend pour base ce tuto de Christophe Blaess.
De cette façon, risque diminué pour crash du système, c'est peut-être une des solutions possibles pour ton utilisation, mais un peu plus complexe à mettre en oeuvre, que mettre les activités système en RAM, si nous avons bien compris ta question initiale.

C'est ce très bon tuto que j'avais à l'esprit en rédigeant ma réponse (ne pas oublier de remettre en write pour les mises à jour).
Mais, comme il est assez technique, j'attendais que le PO précise davantage son besoin (et son niveau) avant de le lancer dans du dur.
Nota: même ton expression "activités système en RAM" est peu précise. Sauf erreur de ma part, à part le contenu des registres et du cache du processeur, toute l'activité système est en RAM. Tu veux peut-être parler des conséquences de l'activité système qui génèrent une écriture (les logs en particulier).

Sylvain

Oui je veux effectivement parler des LOG principalement, mais également des fichiers écrits ou mis à jour au démarrage du système, comme par exemple le fichier "/etc/resolv.conf" pour la config DHCP que je redirige via un lien symbolique vers "/run/resolv.conf"

Il y a aussi des distributions faites expressément pour fonctionner en RAM à l'instar de TinyCoreLinux: j'en suis content sur PC ou je l'utilise pour des clefs bootables et il me semble (conditionnel donc) qu'il a été porté sur PI. Le blême est que le nombre de packages est réduit...

Envoyé de mon E2303 en utilisant Tapatalk

destroyedlolo a écrit :Il y a aussi des distributions faites expressément pour fonctionner en RAM à l'instar de TinyCoreLinux: j'en suis content sur PC ou je l'utilise pour des clefs bootables et il me semble (conditionnel donc) qu'il a été porté sur PI. Le blême est que le nombre de packages est réduit...

C'est une piste intéressante. En fait, c'est une live et tout se perd à la coupure, voulue ou non voulue.
Toutefois, certaines distributions permettent de garder une partition, sur le support amovible, pour sauvegarder des fichiers de configuration, préférences .. c'est la notion de persistance.
A voir si cela existe pour le Raspberry, n'en ayant pas le besoin, je n'ai pas cherché (mais je l'avais vu pour tester une Ubuntu sur un vieux mac).

Sylvain