What is linux rootfs

Образ rootfs

Содержание

Что такое rootfs

rootfs, то есть root file system, корневая файловая система — это архив с минималистичной системой, грубо говоря, это как если бы вы открыли файловый менеджер в корне своего Linux и запаковали всё найденное в архив, только здесь предустановлено минимально необходимое количество пакетов.

Для чего нужен rootfs

• chroot
• запуск в контейнере (systemd-nspawn, lxc, docker)
• установка системы вручную

Где скачать rootfs Росы

Раз в день автоматически выполняются сборки rootfs архитектур x86_64 и i586 на платформах rosa2016.1 и rosa2014.1.

Найти и скачать самые свежие сборки можно здесь.

Образы rootfs-min — это минималистичный образ (ввиду того, что некоторые пакеты в репозитории сейчас тянут лишние зависимости, в rootfs также есть лишние пакеты, например, grub2). Образы rootfs-std — это более расширенный набор пакетов, добавлены пакеты, необходимые для сборки других пакетов (rpm-build, git-core и др.).

Порядок скачивания последней сборки rootfs

• Зайти в список сборок
• Нажать на номер нужной сборки, обычно это последняя сборка
• Скачать нужный файл
• Распаковать его как архив

Как собрать rootfs самому

Нужно взять скрипты сборки и запустить mkimage-urpmi.sh.

Патчи и пулл-реквесты для улучшения скриптов сборки принимаются на Github.

Пример использования rootfs

Разберем на примере ежедневной сборки №25111. Контейнер назовем «rosa1».

После последней команды загрузится консоль контейнера, вводите логин root, пароль не запросит. Если убрать -b и сделать просто systemd-nspawn -D rosa1, то вы попадете в консоль без полноценного запуска виртуальной системы.

В команде wget выше

«ссылка» — это скопированная ссылка на скачивание архива, «имя файла для сохранения» — с каким именем сохранить скачанный файл, можно указать то имя, что в списке сборок. Если не указать, то файл будет назван хешем SHA1 вместо человекопонятного имени.

Пример использования на BTRFS для быстрого клонирования контейнеров

/var/lib/machines должно быть внутри раздела BTRFS.

В итоге у нас есть 3 одинаковых контейнера: /var/lib/machines/rosa1, /var/lib/machines/rosa2, /var/lib/machines/rosa3. Поскольку они одинаковые, место на диске занимается 1 раз, а не 3. После запуска каждого из контейнеров рекомендую менять hostname, чтобы было удобно их различать.

Запуск 32-битного контейнера на 64-битном хосте

Без доп. параметров всё запустится, но, например, uname и lscpu будут выдавать x86_64, в результате чего утилиты типа rpm будут думать, что они работают на 64-битной Ос, а не 32-битной.

Для решения проблемы в параметры запуска systemd-nspawn добавьте: —personality=x86, пример:

Источник

Zynq 7000. Собираем Linux и RootFS при помощи Buildroot

Продолжаем изучение SoC Zynq 7000 и разбираемся с тем, как организовать подготовку, сборку Linux для нашей отладочной платы QMTech. В прошлой статье я рассмотрел процедуру быстрой сборки (без кастомизации) основных компонентов встраиваемой системы Linux и шаг за шагом прошли путь до приглашения к вводу в работающей ОС. Согласитесь, что если вы новичок — то работа была выполнена колоссальная! К счастью, всю эту работу можно автоматизировать! И в этой статье я хотел бы уделить внимание этому вопросу и рассказать как это сделать с помощью Buildroot. Эту статью можно считать логическим продолжением общего повествования о начале работы с Linux на Zynq.

Что такое Buildroot, как им пользовать и чем он может быть полезен для нас — я постараюсь раскрыть в этой статье, без углубления в дебри, но в достаточной степени, чтобы вы могли повторить за мной всю последовательность действий и получить желаемый результат.

Всем интересующимся — добро пожаловать под кат!

Важно! Перед началом повествования, хотелось бы заранее оговориться, что основная цель, которую я преследую при написании этой статьи — рассказать о своем опыте, с чего можно начать, при изучении отладочных плат на базе Zynq. Я не являюсь профессиональным разработчиком под ПЛИС и SoC Zynq, не являюсь системным программистом под Linux и могу допускать какие-либо ошибки в использовании терминологии, использовать не самые оптимальные пути решения задач, etc. Но отмечу, что любая конструктивная и аргументированная критика только приветствуется. Что ж, поехали…

Рекомендуемые источники для более глубокого изучения

Перед началом повествования хотелось бы отдельно отметить источники информации, которые помогли мне при подготовке этого материала:

Книга Криса Симмондса Встраиваемые системы на основе Linux.

Стрим ребят из команды FPGA-Systems.ru по сборке Linux: https://www.youtube.com/watch?v=339hpNuRZDo

Что такое Buildroot и зачем он нужен?

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

Чтобы решить эту проблему профессионалы придумали нечто такое, что позволило бы автоматизировать всю процедуру сборки, настройки всего необходимого! Звучит заманчиво, не правда ли?

В результате реализации этой идеи на свет появился Buildroot! Это система автоматизированной сборки на основе GNU Make и Kconfig.

Основная идея автоматизированной сборки состоит в том, что эта система должна уметь собрать из полученного исходного кода с репозиториев всё необходимо для работы, набор для кросс-компиляции, всех инструментов, начальный загрузчик, ядро ОС, откомпилированный файл device-tree и корневую файловую систему.

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

Общая последовательность шагов которые выполняются при работе с системами сборки мне видится таковой:

Конфигурирование. В этом шаге выполняется настройка всего того, что будет в последствии собрано: от загрузчика до программ которые будут скомпилированы и включены в корневую файловую систему. Самый трудоемкий и объемный шаг, который в последствии облегчается тем, что наработки можно сохранять в файлы конфигурации и детальная настройка нужна только один раз. В дальнейшем можно переиспользовать уже готовую конфигурацию.

Скачивание исходных кодов и сохранение всего того, что было выбрано на этапе конфигурации. Также докачиваются зависимости и всё необходимое для успешной сборки.

Сборка и компиляция исходных кодов. Занимает достаточно много времени, длительность зависит от объема выбранных программ и того, насколько сложную систему вы хотите собрать.

Создание корневой файловой системы и конечная компоновка.

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

В дополнение к этому, есть еще ряд плюшек которые предоставляются системой сборки:

Можно добавлять свои программы и пакеты.

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

Очень удобно использовать при создании автономного SDK и распространения его среди других разработчиков.

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

Наличие удобного интерфейса для взаимодействия с пользователем.

Наверняка, пытливый пользователь может спросить “А ведь есть же PetaLinux который базируется на Yocto. Зачем нужен buildroot?”. И я немного разобравшись в вопросе смело могу заявить, что это абсолютно две разные системы которые подходят к решению задачи сборки довольно таки разных по сложности и преследуют совершенно разные цели.

Основная цель Buildroot — это сборка именно образа корневой файловой системы, хоть она и умеет собирать загрузчик, DTS, и образ ядра.

А что касается Yocto — это полноценная система подготовки дистрибутива Linux. Это более общая система в том, смысле что позволяет описать целевое устройство и способна собирать полновесные дистрибутивы для весьма сложных устройств. Каждый компонент в Yocto генерируется в виде пакетов RPM, DPKK или IPK и после этого все пакеты собираются в цельный образ файловой системы.

Возможно когда-нибудь в будущем я попробую разобраться и с Yocto, но точно не в этой статье. Едем дальше…

Переходим от разговоров к делу!

Сразу отмечу основные моменты касающиеся с источниками полезной информации. Сайт проекта buildroot находится по адресу http://buildroot.org. На сайте находится очень подробная документация https://buildroot.org/downloads/manual/manual.html. По большинству вопросов и для углубленного изучения — можно обращаться к ней.

Что касается используемых версий. Разработчики Buildroot выпускают стабильные версии четыре раза в год: в феврале, мае, августе и ноябре. В этой связи в Git-репозитории им соответствуют метки вида . . Обычно при начале работы с buildroot имеет смысл взять последнюю стабильную версию, но они редко обновляются после выпуска. Рекомендую все время использовать последнюю стабильные версии по мере их выхода.

Перейдем к установке

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

После клонирования репозиториев необходимо установить все требуемые зависимости:

Конфигурирование

Основная сущность, которой оперирует buildroot — это файлы defconfig, которые относятся к той или иной целевой плате. В этом файле хранятся все настройки которые отличаются от тех, что заданы по умолчанию.

Давайте посмотрим, что находится рабочем каталоге buildroot:

board — каталог с файлами, которые относятся к конкретным платам. Тут могут быть скрипты, каталог rootfs_overlay, конфигурацию ядер;

configs — в этой папке находятся те самые файлы defconfig;

dl — каталог со скачанными файлами исходного кода;

Всё, что будет скомпилировано будет положено в папку output, либо в папку указанную в параметрах компиляции с ключом O= , в которой появятся два основных каталога:

host — папка с утилитами для сборки на хосте;

build — папка с собранными пакетами;

На подробном объяснении каждой команды мы останавливаться не будем, все что нужно — можно найти в документации на buildroot.

Создадим файл, запуская который у нас будет открываться меню конфигурации:

Запишем в него следующее:

После этого можно запустить этот файл и если все необходимые зависимости установлены — будет открыто меню конфигурации buildroot:

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

Первым пунктом заходим в меню Target options и выбираем архитектуру ARM (little endian) и выбираем вариант архитектуры Cortex-A9, что собственно соответствует тому, что мы имеем на плате. Устанавливаем также опции связанные с Hard Floating Point. После проведения правильной конфигурации окно примет следующий вид:

Переходим обратно в главное меню и заходим в меню Build options. Для ускорения процедуры сборки можно поставить опцию Number of jobs to run simultaneously в соответствии с количеством ядер CPU. Остальные опции оставляем по умолчанию.

Переходим к настройке Toolchain.

В нашем случае мы воспользуемся toolchain встроенным в Buildroot. Оставляем без изменений пункт Toolchain type.

Меняем используемую C library на glibc.

В пункте Kernel Headers выбираем Custom Git Repository и в меню URL of custom repository указываем путь, к cклонированному в прошлом занятии, ядру Linux. Либо клонируем репозиторий в папку /home:

После в поле Custom repository version необходимо указать хэш текущего указателя на master-ветку в репозитории:

Смотрим версию ядра, склонированную в репозитории linux-xlnx:

Будет выведено окно настройки конфигурации ядра для последующего компилирования и в заголовке будет указана версия:

Выбираем версию ядра 5.10.х в опции Custom kernel headers series.

Устанавливаем опцию Install glibc utilities.

Выбираем версию компилятора gcc. В моем случае это gcc 9.x. Установим его в поле GCC compiler Version.

Установим поддержку C++ в поле Enable C++ support.

Далее выбираем опции Enable compiler link-time-optimization support.

Ставим поддержку мультипроцессорного режима работы программ с использованием OpenMP в поле Enable compiler OpenMP support.

Переходим в меню System configuration и тут по желанию можно написать имя целевой системы и приветственное лого. Я указал в поле System hostname — Z7020, а в System banner — Welcome to QMtech Zynq Linux!. Остальные пункты меню оставляю по умолчанию.

Переходим в меню Kernel. Если вы хотите, чтобы вместе с rootfs было так же собрано ядро Linux — включите опцию Linux kernel.

Настроим параметры ядра для последующей компиляции следующим образом.

Таким же образом указываем Custom Git repository с указанием пути до репозитория и хэша.

Указываем что корневой файл конфигурации будем использовать из in-tree источника: Kernel configuration (Using an in-tree defconfig file).

Файл defconfig указываем тот, что использовали по умолчанию при компиляции ядра в прошлом уроке: записываем в поле Defconfig name xiinx_zynq без постфикса “_defconfig”.

Выбираем опцию Kernel binary format и ставим uImage и тип компрессии gzip

Устанавливаем адрес загрузки Load address в 0x8000.

Остальные опции в этом меню остаются по умолчанию. Выглядит меню настройки следующим образом:

Переходим в меню Target options. В этом меню мы можем выбрать весь набор необходимых программ которые будут включены в состав будущего образа.

Miscelaneous — haveged, который является базовым демоном для генерации случайных чисел;

Networking — dhcpd, демон для работы с сетью и получения сетевых реквизитов по протоколу DHCP;

Networking — dropbear, демон для организации SSH-сервера;

Networking — ifupdown scripts, для работы с сетевыми интерфейсами;

Networking — iperf, iperf3, для проведения бенчмарка пропускной способности по сети (по желанию);

Переходим в меню Filesystem images. Выбираем интересующие нас образы, я выбираю только cpio и метод сжатия lzma.

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

В меню Host Utilites ставим опции:

host dosfstools

host genimage

host mtools

Все настройки завершены, записываем их путем нажатия клавиши F6 сохраняем файл с именем .config.

На этом мы можем считать, что предварительная настройка Linux закончена. Можно запускать компиляцию. Для этого я сделал скрипт br-build и записал в него следующее:

После этого необходимо присвоить ему права на исполнение и запустить:

Если все указано и настроено верно — начнется процедура скачивания исходных кодов и компиляция. Этот процесс может затянуться на многие десятки минут.

После окончания компиляции в папке images/ появятся необходимые образы:

Для того, чтобы можно было воспользоваться образом rootfs — необходимо сделать подпись для загрузки его через U-Boot. Для этого нам понадобится пакет U-Boot-tools:

После этого можно попробовать загрузить то, что у нас получилось. Копируем на загрузочную microSD файлы uImage и uramdisk.image.gz и файл devicetree.dtb который у нас был сделан в прошлом занятии.

Проверим, что получилось

Запускаем плату и попадаем в меню U-Boot. В этом меню вводим команды:

Если все получилось верно — у нас загрузится ядро, все программы которые мы указали при старте уже будут в составе ОС. И все будет готово к работе.

В целом основная задача выполнена и достигнутое можно считать хорошей заготовкой для дальнейшей кастомизации используемого образа Linux. Можно пробовать добавлять свои скрипты и проводить более углубленное изучение buildroot, например, осуществить сборку Device Tree через buildroot.

Источник