Journal Partition root en read-only sur une compact flash

Posté par  .
Étiquettes : aucune
0
3
déc.
2007
Bonjour,

Il y a quelques semaines, sur les forums de linuxfr, je me demandais comment construire un petit système embarqué fonctionnant sous linux et utilisant un disque sous forme de compact flash.
Avec la double problématique:
1- le système doit bien résister aux crashs (il n'y a pas de procédure d'arrêt)
2- il faut limiter les écritures pour préserver la flash (nombre de cycle d'écriture limités)
J'avais eu peu de réponses ici et j'ai trouvé peu de documentations ailleurs...

J'ai finalement utilisé Unionfs pour résoudre mon problème.
J'ai mis par écrit ce que j'ai fais sous forme d'un petit tutoriel.
C'est ici:
http://electronicfr.com/index.php/fr/Embedded-computing/Cons(...)
N'hésitez pas à me faire part de vos remarques, vous aurez peut être d'autre idées.

Le message initial sur le forum: http://linuxfr.org/forums/43/22775.html
  • # busybox + initramfs

    Posté par  (site Web personnel) . Évalué à 4.

    Bonjour,

    Si tu veux un système tres leger et tout en mémoire, une busybox avec initramfs est ideal.

    L'acces a la CF ne se fait qu'au demarrage: tout en mémoire, modifiable, mais au reboot on repart sur la configuration d'origine.


    mes 2 cents.
    • [^] # Re: busybox + initramfs

      Posté par  . Évalué à 3.

      Ça, ça m'intéresse! Un lien vers un HOWTO ?
      • [^] # Re: busybox + initramfs

        Posté par  (site Web personnel) . Évalué à 2.

        Je suis désolé, je n'ai pas ça sous la main.

        En gros les étapes sont:

        Installer busybox dans un "dossier".

        dans ce dossier:
        $ find . -print | cpio -o -Hnewc | gzip > boot/initramfs.gz
        place le fichier initramfs dans dossier/boot

        Par la suite installer grub avec la configuration:
        kernel /boot/vmlinuz-version root=/dev/initramfs rw
        initrd /boot/initramfs.gz
        savedefault
        boot


        Si je retrouve le tutorial, je te le fais parvenir de suite.
  • # StatelessLinux

    Posté par  . Évalué à 4.

    http://fedoraproject.org/wiki/StatelessLinux

    La page est assez peu informative, mais un des principes est que ça doit tourner avec une partition root en read-only.
    C'est avec cette "technologie" (+ d'autres trucs) que sont fait les livecd ou clée USB Fedora.

    Pour faire une clée USB bootable et read-only :
    http://www.redhatmagazine.com/2007/11/07/i-am-fedora-and-so-(...)
  • # comme un auto-radio

    Posté par  (site Web personnel) . Évalué à 4.

    Il y a quelques années, il y avait eu un article très complet dans linux-magazine, c'était sur un linux embarqué dans un autoradio. Il y avait des petites astuces pour les crash et limiter les écritures (root en ro, /tmp et /var/log en ram, etc.).
    Bon je ne me souvient pas de grand chose, alors ça ne te sert à rien, mais ça peut t'orienter vers les quelques fabricants/bricoleurs d'auto-radio-lecteur-dvd-gps embarqués. Il y en a un en France, qui pourra sûrement te donner des conseils.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: comme un auto-radio

      Posté par  (site Web personnel) . Évalué à 2.

      Je ne puis m'empêcher de rebondir là dessus puisque je suis modo sur un forum spécialisé là dedans: carmedia.org
      (Bon le site est "en travaux" actuellement, il faut aller directement là www.carmedia.org/forum )
      Et justement le but est de remplacer un autoradio et même faire un peu plus et un peu mieux. Ce sont quasi tous des accros Windows, en tout cas les carpc sont sous windows grace à/à cause des GPS
      Je dois être le seul survivant avec un projet sous linux (les autres se sont barrés à cause de l'esprit fermé qui commence à peine à s'ouvrir)
      et d'ailleurs j'aurai bien besoin d'aide pour progresser, je ne suis pas développeur, même si j'ai quelques notions, du coup je n'arrive pas à avancer.
      (J'avais demandé de l'aide ici: http://linuxfr.org/forums/10/22854.html )
      J'arrête le Hors sujet, mais je suis toujours demandeur :)
  • # nanobsd

    Posté par  (site Web personnel) . Évalué à 2.

    Il y a aussi nanobsd (et d'autres mais celui-là on l'a directement dans /usr/src/tools dans freebsd) grossomodo on dit ce que l'on a (une carte de 128meg par exemple, le nombre de secteurs... se trouvent dans un fichier en supposant que ta carte existe sinon faudra la déclarer mais rien de méchant) et à partir de là il cré une image / en ro, la possibilité de monter /cfg pour y mettre ses fichiers de conf en dur car tout le reste est virtuel.

    Et puis on peut y mettre un noyau sur mesure, pratique pour l'embarqué. et une fois les deux fichiers de conf créés (option et noyau) chaque mise-à-jour se fait en une seule ligne de commande.

    Ce n'est pas du linux mais cela a aussi le mérite d'être assez bien documenté, dans le handbook entre autre.
  • # Voyage Linux

    Posté par  . Évalué à 2.

    Je ne sais pas si cela t'intéresse, le projet Voyage Linux te permet d'installer une Debian (Etch en l'occurrence) sur une compact flash.
    Installation minimaliste sur une compact flash (au minimum de 128Mo).

    C'est ici : http://linux.voyage.hk
  • # Quelques remarques

    Posté par  . Évalué à 3.

    C'est pas mal de faire une page comme ça. J'avoue que j'ai quelques connaissances, mais je n'ai jamais retrouvé de ressources qui réunisse vraiment tout. Une bonne ressource est quand même tout ce qui tourne autour de Gentoo (le wiki, etc ...), il y a pas mal de bidouilleurs qui aiment faire ce genre de trucs.

    Concernant ton premier exemple, je ne comprend pas l'utilité d'unionfs ....!? Tu pourrais simplement monter /etc et /var en tmpfs, copier le contenu depuis la partition en ro, et hop, sans rien de spécial. La difficulté que tu as vu c'est peut-être "comment copier le contenu de /etc en ro dans le /etc en tmpfs vu qu'ils sont au même endroit ?" : tu peux d'abord monter le tmpfs dans un coin, et utiliser l'option "-o move" de mount pour le bouger dans /etc.

    Sinon, autre remarque : /etc/mtab ça ne sert pas à grand chose d'essayer de le synchroniser à la main. Fait directement un lien symbolique vers /proc/mtab, c'est pareil. J'ai remarqué que c'est (quasiment) le seul fichier modifié dans /etc, si tu ne modifie pas la conf de ton système (dans le cas d'un système qui doit pouvoir retourner dans son état d'origine par un reboot, ce qui n'a pas l'air d'être ton cas).

    D'ailleurs, j'ai vu que tu ne montais pas /proc ni /sys dans ton exemple : c'est parce que tu as supposé que c'était déjà fait ?

    Sinon, n'oublie pas non plus /dev en tmpfs, en ayant créé (ou demandé à udev) les périphériques initiaux (pour un initramfs, le strict minimum c'est /dev/console et /dev/null je coirs).

    Enfin, pourquoi faire un unionfs par partition que tu montes en rw ? Tu pourrais mettre un / en rw par dessus un / en ro.

    Sinon, le "successeur" d'unionfs c'est aufs, je ne sais pas vraiment sur quels points il est mieux.

    Si tu veux un bon exemple, je pense que OpenWRT est pas mal (ils ont un / en squashfs et un / par dessus avec unionfs ou un truc du genre).
    • [^] # Re: Quelques remarques

      Posté par  . Évalué à 1.

      Merci beaucoup pour tes remarques très pertinentes.
      Le premier exemple est la pour être un peu didactique, mais je dois avouer que je ne connaissais pas l'option -o move.
      Pour le mtab tu as raison, je me complique la vie pour rien. Par contre ce n'est pas le seul fichier qui bouge dans etc, surtout quand on utilise DHCP, il y a tout ce qui concerne le réseau (resolv.conf...).
      Pour ce qui est des unions séparés pour /etc/ et /var... je dois dire que ta solution est aussi plus simple, je vais tester et modifier le document.
      Concernant aufs, il faut préciser que ce n'est pas LE successeur de unionfs mais un autre "stackable file system" pour linux. Le projet unionfs est toujours très actifs, aussi bien les développements, que la mailing list. Par contre il est vrai que pas mal de monde switch actuellement vers aufs, en particulier parce que l'accès aux branches est mieux géré. Ce qui me gène avec aufs c'est que c'est encore moins documenté que unionfs!
      Merci
      • [^] # Re: Quelques remarques

        Posté par  . Évalué à 2.

        Oui c'est vrai, j'avais oublié pas mal de truc qui sont modifiés dans /etc. J'en viens à me demander comment j'avais réussi à mettre un /etc en ro .... je crois que c'était parce que je n'utilisais pas de DNS. En tous cas, un système sans changement de configuration devrait pouvoir avoir un /etc en ro, les modifications de fichiers dans /etc lors de l'exécution normale de la plateforme sont là uniquement pour des raisons historiques. Normalement (vive la normalisation), tout ce qui bouge doit être dans /var. D'ailleurs, je crois que resolv.conf est un lien vers /var/...resolv.conf dans openwrt. Ca peut être pas mal comme idée pour contrôler ce qui se passe dans /etc : faire des liens dans /var pour ce qui n'est pas statique (bon, je suis toujours dans une optique d'un système dont la conf ne change jamais, ce qui n'est pas ton cas ici).
        Pour le / en rw par dessus le / en ro, ce que je t'ai dis me "semble" plus simple, mais je ne garantie pas vraiment que tout fonctionne bien comme ça (en particulier, il ne faut pas oublier de monter les /tmp & autre en tmpfs encore au dessus du / en rw). Mais il me semble que c'est comme ça que fait OpenWRT (je peux voir les FS originaux dans /rom pour le ro et /jffs pour le rw, sur mon routeur : tous les noms de fichiers sont relatifs à / ).
        Pour aufs, pareil, c'était une supposition, je ne connais pas vraiment bien. Mais effectivement, dans ce genre de projet, le gros point noir c'est la doc .... et ton document est pas mal pour aider sur ça !

        Bon courage pour la suite.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.