Для подготовки образа SD карты в составе KasperskyOS-Community-Edition-1.1.1.40 предлагается набор скриптов rpi4_prepare_fs_image_rev1.[x].sh
Однако при ряде обстоятельств работа скрипта может завершиться неудачей.
В процессе работы скрипты:
1. Пробуют установить инструменты сборки - хорошо бы просто проверять их наличие в системе, если нет то отправлять разработчика в справку с требованиями.
2. Скачивают образ Debian для Rpi - довольно большой объем, жесткие ссылки, что если пути образов изменятся?
3. Делают клон репозитория u-boot в папке tmp - а что если tmp смонтирован с ограничением размера?
4. Делают сборку u-boot - довольно длительная процедура, при этом результат не сохраняется.
5. Монтируют образ Debian для Rpi на loop
6. Переразмечают раздел корна на 1Gb
7. Редактируют в образе файлы конфигурации в образе
Немного критики. Хоть процедура подготовки образа и не является частой операцией, всё же на определённых этапах повторять приходится. При этом повторяется и весь этот овер-ворк с загрузкой неслабых объемов по сети и довольно долгой сборкой загрузчика. Вообще было бы хорошо чтобы промежуточный результат, ну например архивы образов и репозиторий u-boot сохранялись в некоем кэше.
А вообще в идеале, просьбы по процедуре подготовки образа следующие:
1. Предложить свой набор бинарников u-boot (можно наверное еще существенно порезать по функционалу)
2. Сделать опцию или конфиг где можно указать размер root раздела. Примеры в составе дистрибутива кажется не дают бинарников жирнее 40Мб. И получается можно использовать бросовые карточки минимальных размеров.
Вообще кажется что при таком подходе можно отказаться от необходимости выяснять ревизию конкретной RPi 4B, кажется что разница только в файлах device-tree причем с точки зрения поддержки периферии в КоС несущественная (конечно это вопрос тщательной проверки).
Добрый день!
Для подготовки образа SD карты в составе KasperskyOS-Community-Edition-1.1.1.40 предлагается набор скриптов rpi4_prepare_fs_image_rev1.[x].sh
Однако при ряде обстоятельств работа скрипта может завершиться неудачей.
В процессе работы скрипты:
1. Пробуют установить инструменты сборки - хорошо бы просто проверять их наличие в системе, если нет то отправлять разработчика в справку с требованиями.
2. Скачивают образ Debian для Rpi - довольно большой объем, жесткие ссылки, что если пути образов изменятся?
3. Делают клон репозитория u-boot в папке tmp - а что если tmp смонтирован с ограничением размера?
4. Делают сборку u-boot - довольно длительная процедура, при этом результат не сохраняется.
5. Монтируют образ Debian для Rpi на loop
6. Переразмечают раздел корна на 1Gb
7. Редактируют в образе файлы конфигурации в образе
Немного критики. Хоть процедура подготовки образа и не является частой операцией, всё же на определённых этапах повторять приходится. При этом повторяется и весь этот овер-ворк с загрузкой неслабых объемов по сети и довольно долгой сборкой загрузчика. Вообще было бы хорошо чтобы промежуточный результат, ну например архивы образов и репозиторий u-boot сохранялись в некоем кэше.
А вообще в идеале, просьбы по процедуре подготовки образа следующие:
1. Предложить свой набор бинарников u-boot (можно наверное еще существенно порезать по функционалу)
2. Сделать опцию или конфиг где можно указать размер root раздела. Примеры в составе дистрибутива кажется не дают бинарников жирнее 40Мб. И получается можно использовать бросовые карточки минимальных размеров.
Вообще кажется что при таком подходе можно отказаться от необходимости выяснять ревизию конкретной RPi 4B, кажется что разница только в файлах device-tree причем с точки зрения поддержки периферии в КоС несущественная (конечно это вопрос тщательной проверки).