Eu preciso de uma distribuição Linux que me dê o seguinte:

• Executar em um Raspberry Pi
• Pode sobreviver com segurança à perda de energia (como através de um sistema de arquivos somente leitura)

Eu pude procurar alguma documentação sobre como alterar uma distribuição normal do Linux para o modo somente leitura. Eu esperava que já houvesse uma distribuição criada para ser executada em um ambiente incorporado.

Não preciso de muitos pacotes ou drivers, apenas o suficiente para que o Pi funcione com USB / Ethernet. Eu não preciso de nenhuma interface GUI nem nada, isso apenas estará executando um serviço personalizado construído em C.

Alguém sabe de uma distribuição que seria adequada?

A maioria dos sistemas embarcados usa um kernel personalizado. Uma ferramenta para facilitar isso é o Buildroot , um conjunto de scripts para criar a cadeia de ferramentas GNU gcc, a biblioteca uClibc no lugar da (enorme) GNU libc, o kernel do Linux, o BusyBox e outros utilitários / pacotes para o sistema de arquivos raiz de uma placa incorporada. O RaspberryPi é um conselho relativamente novo, portanto o suporte no Buildroot ainda está em desenvolvimento, mas aparentemente há um projeto , outro projeto e o trabalho de um indivíduo . Provavelmente haverá mais à medida que a fabricação de RP aumenta e a distribuição melhora.

Usando o Buildroot, você pode criar um kernel Linux e um sistema de arquivos raiz exatamente como descrito em sua pergunta. Dependendo da velocidade da sua conexão com a Internet e dos recursos do seu PC de desenvolvimento, você poderá ter os binários em 1 a 4 horas ou mais. A desvantagem é que os binários resultantes não são testados nem garantidos para inicializar e executar com êxito. Um console do sistema é obrigatório para depurar a sequência de inicialização. Consulte minha resposta para Como acessar meu mini-PC (RaspberryPi / MK802 / Mele A1000 / VIA APC) via Ethernet / wifi sem ter o Monitor? Mas, como o RaspberryPi foi projetado para ser intransferível , essa desvantagem não deve ser um impedimento para a construção de seu kernel personalizado e RFS.

Em relação a "sobreviver à perda de energia": a seleção adequada do sistema de arquivos geralmente pode aliviar essa preocupação. A camada do dispositivo MTD mais um sistema de arquivos de registro no diário (por exemplo, jffs2) demonstrou ser bastante robusto por experiência. Para proteção quase absoluta, há o initramfs que usa ramfs(não um ramdisk de tamanho fixo) sem alternar para um sistema de arquivos R / W.

Termo aditivo

Uma introdução de 30 slides sobre os recursos do Buildroot está aqui
No final (# 27), há uma menção de algumas ferramentas alternativas e similares para construir sistemas incorporados.

O TinyCoreLinux é somente leitura por padrão (persistência é opcional): http://www.tinycorelinux.net/ports.html

Tendo um Seagate Dockstar com acesso ao console, instalei o Debian squeeze nele. Como ponto de partida para rodar na raiz somente leitura, usei este excelente artigo 1 de Jeff Doozan. A estratégia básica envolve a criação de um script que, a cada inicialização, monta os diretórios graváveis ​​necessários como um tmpfs. Cito o script de Jeff 2 aqui (parabéns a 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

Salve as linhas acima como um script chamado / sbin / init-ro no seu rootfs de destino e torne-o executável.

chmod 755 /sbin/init-ro

Para usar esse script durante o tempo de inicialização, você precisa preparar um pouco os rootfs do sistema (todos citados no script 2 de Jeff (adaptar $ROOT- se à localização real dos rootfs montados).

# 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/*

Depois de preparar o rootfs como acima, você pode montar o rootfs somente leitura em / etc / fstab (substitua ext2 pelo sistema de arquivos que você está usando ou apenas use o rootfs ).

/dev/root  /                 ext2  noatime,ro   0 1

Finalmente, você deve anexar o seguinte aos parâmetros do seu kernel (ou seja, em /boot/cmdline.txt no Raspi ) para executar o script antes do / sbin / init real . (a seguir é apenas um exemplo de raiz e parâmetros rootdelay . a parte importante que deve ser anexada à linha em cmdline.txt é init=/sbin/init-ro.)

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

Mas esteja ciente de que, para qualquer software que exija acesso de gravação no rootfs, é necessário montar os locais tmpfs apropriados ou gravar no armazenamento externo.

Meus 2 centavos, é muito mais fácil (e melhor no final) fazer um backup de bateria confiável para um Pi do que viver com um sistema operacional somente leitura. Claro, isso significa que você precisará de algum conhecimento básico de eletrônica (e eu quero dizer BASIC; estamos falando de 3-4 componentes). Esse cara fez um chique com apenas mais alguns: /raspberrypi/1360/how-do-i-build-a-ups-like-battery-backup-system

Se você fizer isso, NÃO use LiPo; NiCad é o que você deseja. O LiPo não pode demorar a cobrar constantemente; voce foi avisado.

Além disso, você parece estar muito preocupado com algo que, na minha experiência, é um problema muito menor. Eu brinco com minhas caixas do Linux o tempo todo e um desligamento repentino e não programado é uma questão natural quando não posso ser incomodado. Se você desativar os logs, raramente receberá reclamações sobre isso.

Para desativar todos os logs, você pode adicionar a seguinte linha como a primeira regra no /etc/rsyslog.conf:

*.* ~

Mesmo quando há um problema, 99,9999% do tempo (com isso quero dizer quase todas as vezes na minha experiência pessoal), esse problema é resolvido na próxima verificação do disco. Quando isso acontece principalmente depende do clima, o sistema operacional notou o que você fez (por incrível que pareça, geralmente não). Como um Pi usa cartões SD, eu imaginaria que isso acontece ainda menos em um Pi do que no meu PC.

Se bem me lembro, um sistema de arquivos somente leitura não 'protegerá' o cartão SD. Tenho 10 Pi's em execução em um cliente (tempo de atividade atual de mais de 80 dias para metade deles) em que a energia não é tão estável quanto você esperaria / desejaria. Levei um tempo para encontrar fontes de alimentação (carregadores baratos classificados como 3A e carregadores 'caros' classificados como 2,3A) que poderiam manter o Pi funcionando por mais de alguns dias, antes que eu tivesse todos os tipos de problemas de corrupção de SD , inclusive com um que foi usado apenas IIRC somente leitura.

Meu problema está praticamente resolvido agora (por causa dos novos suprimentos), mas para projetos futuros, estou pensando em criar um sistema de arquivos raiz NFS. Já existem muitos tutoriais sobre isso, principalmente em torno das imagens Pi fs normais, mas é bastante fácil executar um desbootstrap mínimo e alterá-lo para um sistema de arquivos raiz somente leitura por NFS. Associe isso ao uboot para o Pi e um script uboot inteligente, e o seu cartão SD conterá apenas alguns megas de firmware RPi, imagem uboot e script uboot.

Eu ouvi coisas boas sobre o Puppy Linux para isso. Embora eu deva admitir que não tentei.

Pode ser configurado para não gravar de volta no cartão SD.

Existem quatro imagens disponíveis na página de download do raspberrypi.org :

• Debian "chiado"
• Debian de flutuação suave "chiado"
• Arch Linux ARM
• QtonPi

E aqui está o único que é lido somente por padrão (mas que pode ser alterado se necessário):

• TinyCoreLinux

Felizmente, um deles atenderá às suas necessidades.