La plupart des systèmes embarqués utilisent un noyau personnalisé. Un outil pour faciliter cela est Buildroot Un ensemble de scripts pour construire la chaîne d'outils GNU gcc, la bibliothèque uClibc à la place de la (énorme) GNU libc, le noyau Linux, BusyBox et d'autres utilitaires/packages pour le système de fichiers racine d'une carte embarquée. Le RaspberryPi est une carte relativement nouvelle, donc son support dans Buildroot est toujours en cours de développement, mais il y a apparemment un système de fichiers racine de la carte. projet , un autre projet et un travail personnel . Il y en aura probablement d'autres à mesure que la fabrication de RP s'accélérera et que la distribution s'améliorera.

En utilisant Buildroot, vous pouvez construire un noyau Linux et un système de fichiers racine exactement comme vous l'avez décrit dans votre question. En fonction de la vitesse de votre connexion Internet et des capacités de votre PC de développement, vous pourriez disposer des binaires en 1 à 4+ heures. L'inconvénient est que les binaires résultants ne sont pas testés ni garantis pour démarrer et s'exécuter avec succès. Une console système est obligatoire pour déboguer la séquence de démarrage. Voir ma réponse pour Comment puis-je accéder à mon mini-pc (RaspberryPi / MK802 / Mele A1000 / VIA APC) via ethernet/wifi sans avoir Monitor ? Mais étant donné que le RaspberryPi a été conçu pour être incassable mais cet inconvénient ne doit pas vous dissuader de construire votre noyau et votre RFS personnalisés.

Concernant la "survie à la perte de puissance" : Une sélection appropriée du système de fichiers peut généralement atténuer ce problème. La couche de périphérique MTD plus un système de fichiers de journalisation (par exemple, jffs2) s'est avéré être assez robuste d'après l'expérience. Pour une protection quasi-absolue, il y a l'initramfs qui utilise ramfs (pas un disque RAM de taille fixe) sans basculement vers un système de fichiers R/W.

Addendum

Une introduction de 30 diapositives sur les caractéristiques de Buildroot est disponible. ici
A la fin (#27), il est fait mention de quelques outils similaires et alternatifs pour construire des systèmes embarqués.

TinyCoreLinux est en lecture seule par défaut (la persistance est facultative) : http://www.tinycorelinux.net/ports.html

Mes deux centimes, il est beaucoup plus facile (et plus agréable au final) de fabriquer une batterie de secours fiable pour un Pi que de vivre avec un OS en lecture seule. Bien sûr, cela signifie que vous aurez besoin de connaissances très basiques en électronique (et je veux dire BASIC ; nous parlons de 3-4 composants). Ce type en a fait une belle avec juste quelques autres : https://raspberrypi.stackexchange.com/questions/1360/how-do-i-build-a-ups-like-battery-backup-system

Si vous faites cela, n'utilisez pas de LiPo ; les NiCad sont ce que vous voulez. Les LiPo ne supportent pas la surcharge constante ; vous avez été prévenu.

De plus, vous semblez être très inquiet à propos de quelque chose qui, selon mon expérience, est un problème très mineur. J'utilise mes boîtes Linux tout le temps et un arrêt soudain non programmé est une question de cours quand je ne peux pas être ennuyé. Si vous désactivez les journaux, vous recevrez rarement des plaintes à ce sujet.

Pour désactiver tous les journaux, vous pouvez ajouter la ligne suivante comme première règle dans /etc/rsyslog.conf :

*.* ~

Même lorsqu'il y a un problème, dans 99,9999 % des cas (c'est-à-dire presque toujours d'après mon expérience personnelle), ce problème est réglé lors de la prochaine analyse du disque. Le moment où cela se produit dépend principalement du fait que le système d'exploitation a remarqué ce que vous avez fait (étrangement, il ne le fait généralement pas). Comme un Pi utilise des cartes SD, j'imagine que cela se produit encore moins sur un Pi que sur mon PC.

Si je me souviens bien, un système de fichiers en lecture seule ne sécurise pas la carte SD. J'ai 10 Pi qui fonctionnent chez un client (temps de fonctionnement actuel de plus de 80 jours pour la moitié d'entre eux) où l'alimentation n'est pas aussi stable qu'on pourrait le souhaiter. Il m'a fallu un certain temps pour trouver des alimentations (des chargeurs bon marché de 3A et des chargeurs "chers" pour iPad de 2,3A) qui pouvaient réellement faire fonctionner les Pi pendant plus de deux jours, avant cela j'avais toutes sortes de problèmes de corruption de carte SD, y compris avec une carte qui n'était utilisée qu'en lecture seule IIRC.

Mon problème est en grande partie résolu maintenant (grâce aux nouvelles fournitures), mais pour de futurs projets, j'envisage de faire un système de fichiers racine NFS. Il y a déjà beaucoup de tutoriels à ce sujet, la plupart résolvant autour des images fs normales du Pi, mais il est assez facile de faire un debootstrap minimal et de le changer en un système de fichiers racine en lecture seule sur NFS. Associez cela avec uboot pour le Pi et un uboot script intelligent, et votre carte SD ne contiendra que quelques megs de firmware RPi, d'image uboot et de uboot script.

Ayant eu un Seagate Dockstar avec accès à la console, j'ai installé Debian squeeze dessus. Comme point de départ pour le faire fonctionner en lecture seule, j'ai utilisé cet excellent article 1 par Jeff Doozan. La stratégie de base consiste à créer un script qui, à chaque démarrage, monte les répertoires nécessaires en écriture comme un tmpfs. Je cite le script de Jeff 2 ici (bravo à Jeff !)

#!/bin/bash
DIRS="/tmp /var/log /var/run /var/lock /var/tmp /var/lib/urandom /var/lib/dhcp /etc/network/run"
for DIR in $DIRS; do
  echo "Mounting $DIR as tmpfs"
  mount -n -t tmpfs tmpfs $DIR
  if [ -d "$DIR-saved" ]; then
    echo "Restoring $DIR-saved to $DIR"
    tar -C "$DIR-saved" -cf - ./ | tar -C "$DIR" -xpf -
  fi
done

echo "nameserver 4.2.2.1" > /var/tmp/resolv.conf
touch /var/lib/dhcp/dhcpd.leases

exec /sbin/init

Sauvegarder les lignes ci-dessus comme un script appelé /sbin/init-ro sur votre rootfs cible et le rendre exécutable.

chmod 755 /sbin/init-ro

Afin d'utiliser ce script pendant le démarrage, vous devez préparer un peu le système rootfs (tout est cité à partir du script de Jeff). 2 (adapter $ROOT à l'emplacement réel de votre rootfs monté).

# Configure dhcp-client to write resolv.conf to /tmp instead of /etc
sed -i 's/\/etc\/resolv.conf/\/var\/tmp\/resolv.conf/' $ROOT/sbin/dhclient-script > /dev/null 2>&1
rm $ROOT/etc/resolv.conf
ln -s /var/tmp/resolv.conf $ROOT/etc/resolv.conf

# make /etc/network/run/ a symlink to /tmp/network/
rm -rf $ROOT/etc/network/run
ln -s /var/tmp/network $ROOT/etc/network/run

# Fixes from http://wiki.debian.org/ReadonlyRoot

rm $ROOT/etc/blkid.tab  > /dev/null 2>&1
ln -s /dev/null $ROOT/etc/blkid.tab

rm $ROOT/etc/mtab  > /dev/null 2>&1
ln -s /proc/mounts $ROOT/etc/mtab

rm $ROOT/etc/rcS.d/S12udev-mtab

rm -rf $ROOT/var/log/*

Après avoir préparé le rootfs comme ci-dessus, vous pouvez monter le rootfs en lecture seule dans /etc/fstab (remplacez ext2 avec le système de fichiers que vous utilisez ou utilisez simplement rootfs à la place).

/dev/root  /                 ext2  noatime,ro   0 1

Enfin, vous devez ajouter ce qui suit à vos paramètres de noyau (c'est-à-dire dans /boot/cmdline.txt sur Raspi) afin d'exécuter le script avant l'exécution proprement dite. /sbin/init . (ce qui suit n'est qu'un exemple de racine et délai d'enracinement La partie importante qui doit être annexée à la ligne dans les paramètres de l'entreprise. cmdline.txt es init=/sbin/init-ro .)

root=/dev/mmcblk0p2 rootdelay=2 init=/sbin/init-ro

Mais soyez conscient que pour tout logiciel nécessitant un accès en écriture sur le rootfs, vous devez monter les emplacements tmpfs appropriés ou écrire sur un stockage externe.