caxapa.ru :: Сделали. Люди пользуются. Но есть ощущение что и без него все в порядке, изучаю вопрос. На самом деле бессмысленно бороться за totaly readonly (как и за любой другой абсолют, к слову). Нахуя такая схизма?! А обновления накатить?Потихоньку обложил "железку" измерялками и, в общем, никакой особой драмы не наблюдаю.

Cкpипaч^пророк (11.06.2020 19:55, просмотров: 707) ответил fk0 на А в паделке финских студентов уже сделали overlay для файловых систем? Чтоб поверх ro rootfs был rw overlay, который куда-то там писался отдельно. И потом просто посмотреть, что туда написалось и сделать выводы. Вроде да, сам никогда не пользовался:

Сделали. Люди пользуются. Но есть ощущение что и без него все в порядке, изучаю вопрос. На самом деле бессмысленно бороться за totaly readonly (как и за любой другой абсолют, к слову). Нахуя такая схизма?! А обновления накатить?Потихоньку обложил "железку" измерялками и, в общем, никакой особой драмы не наблюдаю.

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

Но нет уверенности что я точно-точно никак "не вносил погрешность в измерения".

Потенциально, выглядит обнадеживающе.

Добавлю себе в код awk '{print $5}' /sys/block/mmcblk0/stat

Для контроля в полевых условиях. С сигнализацией если "а чего оно вдруг расти начало?!".

... но не любой ценой.

Ответить

- overlayfs удобна тем, что при тотальном крэше rw файлухи "от неизбежных в ~~море~~ поле случайностей" ты остаешься с исходной ro rootfs, а не с кирпичем. Обновления на ядро/rootfs накатываются путем замены собственно ядра/rootfs. Обновления всего остального - обычным порядком. - LightElf(11.06.2020 20:49)
  - Есть и другой путь. Делаем не readonly, а контроль ресурса. ~~Освободившуюся RAM используем для хранения фото котиков.~~ Достаточно несложно просигналить на базу за полгода до "окирпичивания". ~~Выезд на замену - платный.~~ Cкpипaч^пророк(127 знак., 11.06.2020 21:00)
    - Систему нужно обновлять целиком, а не по частям. Иначе потом никто не разберется в этом конструкторе, у кого, что и какой версии стоит. А так прочитал /etc/version и сразу понял, что за хрень у клиента установлена, и что, ее, млин, надо было еще год назад обновить - lloyd(11.06.2020 21:30)
      - Слово "нужно" слишком сильно похоже на слово "должен". У меня, наоборот, у клиента на шлюзе скорее всего, кроме прочего, крутятся десятки прикладных скриптов. Узко-специально-клиентских. Естественно они обновляются раздельно-асинхронно. - Cкpипaч^пророк(11.06.2020 21:34)
    - В идеальном мире, где софт не содержат ошибок, а микросхемы работают строго по спецификации - оно конечно. А в реальном мире хорошо бы сохранить доступ к платке в Дальних Пердях. Чтобы зайти по SSH, отформатить флешку и заново залить свежи софты. - LightElf(11.06.2020 21:15)
      - Стоп! Вы действительно умеете форматировать флешку, на которой лежит и /boot, и /root одновременно? (и вообще другой любой памяти, кроме еще оперативки, в системе нет?) Cкpипaч^пророк(129 знак., 11.06.2020 21:27)
        
        Мы, кажется говорили об overlayfs? На флешке два раздела: FAT и EXT3. Загрузчик подбирает с FAT-раздела ядро с вкомпиленной маленькой ramfs и запущает его. Инитскрипт чекает раздел EXT3 и если он годен - монтирует поверх своего rootfs, после чего все работает оттуда с обновленным софтом и прочим блекджеком. При этом FAT-раздел вообще не смонтирован и никто туда ничего не пишет. Если раздел EXT3 покоцан - то ничего не монтирует, дает зеленый свисток в зенит и ждет LightElf(271 знак., 11.06.2020 21:46)
        
        root кладётся в initrd в котором squashfs. Т.е. с флешки только загрузчик однажды скопирует содержимое в ОЗУ и запустит. Потом до следующего ребута флешка не нужна вообще. Я такое видел. Можно как раз обновлением всё переписать в процессе работы. Хуже, если в процессе обновления сбой, ребут, питание кончится. Но там загрузчик в отдельном разделе сидел, который со своим вторым запасным маленьким линуксом, и который умел скачивать из сети всё заново. - fk0^{легенда}(11.06.2020 21:27)
        
        Ну да, как-то так. В одном из вариантов есть три версии ядра: одна, совсем мелкая, в SPI флешке. Вторая и третья - на FAT-разделе. Загрузчик сначала пытается запустить новую версию с FAT-раздела, если не вышло - предыдущую версию с FAT-раздела, если и там облом - то мелкое ядро из SPI. А если уж и там все плохо, то загрузчик будет пытаться загрузиться по сетке. - LightElf(11.06.2020 21:53)
        
        Альтернативная загрузка... man grub или что-то другое? - Cкpипaч^пророк(11.06.2020 22:06)
        
        Вот на писюках тут всё плохо. Я не знаю как grub заставить так работать: у него есть fallback, но он предполагает запись на диск... не то. Нужен вариант: мол грузи ядро и initrd отсюда, а если контрольные суммы не сошлись -- тогда отсюда (из другого раздела, или с другого физического накопителя). У grub вроде нет, у syslinux есть ONERROR -- там можно что-то похожее сделать. - fk0^{легенда}(11.06.2020 23:20)
        
        Вроде бы U-Boot можно под писюк собрать, но это не точно - LightElf(11.06.2020 23:58)
        
        У меня U-Boot :) Писюками не занимался, про grub ничего не знаю. - LightElf(11.06.2020 22:37)
        
        ~~Дай списать :)~~ Можно пример скриптов посмотреть? - Cкpипaч^пророк(11.06.2020 22:42)
        
        Для U-Boot? Там же все очевидно. Ну вот от текущего проекта (там SPI флешка совсем мелкая, ядро не влазит). LightElf(572 знак., 11.06.2020 22:58)

Кибернетика, автоматика, протоколы