Potrzebuję dystrybucji Linuksa, która da mi następujące rzeczy:

• Uruchom na Raspberry Pi
• Może niezawodnie przetrwać utratę zasilania (na przykład przez system plików tylko do odczytu)

Udało mi się znaleźć trochę dokumentacji na temat zmiany zwykłej dystrybucji Linuksa na tryb tylko do odczytu. Miałem nadzieję, że będzie już zbudowana dystrybucja, która została zaprojektowana do działania w środowisku osadzonym.

Nie potrzebuję wielu pakietów ani sterowników, wystarczy, że Pi działa z USB / Ethernet. Nie potrzebuję żadnego interfejsu GUI ani nic, będzie to po prostu uruchomienie niestandardowej usługi wbudowanej w C.

Czy ktoś wie o dystrybucji, która by pasowała?

Większość systemów osadzonych używa niestandardowego jądra. Jednym z narzędzi ułatwiających to jest Buildroot , zestaw skryptów do budowy zestawu narzędzi GNU gcc, biblioteka uClibc zamiast (ogromnego) GNU libc, jądra Linux, BusyBox i innych narzędzi / pakietów dla głównego systemu plików na płycie wbudowanej. RaspberryPi jest stosunkowo nową płytą, więc wsparcie dla niego w Buildroot jest wciąż w fazie rozwoju, ale najwyraźniej istnieje projekt , inny projekt i praca indywidualna . Prawdopodobnie będzie ich więcej w miarę zwiększania produkcji RP i poprawy dystrybucji.

Korzystając z Buildroot, możesz zbudować jądro Linuksa i główny system plików dokładnie tak, jak opisano w pytaniu. W zależności od szybkości połączenia internetowego i możliwości komputera deweloperskiego pliki binarne mogą mieć od 1 do 4 godzin. Minusem jest to, że wynikowe pliki binarne nie są testowane ani gwarantowane do pomyślnego rozruchu i wykonania. Konsola systemowa jest obowiązkowa do debugowania sekwencji rozruchowej. Zobacz moją odpowiedź na temat Jak uzyskać dostęp do mojego mini-komputera (RaspberryPi / MK802 / Mele A1000 / VIA APC) za pośrednictwem sieci Ethernet / Wi-Fi bez monitora? Ale biorąc pod uwagę, że RaspberryPi został zaprojektowany tak, aby był niemożliwy do odtworzenia , ten minus nie powinien zniechęcać do budowania własnego jądra i RFS.

Odnośnie „przetrwania utraty zasilania”: Właściwy wybór systemu plików może zwykle złagodzić ten problem. Warstwa urządzenia MTD oraz system plików kronikowania (np. Jffs2) okazały się dość solidne z doświadczenia. Dla niemal absolutnej ochrony istnieje initramfs, który używa ramfs(nie ramdysku o stałej wielkości) bez przełączania na system plików R / W.

Uzupełnienie

30-slajdowe wprowadzenie na temat funkcji Buildroot jest tutaj.
Na końcu (# 27) jest mowa o kilku podobnych i alternatywnych narzędziach do budowy systemów osadzonych.

TinyCoreLinux jest domyślnie tylko do odczytu (trwałość jest opcjonalna): http://www.tinycorelinux.net/ports.html

Mając Seagate Dockstar z dostępem do konsoli, zainstalowałem na nim wyciskanie Debiana. Jako punkt wyjścia, aby uruchomić go na katalogu głównym tylko do odczytu, skorzystałem z tego doskonałego artykułu 1 autorstwa Jeffa Doozana. Podstawowa strategia polega na stworzeniu skryptu, który przy każdym uruchomieniu instaluje niezbędne zapisywalne katalogi jako tmpfs. Cytuję scenariusz Jeffa 2 tutaj (podziękowania dla Jeffa!)

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

Zapisz powyższe linie jako skrypt o nazwie / sbin / init-ro na docelowych rootfach i uczyń go wykonywalnym.

chmod 755 /sbin/init-ro

Aby użyć tego skryptu podczas rozruchu, musisz nieco przygotować systemowe rootfy (wszystkie cytowane ze skryptu Jeffa 2 (dostosuj $ROOTdo rzeczywistej lokalizacji zamontowanych rootfów).

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

Po przygotowaniu rootfów jak wyżej, możesz zamontować rootfy tylko do odczytu w / etc / fstab (zamień ext2 na używany system plików lub po prostu użyj rootfs ).

/dev/root  /                 ext2  noatime,ro   0 1

Na koniec musisz dołączyć następujące parametry do parametrów jądra (tj. W /boot/cmdline.txt na Raspi), aby uruchomić skrypt przed aktualnym / sbin / init . (poniżej jest tylko przykład parametrów root i rootdelay . Ważną częścią, którą należy dołączyć do wiersza w cmdline.txt jest init=/sbin/init-ro.)

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

Należy jednak pamiętać, że w przypadku każdego oprogramowania wymagającego dostępu do zapisu w rootfach należy zamontować odpowiednie lokalizacje tmpfs lub zapisać w pamięci zewnętrznej.

Moje 2 centy, o wiele łatwiej (i ładniej w końcu) zrobić niezawodne podtrzymanie bateryjne dla Pi niż żyć z systemem operacyjnym tylko do odczytu. Oczywiście oznaczałoby to, że będziesz potrzebować bardzo podstawowej wiedzy na temat elektroniki (i mam na myśli BASIC; mówimy o 3-4 elementach). Ten facet zrobił fantazyjnego z kilkoma dodatkowymi: /raspberrypi/1360/how-do-i-build-a-ups-like-battery-backup-system

Jeśli to zrobisz, NIE używaj LiPo; NiCad są tym, czego chcesz. LiPo nie może przejmować stałego ładowania; Zostałeś ostrzeżony.

Ponadto wydaje się, że bardzo martwisz się o coś, co z mojego doświadczenia jest bardzo drobną kwestią. Cały czas wyrzucam swoje Linux-a, a nagłe nieplanowane zamknięcie jest sprawą oczywistą, kiedy nie mogę się martwić. Jeśli wyłączysz dzienniki, wtedy rzadko będziesz otrzymywać skargi.

Aby wyłączyć wszystkie dzienniki, możesz dodać następujący wiersz jako pierwszą regułę w /etc/rsyslog.conf:

*.* ~

Nawet gdy pojawia się problem, 99,9999% czasu (przez to mam na myśli prawie za każdym razem w moim osobistym doświadczeniu) ten problem jest rozwiązywany przy następnym skanowaniu dysku. Kiedy tak się dzieje, zależy głównie od pogody, system operacyjny zauważył to, co zrobiłeś (o dziwo, zwykle tak nie jest). Ponieważ Pi używa kart SD, wyobrażam sobie, że dzieje się to jeszcze mniej na Pi niż na moim komputerze.

Jeśli dobrze pamiętam, system plików tylko do odczytu nie „zabezpieczy” karty SD. Mam 10 Pi pracujących u klienta (bieżący czas pracy ponad 80 dni dla połowy z nich), gdzie moc nie jest tak stabilna, jak można by oczekiwać / chcieć. Zajęło mi trochę czasu, aby znaleźć zasilacze (tanie ładowarki o wartości 3A i „drogie” ładowarki do iPada o wartości 2,3A), które mogłyby faktycznie utrzymywać działanie Pi przez więcej niż kilka dni, zanim miałem różne problemy z uszkodzeniem SD , w tym z takim, który był używany tylko do odczytu IIRC.

Mój problem został w większości rozwiązany teraz (z powodu nowych materiałów eksploatacyjnych), ale w przyszłych projektach zamierzam stworzyć system plików root NFS. Jest już wiele samouczków na ten temat, głównie dotyczących normalnych obrazów Pi fs, ale dość łatwo jest wykonać minimalny pasek debootstrap i zmienić go na system plików root tylko do odczytu przez NFS. Połącz to z funkcją Uboot dla Pi i inteligentnego skryptu Uboot, a Twoja karta SD będzie zawierać tylko kilka megabajtów oprogramowania układowego RPi, obrazu Uboot i skryptu Uboot.

Słyszałem o tym dobre rzeczy o Puppy Linux . Chociaż muszę przyznać, że tego nie próbowałem.

Można ustawić, aby nie zapisywać z powrotem na karcie SD.

Na stronie pobierania raspberrypi.org dostępne są cztery obrazy :

• Debian „wheezy”
• Debian soft-float „wheezy”
• Arch Linux ARM
• QtonPi

A oto jedyny, który jest domyślnie tylko do odczytu (ale można go zmienić w razie potrzeby):

• TinyCoreLinux

Mam nadzieję, że jeden z nich spełni twoje potrzeby.