Мені потрібен дистрибутив Linux, який дасть мені наступне:

• Бігайте на малиновому пі
• Може надійно пережити втрати електроенергії (наприклад, через файлову систему лише для читання)

Мені вдалося знайти деяку документацію про те, як змінити звичайний дистрибутив Linux на режим лише для читання. Я сподівався, що вже буде побудований дистрибутив, який був розроблений для роботи у вбудованому середовищі.

Мені не потрібно багато пакетів або драйверів, достатньо, щоб Pi працював з USB / Ethernet. Мені не потрібен інтерфейс GUI або що-небудь, це буде просто запущена спеціальна служба, вбудована в C.

Хтось знає про дистрибутив, який би підходив?

Більшість вбудованих систем використовують спеціально створене ядро. Одним із засобів для полегшення цього є Buildroot - набір скриптів для побудови інструментальної мережі GNU gcc, бібліотеки uClibc замість (величезного) libc GNU, ядра Linux, BusyBox та інших утиліт / пакетів для кореневої файлової системи вбудованої дошки. RaspberryPi - це відносно нова рада, тому підтримка її у Buildroot ще розробляється, але, мабуть, є проект , інший проект та робота особистості . Напевно, буде більше, оскільки виробництво RP наростає і дистрибуція покращується.

Використовуючи Buildroot, ви могли б скласти ядро ​​та кореневу файлову систему Linux точно так, як ви описали у своєму запитанні. Залежно від швидкості підключення до Інтернету та можливостей вашого ПК для розвитку, ви можете мати двійкові файли протягом 1–4 годин. Мінусом є те, що отримані бінарні файли не перевіряються і не гарантуються для успішного завантаження та виконання. Для налагодження послідовності завантаження системна консоль є обов'язковою. Дивіться мою відповідь на тему: Як я можу отримати доступ до свого міні-ПК (RaspberryPi / MK802 / Mele A1000 / VIA APC) через Ethernet / Wi-Fi, не маючи Монітора? Але зважаючи на те, що RaspberryPi був розроблений як нерозбірливий , цей недолік не повинен бути стримуючим фактором для побудови вашого власного ядра та RFS.

Щодо "пережити втрати потужності": Правильний вибір файлової системи зазвичай може полегшити цю проблему. Шлях пристрою MTD плюс файлова система журналу (наприклад, jffs2) показали досить надійний досвід. Для забезпечення майже абсолютного захисту є initramfs, який використовує ramfs(а не рамковий диск фіксованого розміру) без переходу на файлову систему R / W.

Додаток

30-слайд - інтро на особливостях Buildroot знаходиться тут
в кінці (# 27) є згадка про декілька подібних і альтернативних інструментах для створення вбудованих систем.

TinyCoreLinux читається лише за замовчуванням (збереження необов’язково): http://www.tinycorelinux.net/ports.html

Маючи Dockstar Seagate з доступом до консолі, я встановив Debian стиснення на нього. В якості вихідної точки, щоб змусити її працювати на корені лише для читання, я використав цю чудову статтю 1 Джеффа Дузана. Основна стратегія передбачає створення сценарію, який під час кожного завантаження монтує необхідні для запису каталоги як tmpfs. Я цитую тут сценарій Джеффа 2 (кудо Джеффу!)

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

Збережіть рядки вище у вигляді скрипту під назвою / sbin / init-ro на своїх цільових коренях та зробіть його виконуваним.

chmod 755 /sbin/init-ro

Для того, щоб використовувати цей скрипт під час завантаження, вам слід трохи підготувати системні корені (усі вони цитуються з сценарію Jeff 2) (адаптувати $ROOTдо фактичного місця розташування встановлених вами руфів).

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

Після того, як руфи підготуються, як описано вище, ви можете змонтувати rootfs тільки для читання в / etc / fstab (замініть ext2 файловою системою, яку ви використовуєте, або просто замість цього використовуйте rootfs ).

/dev/root  /                 ext2  noatime,ro   0 1

Нарешті, вам слід додати наступне до параметрів ядра (тобто в /boot/cmdline.txt на Raspi), щоб запустити скрипт перед фактичним / sbin / init . (Нижче наведено лише приклад кореневих і rootdelay параметрів. Важлива частина , яка повинна бути додана до лінії в cmdline.txt є init=/sbin/init-ro.)

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

Але майте на увазі, що для будь-якого програмного забезпечення, що вимагає доступу для запису на rootfs, вам потрібно встановити відповідні місця tmpfs або записати у зовнішнє сховище.

Мої 2 копійки, набагато простіше (і в кінцевому підсумку) зробити надійніші резервні копії акумулятора для Pi, ніж жити з ОС, що лише читається. Звичайно, це означає, що вам знадобляться дуже базові знання електронної (і я маю на увазі БАЗОВЕ; ми говоримо про 3-4 компоненти). Цей хлопець зробив фантазію лише кількома ще: /raspberrypi/1360/how-do-i-build-a-ups-like-battery-backup-system

Якщо ви це зробите, НЕ використовуйте LiPo; NiCad - те, чого ти хочеш. LiPo не може приймати постійну перезарядку; вас попередили

Крім того, ви, здається, дуже переживаєте за щось, що, на мій досвід, є дуже другорядним питанням. Я постійно розбиваю свої скриньки Linux, і раптове позапланове відключення - це питання, звичайно, коли мене не можна турбувати. Якщо ви відключите журнали, ви рідко навіть отримуватимете скарги на це.

Щоб вимкнути всі журнали, ви можете додати наступний рядок як перше правило в /etc/rsyslog.conf:

*.* ~

Навіть коли виникає проблема, у 99,9999% часу (під цим я маю на увазі майже кожен раз, коли я переживаю особисто), ця проблема вирішується при наступному скануванні диска. Коли це відбувається головним чином, залежить від погоди, ОС помітила, що ви зробили (як не дивно, зазвичай це не так). Оскільки Pi використовує SD-карти, я думаю, що на Pi це відбувається навіть менше, ніж на моєму ПК.

Якщо я правильно пам’ятаю, файлова система лише для читання не захистить SD-карту. У мене 10 Pi працює на клієнта (поточний час роботи понад 80 днів для половини з них), де потужність не така стабільна, як ви очікували / хочете. Мені потрібен час, щоб знайти джерела живлення (дешеві зарядні пристрої з оцінкою 3A та «дорогі» iPad-зарядні пристрої, оцінені в 2.3A), які насправді могли би продовжувати роботу Pi більше двох днів, до цього у мене виникли всі види корупційних проблем SD , у тому числі з одним, який використовувався лише IIRC, доступний лише для читання.

Моє питання в основному вирішується зараз (через нові поставки), але для майбутніх проектів я розглядаю роботу з кореневою файловою системою NFS. Про це вже існує багато підручників, які в основному вирішуються навколо звичайних зображень Pi fs, але зробити мінімальну деботстрап і змінити її в кореневу файлову систему через NFS досить просто. З'єднайте це з uboot для Pi та смарт-скриптом uboot, і ваша SD-карта буде містити лише кілька меґів варті прошивки RPi, зображення uboot та скрипт uboot.

Я чув для цього гарні речі про Puppy Linux . Хоча мушу визнати, що я цього не пробував.

Це може бути встановлено, щоб не записувати назад на SD-карту.

На сторінці завантаження raspberrypi.org доступні чотири зображення :

• Debian "хрипкий"
• Soft-float Debian "хрипкий"
• Arch Linux ARM
• QtonPi

І ось єдиний, який читається лише за замовчуванням (але його можна змінити за потреби):

• TinyCoreLinux

Сподіваємось, одна з них задовольнить ваші потреби.