Является ли использование корневой файловой системы только для чтения хорошей идеей для встроенной установки?

Мне было поручено запустить Linux в качестве операционной системы на встроенном устройстве.

Цель имеет процессор x86 и 8 ГБ устройство CompactFlash для хранения.

Мне удалось использовать buildroot для создания образа ядра и инструментов кросс-компиляции. Я разделил устройство CF на небольшой раздел FAT, где находится образ ядра, а также syslinuxзагрузочную конфигурацию и ext3файловую систему, в которой я распаковал корневую файловую систему, созданную buildroot.

Система успешно загружается с syslinuxпомощью установки корневого каталога на раздел CF ext3, где находится моя файловая система buildroot.

Мой вопрос связан с необходимостью обеспечения надежности в условиях немедленной (и частой) потери питания, поскольку крайне важно, чтобы устройство успешно загружалось после перебоев в подаче электроэнергии. Я прочитал, что монтирование корневой файловой системы только для чтения является способом обеспечения целостности данных. Это разумный путь для меня?

Я также читал о возможности загрузки корневой файловой системы в ОЗУ для достижения того же результата, но пока не знаю, как это сделать.

Есть ли предпочтительный способ достижения этой цели, и если да, то как мне лучше поступить?

Новый ответ (2015-03-22)

( Примечание: этот ответ проще, чем предыдущий, но не более безопасен. Мой первый ответ сильнее, потому что вы можете оставить файлы доступными только для чтения с помощью параметров монтирования fs до флагов разрешений. Поэтому принудительное написание файлов без разрешения на запись не будет работать совсем.)

Да, под Debian есть пакет: fsprotect ( домашняя страница ).

Он использует aufs(по умолчанию, но может использовать другой unionfsинструмент), чтобы разрешить изменения сеанса в реальном времени, но в ОЗУ по умолчанию, поэтому при перезагрузке все забывается

Вы можете установить их, просто запустив:

apt-get install fsprotect

После того, как сделано, из онлайн-документа:

После того:

• Отредактируйте /boot/grub/menu.lstили /etc/default/grub2или /etc/lilo.confи добавьте " fsprotect=1G" к параметрам ядра.
• Измените 1G по мере необходимости.
• Применить изменения (т.е. запустить update-grub)
• Изменить, /etc/default/fsprotectесли вы хотите защитить файловые системы, кроме /.
• перезагрузка

Вы также можете защитить паролем загрузчик grub или запретить любые изменения в нем.

Оттуда, если какой-либо файл защищен от изменений, например,

chmod ugo-w myfile

если вы используете для образца vi myfileи пытаться писать на нем с помощью команды :w!, это будет работать и ваш myfileстал изменен. Вы можете перезагрузиться, чтобы получить неизмененные myfile.

Это даже невозможно с моим следующим первым решением:

Старый (первый) ответ:

Да, это сильное решение, но мощное!

Сделать р / о пригодным для использования

Вы должны установить некоторые каталоги в рве , как /var, /etcи возможно /home. Это можно сделать с помощью aufs или unionfs . Мне нравится это по- другому , используя /dev/shmи mount --bind:

cp -a /var /dev/shm/
mount --bind /dev/shm/var /var

Раньше вы могли бы переместить все каталоги, которые не должны изменяться в обычной работе, в a static-var, чем создать символические ссылки в / var:

mkdir /static-var
mkdir /static-var/cache
mkdir /static-var/lib
mv /var/lib/dpkg /static-var/lib/dpkg
ln -s /static-var/lib/dpkg /var/lib/dpkg
mv /var/cache/apt /static-var/cache/apt
ln -s /static-var/cache/apt /var/cache/apt
... # an so on

Таким образом, при повторном монтировании в ro копирование /varв /dev/shmне займет слишком много места, так как большинство файлов перемещается, /static-varа в ram нужно копировать только символические ссылки.

Лучший способ сделать это точно - это сделать полный цикл питания, один день полной работы и точно запустить команду вроде:

find / -type f -o -type f -mtime -1

Таким образом, вы увидите, какие файлы должны быть расположены в разделе для чтения и записи.

логирование

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

echo >/etc/syslog.conf '*.* @mySyslogServer.localdomain'

Таким образом, если ваша система сломалась по какой-либо причине, все до этого регистрируется.

модернизация

При работе с некоторыми из них mount --bind, для выполнения такого обновления во время использования системы (без необходимости запуска init 1, для сокращения времени простоя), более простой способ состоит в том, чтобы восстановить чистый корень , способный выполнить обновление:

После перемонтирования '/' в режиме чтения-записи :

mount -o remount,rw /

for mpnt in /{,proc,sys,dev{,/pts}};do
    mount --bind $mnpt /$mnt$mpnt;
    done

chroot /mnt

apt-get update && apt-get dist-upgrade

exit

umount /mnt/{dev{/pts,},proc,sys,}

sync
mount -o remount,ro /

И сейчас:

shutdown -r now

У меня есть только опыт использования более свежего buildroot (2014-02). В этой версии вы можете отключить «перемонтировать корневую файловую систему для чтения-записи при загрузке» в файле конфигурации с помощью:

BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW не установлен

Мне удалось создать образ, который использует раздел ext4 / только для чтения, поэтому отключение питания системы не повредит. Он прекрасно работает, поэтому, если вам не нужно записывать в вашу файловую систему, возможно, это гораздо более простое решение, чем упомянутое выше (которое кажется более или менее применимым к системе Debian, так как относится к apt-get).