Малиновый Прог против Интернета Кирпичей, или Raspberry Pi с графикой на read-only microSD

Запуск Raspberry Pi с полной поддержкой графики на microSD, навсегда остающейся в режиме read-only после установки системы. Отсутствие какой-либо записи данных на флэш-память повышает надёжность устройства, приближая его к промышленному классу изделий. Пошаговая инструкция. Небольшой театр инженерного абсурда для развлечения аудитории.

Мне понадобилось сетевое устройство с открытым кодом и выходом HDMI, и я решил попробовать Малиновый Прог. Да, я именно так предлагаю переводить Pi: Прог. Понятное дело, даже одноплатнику нужна операционка. И вот, захожу я на официальный сайт, ожидая встретить там подробное руководство по созданию суровой, неломаемой Вещи à la turnkey box. Но народ, как ни в чём не бывало, устанавливает Ubuntu (т.е. Raspbian Jessie) прямо на microSD, размещая и swap там же. Как обычный десктоп, face palm.

Но то цветочки. Малиновые ягодки — это проекты фоторамок из МалинПрога, требующие обязательного выключения кнопкой. Иначе фоторамка после сбоя питания может не заработать, вместо картинок предлагая воспользоваться fsck. Но и это не предел, под катом читателя ждёт настоящий шедевр инженерного абсурда, найденный автором на просторах сети.

Итак, по стандартной инструкции нормальный одноплатник превращается в раздутый десктоп со средним временем жизни год-полтора, пока изношенная флэшка не сдохнет, превратив в общем-то хороший девайс в кирпич. И большинство людей, похоже, это вполне устраивает. Меня — нет.

Куда мир катится

Прежде чем открывать спойлер, оденьте защитную маску, либо заранее возьмитесь руками за голову.

Неплохой проект, который испортила одна рекомендация

Представьте себе большой телевизор и демонстратор слайд-шоу на базе RPi, но с нейтрализацией скринсейвера аппаратным (!) имитатором ёрзающей мыши. Дескать, в оконном интерфейсе Raspbian тайм-аут скринсейвера больше 720 минут не выставляется. Поэтому, дабы каждые 12 часов не шевелить мышь вручную, народ автоматизирует процесс микроконтроллером, создающим виртуальные «ползки» USB-мыши каждые 4 минуты. Я не шучу, вот реальный проект на RPi, там же ссылка на микроконтроллер ECIO28P, и прошивка взбадривателя имеется.

Ладно, не буду отрицать самостоятельной полезности аппаратного взбадривателя: это реальный лайф-хак для тех, у кого почасовая оплата идёт за сидение перед монитором. Или для поддержания в тонусе какого-нибудь особо тупого сурового промышленного терминала, из-под антивандальной брони которого торчит один разъём для мыши (для PS/2 должен подойти зелёный переходник). Да, если втиснуть раздутый десктоп в одноплатный компьютер, то в руках über-умельцев это грозное оружие, особенно с брутально торчащей из разъёма платой МК. Сразу видно: человек умеет работать руками. Но если нужен вечно включённый экран, на линуксе достаточно головы, резиденты данного ресурса прекрасно это знают. Для гостей портала я всё-таки дам инструкцию, мало ли чего.

Отключение DPMS, скринсейвера и заодно всех GUI-элементов

Для начала примем, что используется минималистичная оболочка LightDM, и отключим X-серверу DPMS в файле /etc/lightdm/lightdm.conf:

...
xserver-command=X -s 0 -dpms -nocursor
...

Флажок -nocursor убирает долой из центра экрана неподвижную стрелку курсора. А вместо нейтрализации скринсейвера можно просто закомментировать его запуск в файле ~/.config/lxsession/LXDE/autostart. Если это не помогает, можно повесить по cron(8) с интервалом 718 минут команду xscreensaver-command -deactivate (это уже стёб, дорогие читатели ;-)

Я поступил просто: принял LightDM с автовходом, но оставил в файле ~/.config/lxsession/LXDE/autostart лишь вызов feh с префиксом '@' для перезапуска в случае аварии и соотв. параметрами. Т.е. как бы обычная графика, но без lxpanel, без pcmanfm, без xscreensaver, с отключённым DPMS и скрытым курсором несуществующей мыши.

Минимальную графику очень легко получить командами apt-get и правкой файла autostart, причём в системе будет всё необходимое для жизнедеятельности стандартных приложений, включая X-сервер, менеджер окон, менеджер сеансов и менеджер дисплея с автовходом пользователя. Но пока это ещё не Вещь, а всего лишь одноплатный десктоп.

UPD
Пользователь Jaromir предлагает вообще отказаться от менеджера дисплея и использовать unclutter в тех случаях, когда мышь изредка требуется. Эта утилита скрывает курсор, если мышь находится в покое достаточно долго.
Пользователь Spider55 рекомендует вместо LightDM использовать noDM. Считаю весьма разумным, но тогда пошаговая инструкция чуть меняется.

Задача

Сферический одноплатник в вакууме — это скучно. Не для того на Малиновом Проге целая гребёнка GPIO с I2C/PWM, а также всякие CSI-DSI и сторожевой таймер. Но я в качестве практического примера использую всё-таки сетевой демонстратор с HDMI-выходом, добавив возможность нескольким пользователям по очереди «захватывать» общий экран-табло и транслировать на него свой рабочий стол, не вставая с кресла. Экран повёрнут лицом в сторону гостей, в состоянии покоя тихонечко перебирает случайным образом картинки, выложенные в сети. Если надо показать гостю продукт, один из сидящих за стойкой администраторов временно превращает табло в «зеркало» своего монитора, но потом освобождает его для другого админинистратора. В моём случае это реальный бизнес-инструмент, висящий в реальном торговом зале. Кстати, благодарю пользователя Sauron за подсказку.

Однако, глянув на размер этой публикации, я решил отложить описание прикладного решения (т.е. собственно видеомодуля) в отдельную статью. Пока позвольте сфокусироваться на изначальной задаче: заставить Raspberry Pi загружаться и работать с microSD в режиме read-only, не боясь отключения питания и не запиливая флэш-память мусором.

Теория вопроса

Даже очень серьёзная файловая система с журналом в конечном итоге не может проконтролировать процессы, происходящие внутри SD-носителя при отключении питания. Например, серьёзные SSD-накопители для использования в ЦОД имеют конденсаторы, разряда которых как раз хватает на закрытие последней транзакции записи, и даже остаётся ещё немного. А что с отключением питания в microSD? Я уверен, там конденсаторов достаточной ёмкости нет, зато есть ненулевая вероятность того, что запись страницы NAND-памяти не успеет завершиться. И потом драйвер файловой системы от прочитанного придёт в такое недоумение, что потребуется ручное вмешательство оператора. Вот вам и фоторамка с fsck.

Насколько сложно перевести microSD Raspberry Pi в режим read-only методом Микеланджело, т.е. убирая лишние службы и пакеты? Достаточно просто, если нет графики (ссылка). Но стоит пустить в систему иксы с этими их многочисленными менеджерами всего, начинается долгий и нудный поединок с непредсказуемым результатом. Это вам не иголка в стоге сена, её хотя бы магнитом можно вытянуть. Представьте, что неизвестное количество иголок спрятаны в клубке из колючей проволоки, да ещё обильно присыпаны гвоздями. Какой там поиск иголок, не убиться бы насмерть.

Лемма: для выполнения даже самой элементарной новой функции линукс-система всегда подтянет кучу ненужных зависимостей, причём даже с «лёгкой» графикой рост системной энтропии получается кратный.

Теорема: в любом конечном наборе программных пакетов всегда найдётся бесконечно малый кусок кода, который попытается записать один бесконечно бесполезный бит на файловую систему, смонтированную в read-only, чем вызовет фатальную ошибку, повалит всю систему и перечеркнёт многочасовые усилия оператора.

Решение: UnionFS

Один немец несколько лет назад придумал очень красивый способ собрать все эти иголки в корыто с помощью UnionFS и просто сжигать их в печи при каждой перезагрузке. К сожалению, оригинальный пост уже погиб вместе с хостившим его доменом, но немец точно не одинок. Благодарные читатели сохранили идею, я считаю просто необходимым опубликовать её здесь.

Суть в том, что поверх постоянной «подложки» (read-only файловой системы на microSD) при каждом включении создаётся временная «нашлёпка» в ОЗУ, поглощающая всю ненужную энтропию и «сгорающая» при выключении питания устройства. Файловая система на microSD всё время остаётся read-only, и потому риск её повреждения снижается почти до нуля, как и риск преждевременного износа флэшки. Почему не строго до нуля? Знатоки EXT4, поправьте меня, но драйвер файловой системы всё-таки что-то записывает на носитель при каждом монтировании-демонтировании файловой системы, даже если она монтируется в read-only. И noatime не поможет, нужен аппаратный ключ на microSD. Иначе как объяснить тот факт, что по /sys/block/mmcblk0/stat у меня оказалось считано 282612 секторов, а записано аж 96, и это в режиме read-only? Ладно, хоть соотношение почти 3000:1, на обычной системе оно 5:1. (виноват, соврал, но сути это не меняет)

UPD:
Пользователь gattopazzo83 указал мне на промышленную память Flash Media Kit производства известной фирмы Харлампий-Панкрат (теперь уже Эдуардович). Раз у неё 100,000 циклов записи, это точно SLC-память в формате microSD. Даже если уважаемый читатель использует файловую систему в read-only, для серьёзных проектов я настоятельно рекомендую потратиться на промышленную память, это практика крепсондо («до» по-японски означает «путь» ;-)

UPD:
В комментариях достаточно длинная дискуссия вышла у меня с пользователем doga, в результате которой я «открыл» для себя простой способ получать внутреннюю информацию об используемой SD-карточке прямо из командной строки RPi. Пользователь doga в долгу не остался и указал на пакет mmc-utils, который тоже читает внутренности SD-карточки, но готового порта для Raspbian я не увидел. Что-то помещаю в спойлер, который, видимо, будет пополняться и раздуваться.

SD-внутренности

Команда:

udevadm info -a -n /dev/mmcblk0

Можно увидеть «сырые» регистры CID и CSD, из них код изделия (name), серийный номер (serial), дату производства (date), идентификаторы производителя (hwrev, fwrev, oemid, manfid). Расшифровку можно найти на сайте www.sdcard.org в разделе загрузок «упрощённых» спецификаций (Simplified Specifications), см. Part 1 Simplified, Physical Layer Simplified Specification.
Очень интересный объект stat, структура которого описана прямо на kernel.org. Эта информация сбрасывается при перезагрузке, но по ней можно оценить среднесуточную нагрузку на чтение и запись.
Коды производителей где-то точно лежат, но я их нашёл только в исходниках lsmmc.c.
«Пробить по базе» карточку можно хотя бы в разделе RPi SD cards на сайте Embedded Linux, это просто отзывы пользователей.
Самое интересное — данных износа — пока не увидел, хотя утилиту mmc-utils собрал, но пока запустить её не удалось.

Недостатки

Какие минусы, помимо «сгорания» логов? Устройства без аппаратных часов при старте всегда считают, что на дворе 1 января 1970 года, и пребывают в этом заблуждении вплоть до подъёма сетевого стэка и доступности NTP. Поэтому на момент данной публикации целый ряд файловых объектов «нашлёпки» будут примерно на 46 лет моложе, чем им кажется. С другой стороны, несколько секунд от начала эпохи — уже не ноль.

UPD: часы реального времени
Пользователь st1373 в комментариях напомнил о наличии I2C-совместимых часов реального времени DS3231 (стоимостью примерно в полтора рулона туалетной бумаги). Есть и нехитрая инструкция на русском: Подключение RTC (часов реального времени) к Raspberry Pi.

Безопасность

Обновления безопасности накатывать на такую систему довольно неудобно. Но, опять же, взломать такую Вещь несколько сложнее, чем эксплуатировать уязвимость Adobe Flash в браузере обычного десктопа. Вредоносный код должен открыть файловую систему на запись, чтобы закрепиться в ней, иначе он «сгорит» при перезагрузке вместе с логами и мусором. Упомянутая ниже SquashFS усложняет изменения ещё больше. Однако все эти преимущества справедливы ровно до того момента, пока вся выпоняемая масса кода «замкнута» в read-only зонах, т.е. когда защищённая «подложка» не делает вызовов команд, расположенных в записываемых областях: именно это и есть (будет?) приоритетным вектором заражения в Интернете Вещей. Будьте внимательны со стартовыми скриптами, они выполняются с правами root, одно неверное движение — и это критическая уязвимость инфраструктуры домашнего очага, постоянно подключённой к Интернету.

Пошаговая инструкция

Поскольку я впервые в жизни установил Rasbian Jessie и особо не верю в долговечность microSD даже в read-only, то решил записать все шаги подробно. Вдруг понадобится повторить.

DISCLAIMER

Извините за переносы строк. Все команды запускаются с правами root, но аккуратный читатель может использовать каждый раз sudo. Честно говоря, я не понимаю, зачем каждую команду запускать через sudo, будто это защитит от чего-то. Вот скажите, когда вы в последний раз *не были* уверены, что хотите удалить данный файл в корзину? Это как выпить пять бокалов пива по пол-литра, но на дорожку ещё налейте один 0.33, пожалуйста, а то мне уже хватит… Я дам неправильный совет: если уж взялись за эти игрушки, выходите на root командой sudo bash, не занимайтесь самообманом.

1. Инициализация

Установите Raspbian Jessie Lite. Утилитой raspi-config задайте региональные настройки и пароль пользователя pi. Подключите сеть, Debian — дитя широкополосного доступа. Загрузку в графику пока не включайте.

apt-key update
apt-get update

2. Установка и удаление программ

С графикой, установка:

apt-get install --no-install-recommends tightvncserver xtightvncviewer xserver-xorg xinit lxde-core lxappearance lightdm feh xprintidle policykit-1 busybox-syslogd ntpdate watchdog unionfs-fuse

Удаление:

dpkg --purge rsyslog
apt-get remove --purge wolfram-engine triggerhappy cron anacron logrotate dphys-swapfile fake-hwclock
apt-get autoremove --purge

Пакеты tightvncserver, xtightvncviewer, xprintidle и feh понадобились мне для частной задачи, можете обойтись без них.

Если без графики, вам *не* понадобятся также: xserver-xorg xinit lxde-core lxappearance lightdm policykit-1.

3. Создание графического окружения

Теперь утилитой raspi-config можно включить автозапуск в графическом режиме с автовходом, который будет с правами пользователя pi. Чем зацикливаться на sudo, лучше поставить сильный пароль пользователю pi, и не использовать pi для автоматического входа в графический интерфейс. Вместо этого создать пользователя pu и запускать «иксы» с его правами. Причём командный интерпретатор (default shell) этого пользователя лучше либо отключить совсем (поставив /usr/sbin/nologin), либо подменить специальным скриптом типа /usr/local/bin/pu. Об этом я намерен рассказать в другой публикации, посвящённой видеотабло с удалённым управлением по SSH, ради чего и создаётся отдельная учётная запись с пониженными правами. Ещё раз благодарю Sauron et al.

adduser --home /home/pu --shell /usr/local/bin/pu --uid 990 --gecos "RPi p-u" --gid 1000 pu
mkdir -p /home/pu/.config/lxsession/LXDE
cp -p /etc/xdg/lxsession/LXDE/desktop.conf /home/pu/.config/lxsession/LXDE/desktop.conf
touch /home/pu/.config/lxsession/LXDE/autostart
chown -R pu:pi /home/pu
sed -i 's/^#\?xserver-command=.*$/xserver-command=X -s 0 -dpms -nocursor/' /etc/lightdm/lightdm.conf
sed -i 's/^#\?autologin-user=.*$/autologin-user=pu/' /etc/lightdm/lightdm.conf

Вместо двух последних команд можете открыть редактором /etc/lightdm/lightdm.conf и задать значения двух параметров, первый я уже упоминал выше, второй говорит сам за себя:

...
xserver-command=X -s 0 -dpms -nocursor
...
autologin-user=pu
...

4. Сторожевой таймер (по желанию)

У меня Raspberry Pi 3 Model B, поэтому ядерный модуль сторожевого таймера зовут так:

modprobe bcm2835_wdt
echo "bcm2835_wdt " | sudo tee -a /etc/modules

Затем добавляем следующую строку в секцию [Install] в конце файла /lib/systemd/system/watchdog.service:

[Install]
WantedBy=multi-user.target

После этого включаем службу:

systemctl enable watchdog.service

Сторожевой таймер в минимальной конфигурации должен сработать, если зависло ядро. Но есть ещё много других вариантов, например, по чрезмерной нагрузке на систему, по истечению памяти, по перегреву системы, по отсутствию сигнального файла и т.д. См. также watchdog(8) и watchdog.conf(5)

5. Параметры старта

Я отключил отображение малинового лого и swap-файл, включил быструю загрузку. Для этого добавил в /boot/cmdline.txt буквально три слова logo.nologo fastboot noswap. У меня в итоге получилось так:

logo.nologo dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait fastboot noswap

6. Запечатывание корневой файловой системы Raspberry Pi в read-only

Вот теперь мы добрались, наконец, до главного.

Ниже скрипт, который следует расположить под именем mount_unionfs где-нибудь в /usr/local/bin. Не забудьте включить биты выполнимости +x (chmod 755 или 555). Обратите внимание на суффиксы .orig и .rw, они должны совпадать с подготовкой (далее):

#!/bin/sh
DIR=$1
ROOT_MOUNT=$(awk '$2=="/" {print substr($4,1,2)}' < /etc/fstab)
if [ $ROOT_MOUNT = "rw" ]; then
	/bin/mount --bind ${DIR}.orig ${DIR}
else
	/bin/mount -t tmpfs ramdisk ${DIR}.rw
	/usr/bin/unionfs-fuse -o cow,allow_other,suid,dev,nonempty ${DIR}.rw=RW:${DIR}.orig=RO ${DIR}
fi

Из других инструкций я решил воспользоваться советом и сделать следующее:

insserv -r bootlogs
insserv -r alsa-utils

rm -rf /var/lib/dhcp/
ln -s /tmp /var/lib/dhcp

Графические приложения очень любят записывать в /home что-нибудь ненужное, поэтому в дополнение к /etc и /var я включил ещё и /home. Подготовим разделы к переключению в режим UnionFS (внимание на суффиксы .orig и .rw):

cp -al /etc /etc.orig
mv /var /var.orig
mv /home /home.orig
mkdir /etc.rw /var /var.rw /home /home.rw

Наконец, файл fstab(5)

proc            /proc           proc    defaults        0       0
/dev/mmcblk0p1  /boot           vfat    ro              0       2
/dev/mmcblk0p2  /               ext4    ro              0       1
mount_unionfs   /etc            fuse    defaults        0       0
mount_unionfs   /var            fuse    defaults        0       0
mount_unionfs   /home           fuse    defaults        0       0
none            /tmp            tmpfs   defaults        0       0

7. Аудит системы и тест

Окиньте взглядом систему, уберите за собой .bash_history, всякие лог-файлы и т.д. Учтите, что они сейчас могут находиться не там, где обычно (например, в /var.orig вместо var).

Перезагрузите систему и посмотрите, что получилось. Если была допущена ошибка, есть большие шансы, что система уйдёт в single user и просто запустит консоль root. Если файловая система цела, перемонтировать её из read-only в read-write довольно просто:

mount -o rw,remount /

Если же система загрузилась нормально в read-only и выполняет все функции, поздравляю!
Это родилась Интернет-Вещь.

8. Распечатывание файловой системы

Если нужно распечатать систему, сперва верните коневую систему в состояние read-write (см. выше). Затем закомментируйте в fstab(5) строки, начинающиеся со слова mount_unionfs, после чего *обязательно* верните на место каталог /var.orig со всем содержимым (и желательно /home.orig тоже). Если не восстановить /var, потеряете базу установленных пакетов, но ведь именно ради установки обновлений безопасности командой apt-get вы только что распечатали систему, не так ли? Перед apt-get перезагрузите систему и убедитесь в её адекватности. Как запечатывать обратно, знаете;)

Альтернативы

Уважаемых читателей, которые знают готовые промышленные образы операционных систем (с поддержкой read-only) для Raspberry Pi и других одноплатных компьютеров, приглашаю делиться в комментариях. Надеюсь, с вашей помощью я смогу информационно обогатить этот раздел и других читаталей, резидентов и гостей уважаемого портала:)

Что касается аппаратных альтернатив самому Малиновому Прогу в контексте прикладной задачи (сетевой HDMI-свисток), то я случайно наткнулся на один обзор, который, впрочем, можно обсудить отдельно. Чисто экономически Raspberry Pi весьма выгоден, это пока главное:)

Итак, поехали.

UPD: OverlayFS
Уважаемый ValdikSS упомянул проект OverlayFS, который вошёл в ядро Linux в 2014г, уже после оригинального немецкого поста, а также initramfs. А спустя некоторое время art_gl прислал ссылку на пошаговую инструкцию: Raspbian with Read-only Root.
Кстати, проект Domoticz, у которого есть и готовый образ для Малинового Прога, может использовать OverlayFS. И заодно ещё раз поблагодарю Sauron за комментарий про Domoticz.

UPD: SquashFS
Пользователи Vooon, Vcoderlab, av_in et al справедливо упомянули в комментариях SquashFS. И даже википедия отмечает, что данная система удачно ложится «под» union mount, также аккумулируя энтропию записи исключительно в ОЗУ для последующего уничтожения. Однако не стоит забывать, что SquashFS by-design всегда остаётся read-only, т.е. речь идёт скорее о серийном изготовлении firmware-прошивки, с соответствующим (длинным) циклом тестирования, но это не главное. Обновление критических уязвимостей, особенно на раздутых системах, очень сильно удорожает подобные проекты. И не только я считаю, что именно критические уязвимости в IoT будут определять ландшафт информационной безопасности в ближайшие лет десять. Нет ничего невозможного, но даже если уважаемый читатель настолько подкован, что может изготовить стабильный образ системы на SquashFS, стоит ли он двух-трёх Малиновых Прогов? Впрочем, это всего лишь вопрос времени, и мы с вами скоро увидим больше удачных community-проектов для Интернета Вещей на базе SquashFS, в т.ч. и для Raspberry Pi. Например, OpenELEC.

UPD: F2FS
Пользователь nlykl упомянул F2FS aka «Flash-Friendly File System», и на тему МалинПрога есть даже HOWTO: Replace the micro SD card's ext4 root partition by f2fs on the Raspberry PI. DISCLAIMER: мною не проверялось. См. также обзор F2FS в одном онлайн-журнале.

UPD: Загрузка по сети
Пользователь ilmarin77 указал на официальную возможность загружать Прог по сети: Network booting. Появляется зависимость от сервера. Пожалуй, интересно для группы устройств, например, та же система видеотабло на объекте, либо (не очень критичная к отказам) система распределённых датчиков. Диапазон работы проводного модуля USB-Ethernet LAN9514 составляет 0..70°C

UPD: Загрузка с USB-накопителя
Снова ilmarin77 указал на загрузку с USB: How to boot from a USB Mass Storage Device on a Raspberry Pi 3. Если загружаться и работать с SSD, подключённого по USB, это будет надёжнее, чем microSD, но со скоростью USB 2.0 (где-то 30-40Мбайт/с, да ещё и в полудуплексе). Мне такая идея не очень нравится, потому что превращает устройство в медленный десктоп. Возможно, лучше загружаться с read-only microSD, но логи и СУБД держать на SSD повышенной надёжности и небольшой ёмкости, чтобы не стоило как деталь самолёта. USB-флэшка потенциально обладает теми же проблемами, что и microSD, и принципиально ничего не меняет.

UPD: Сторожевой таймер (watchdog)
Пользователь homecreate указал на более простой способ включения сторожевого таймера через systemd, правда, с некоторыми ограничениями. См. также комментарий.

UPD:

Находится ли моя система в зоне риска?

Именно этот вопрос и задаёт себе рациональный читатель. К сожалению, индустрия флэш-памяти для Интернета Вещей только начинает вырабатывать аппаратные механизмы, аналогичные S.M.A.R.T для HDD и SSD. SanDisk, кстати, уже пошёл по этому пути, встроив метрики износа в структуры EXTCSD. И когда нужные стандарты более-менее устаканятся, появится поддержка в ядре Linux и утилиты командной строки. А там, глядишь, и аналог smartd(8) для встраиваемых систем появится.

Но получить ответ на вопрос «сколько моя Linux-система записывает на SD-карточку в сутки/неделю» можно уже сейчас, нужно только продержать систему включённой достаточно долго, чтобы статистика получилась точнее (т.е. желателен uptime порядка месяца, или хотя бы 10 дней). Итак, заходим в систему и делаем две команды (без sudo и root):

uptime
cat /sys/block/mmcblk0/stat | awk '{printf "Uptime read: %.3fMiB (%.1f%% I/Os merged) written: %.3f MiB (%.1f%% I/Os merged)\n", $3*512/1048576, $2/$1*100, $7*512/1048576, $6/$5*100}'

Первая в комментариях не нуждается, а вторая напишет объёмы считанных и записанных данных с момента старта системы, в мегабайтах, а также «кучность» запросов. Например, пользователь Meklon в комментариях весьма любезно поделился цифрами медиа-центра, работающего на базе openELEC / KODI. Примерно за 6 дней система считала порядка 72Мб и записала менее 66Мб. Примечательно соотношение чтение/запись близкое к 1:1, что я связываю с использованием SquashFS (она распаковывает файловую систему в ОЗУ и потому SD-карточку почти не трогает даже на чтение). Классические же системы имеют показатель чтение/запись от 5:1 до 10:1, но он может сильно варьироваться. Однако главное в том, что 10Мб в сутки — это существенно меньше автомобильного регистратора, система с такими параметрами весьма долговечна.
Но помимо статистического подвоха, в такой методике есть ещё один чисто технологический изъян: запись на флэшку производится не блоками по 512 байт, а страницами неизвестного размера, либо даже целыми erase-блоками мегабайтных размеров. В докладе Optimizations for Cheap Flash Media автора Arnd Bergmann (ссылка, англ.) сказано довольно много интересного по поводу внутренней «кухни» флэшек, в т.ч. упомянут размер страницы 32КБайт, размер erase-блока 4..8МБайт. И если принять самый неудачный сценарий «кучности» записи, то каждый блок 512 байт вынудит записать одну страницу целый erase-блок, т.е. объём фактически записанных данных получится в 64 раза тысячекратно больше, чем говорит stat. Пользователи в комментариях описывали систему с интенсивностью записи порядка 6ГБайт/мес, которая изнашивает microSD-карточку всего за несколько месяцев.
Как только автор наберёт достаточно материала, будет продолжение в отдельной публикации.

Ссылки

Make Raspbian System Read-Only
blog.pi3g.com/2014/04/make-raspbian-system-read-only
(источник)

How to make RaspberryPi truly read-only, reliable and trouble-free
k3a.me/how-to-make-raspberrypi-truly-read-only-reliable-and-trouble-free
(без графики)

Protect your Raspberry PI SD card, use Read-Only filesystem
hallard.me/raspberry-pi-read-only
(прислал sisaenkov, улучшенная версия, но тоже без графики)

Stopping SD Card Corruption on Raspberry Pi’s Raspbian
ideaheap.com/2013/07/stopping-sd-card-corruption-on-a-raspberry-pi
(без графики)

Raspberry Pi как информационное табло — с помощью VNC на localhost
habrahabr.ru/post/212661

Подключение RTC (часы реального времени) к Raspberry Pi
raspberrypi.ru/blog/598.html
(использует I2C-совместимые часы DS3231)

How to boot from a USB Mass Storage Device on a Raspberry Pi 3
www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

Network booting
www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md

ECIO(TM), a powerful USB programmable single chip computer based on PICmicro microcontroller technology
www.matrixtsl.com/product.php?Prod=ECIO28P

Easy Raspberry Pi Based Screensaver/Slideshow for Exhibitions/Store Front
www.instructables.com/id/Easy-Raspberry-Pi-Based-ScreensaverSlideshow-for-E
(у меня вызвал искреннее недоумение шаг 6)

Flash memory card design (2013)
wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
(почему флэшка накрывается гораздо раньше, чем мы ожидаем? польза и вред от оптимизации внутренней логики под FAT; классификация контрафактных продуктов; каталог флэшек 2013г)

Optimizing Linux with cheap flash drives, Arnd Bergmann, 2011
lwn.net/Articles/428584
(иллюстрированная статья)

Optimizations for Cheap Flash Media, Arnd Bergmann, 2011
free-electrons.com/blog/elce-2011-videos
(видео выступления на английском, запись любительская, но интересная)

SD Association, Simplified Specifications, Part 1 Simplified: Physical Layer Simplified Specification
www.sdcard.org/downloads/pls/index.html

Block layer statistics in /sys/block/<dev>/stat
www.kernel.org/doc/Documentation/block/stat.txt
(как оценить износ SD-карточки с момента запуска системы: запустите cat /sys/block/mmcblk0/stat и потом сразу uptime)