L'utilisation d'un système de files racine en lecture seule est-elle une bonne idée pour l'installation embeddede?

J'ai été chargé d'exécuter Linux en tant que operating system sur un périphérique embarqué.

La cible a un processeur x86 et dispose d'un dispositif CompactFlash de 8 Go pour le stockage.

J'ai réussi à utiliser buildroot pour créer l'image du kernel et les outils de compilation croisée. J'ai partitionné le périphérique CF dans une petite partition FAT où réside l'image du kernel ainsi que la configuration de démarrage syslinux et un système de files ext3 où j'ai décompressé le système de files racine généré par buildroot.

Le système démarre correctement en utilisant syslinux en définissant le directory racine sur la partition CF ext3 où se trouve mon système de files buildroot.

Ma question est cinput sur le besoin de robustesse face à la perte de puissance immédiate (et fréquente) car il est crucial que l'appareil démarre correctement après les coupures de courant. J'ai lu que monter le système de files racine en lecture seule est un moyen d'assurer l'intégrité des données. Est-ce une façon raisonnable pour moi de procéder?

J'ai également lu sur la possibilité de charger le système de files racine dans la RAM pour réaliser la même chose, mais ne sais pas encore comment le faire.

Y a-t-il un moyen privilégié pour atteindre cet objective et, dans l'affirmative, quelle est la meilleure façon de procéder?

    Nouvelle réponse (2015-03-22)

    ( Note: cette réponse est plus simple que la précédente, mais pas plus sécurisée.) Ma première réponse est plus forte car vous pouvez garder les files en lecture seule par les options de assembly fs avant les drapeaux d'autorisation. du tout.)

    Oui, sous Debian , il y a un packageage: fsprotect ( page d'accueil ).

    Il utilise aufs (par défaut, mais pourrait utiliser un autre outil unionfs ) pour permettre des changements de session en direct, mais en RAM par défaut, donc tout est oublié au redémarrage.

    Vous pouvez les installer en exécutant simplement:

     apt-get install fsprotect 

    Une fois terminé, à partir du document en ligne:

    Après ça:

    • Editez /boot/grub/menu.lst ou /etc/default/grub2 ou /etc/lilo.conf et ajoutez " fsprotect=1G " aux parameters du kernel.
    • Modifiez 1G si nécessaire.
    • Appliquer les modifications (c. update-grub d. Exécuter update-grub )
    • Editez /etc/default/fsprotect si vous voulez protéger les filesystems autres que / .
    • redémarrer

    Vous pouvez également protéger par mot de passe le chargeur de démarrage de Grub ou interdire toute modification.

    De là, si un file est protégé contre les changements, pour l'échantillon par

     chmod ugo-w myfile 

    si vous utilisez pour l'échantillon vi myfile et essayez d'écrire dessus avec la command :w! , cela fonctionnera et votre myfile sera changé. Vous pouvez redémarrer afin de récupérer myfile non myfile .

    Ce n'est même pas possible avec ma première solution suivante:

    Vieille (première) réponse:

    Oui, c'est une solution forte, mais puissante!

    R / o utilisable

    Vous devez monter quelques directorys dans rw , comme /var , /etc et peut /home être /home . Cela pourrait se faire en utilisant aufs ou unionfs . J'aime ça d' une autre manière , en utilisant /dev/shm et mount --bind :

     cp -a /var /dev/shm/ mount --bind /dev/shm/var /var 

    Vous pourriez avant, déplacer tous les directorys qui ne doivent pas changer en fonctionnement normal dans un static-var , que de créer des liens symboliques dans / var:

     mkdir /static-var mkdir /static-var/cache mkdir /static-var/lib mv /var/lib/dpkg /static-var/lib/dpkg ln -s /static-var/lib/dpkg /var/lib/dpkg mv /var/cache/apt /static-var/cache/apt ln -s /static-var/cache/apt /var/cache/apt ... # an so on 

    Ainsi, lors du reassembly dans ro, la copy /var dans /dev/shm ne prend pas trop de place car la plupart des files sont déplacés vers /static-var et seuls les liens symboliques doivent être copiés dans ram.

    La meilleure façon de le faire finement est de faire un cycle de puissance complet, une journée de travail complet et de bien exécuter une command comme:

     find / -type f -o -type f -mtime -1 

    Vous verrez donc quels files doivent être situés sur une partition en lecture-écriture.

    Enregistrement

    Comme dans cet hôte, aucune memory statique inscriptible n'existe, afin de stocker l'historique et les autres journaux, vous devez configurer un server syslog distant.

     echo >/etc/syslog.conf '*.* @mySyslogServer.localdomain' 

    De cette façon, si votre système se casse pour une raison quelconque, tout ce qui précède est enregistré.

    Mise à niveau

    Lors de l'exécution avec un mount --bind en cours d'utilisation, pour effectuer une telle mise à niveau pendant l'utilisation du système (sans avoir besoin d'exécuter init 1 , pour réduire les time d'arrêt), le plus simple est de rebuild une racine propre faire la mise à niveau:

    Après avoir remonté '/' en mode lecture-écriture :

     mount -o remount,rw / for mpnt in /{,proc,sys,dev{,/pts}};do mount --bind $mnpt /$mnt$mpnt; done chroot /mnt apt-get update && apt-get dist-upgrade exit umount /mnt/{dev{/pts,},proc,sys,} sync mount -o remount,ro / 

    Et maintenant:

     shutdown -r now 

    J'ai seulement de l'expérience en utilisant un buildroot plus récent (2014-02). Dans cette version, vous pouvez désactiver «remonter le système de files racine en lecture-écriture du démarrage» dans le file de configuration avec:

    BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW n'est pas défini

    J'ai réussi à créer une image qui utilise juste son ext4 / partition en lecture seule afin de détwigr la puissance du système ne pas nuire du tout. Cela fonctionne très bien, donc si vous n'avez pas besoin d'écrire dans votre système de files, c'est peut-être une solution bien plus simple que celle mentionnée ci-dessus (qui semble plus ou less applicable à un système Debian).