Класс image

Класс используется при создании образов файловой системы (ФС), содержащих корневую ФС, генерируемых классом rootfs для таких типов пакетов, как rootfs_ipkg class, для использования на целевой машине. Например, это может быть jffs2 образ, записываемый непосредственно во флеш память устройства. В дополнение к этому, класс настраивает источники обновлений ipkg и может создавать несколько видов образов.

Общий список действий, выполняемых классом image_ipkg:

  1. Наследование rootfs класса соответствующего типа пакетов, обычно это rootfs_ipkg class, чтобы получить необходимую для создания образа корневой ФС. Образ такой ФС создаётся из набора пакетов (обычно ipkg);

  2. Установка BUILD_ALL_DEPS = "1" чтобы система разрешения зависимостей собрала все пакеты, перечисленные в RDEPENDS и/или RRECOMENDS устанавливаемых пакетов;

  3. Определяет названия таблиц устройств образа (IMAGE_DEVICE_TABLES/IMAGE_DEVICE_TABLE), используемых для описания файлов устройств, создаваемых в директории /dev корневой ФС;

  4. Очистка содержимого любых существующих образов корневой ФС, ${IMAGE_ROOTFS};

  5. Если devfs не используется, то создаётся /dev директория, ${IMAGE_ROOTFS}/dev, и заполняется файлами устройств (используя "makedevs -r ${IMAGE_ROOTFS} -D <table>" для каждой таблицы устройств);

  6. Вызов методов rootfs_ipkg class для установки всех требуемых пакетов в корневую файловую систему;

  7. Настройка информации о ipkg источниках (используя FEED_URIS и FEED_DEPLOYDIR_BASE_URI);

  8. Выполнение команд предварительной обработки образов, указанных в ${IMAGE_PREPROCESS_COMMAND};

  9. Вызов bbimage на корневых ФС для всех требуемых типов образов, перечисленных в ${IMAGE_FSTYPES}, для создания действительных образов ФС;

  10. Выполнение команд пост-обработки образов, указанных в ${IMAGE_POSTPROCESS_COMMAND}.

Следующие переменные могут быть использованы для управления поведением класса (нужно помнить, что для сборки образа ФС используется rootfs_ipkg class, так что стоит посмотреть ещё переменные этого класса)):

USE_DEVFS

Показывает, используется ли при создании образа devfs, файловая система устройств. Если devfs используется, то нет необходимости в директории /dev на образе. Значение "1" означает использование devfs. Обратите внимание, что devfs удалена из ядра Linux в ветке 2.6 и большая часть платформ переходит на использование udev в качестве замены devfs.

Значение по умолчанию: "0"

IMAGE_DEVICE_TABLES

Определяет один, или несколько, файлов, содержащих список файлов устройств, которые должны быть созданы в /dev директории образа. Поиск файлов ведётся с использованием ${BBPATH}, так что могут быть указаны относительные пути. Файлы устройств обрабатываются в указанном порядке. Если установлена IMAGE_DEVICE_TABLE, то IMAGE_DEVICE_TABLES игнорируется.

Пример: IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt files/device_table_add-sci.txt device_table_add-sm.txt"

По умолчанию: "files/device_table-minimal.txt"

IMAGE_DEVICE_TABLE

Указывает файл, содержащий список файлов устройств, которые должны быть созданы в /dev директории образа. Список должен состоять из абсолютных путей и поэтому пути указываются относительно ${BBPATH}. При использовании этого параметра возможно указать только одну таблицу устройств. Для указания нескольких таблиц нужно использовать IMAGE_DEVICE_TABLES.

По умолчанию: ""

IMAGE_PREPROCESS_COMMAND

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

По умолчанию: ""

IMAGE_POSTPROCESS_COMMAND

Дополнительные команды для запуска после обработки образа. Обратите внимание, что эти команды выполняются в том же экземпляре fakeroot, как и остальные функции класса.

По умолчанию: ""

IMAGE_FSTYPES

Указывает типы образов, которые нужны создать. Поддерживаемые типы образов и подробности касательно модификации существующих и создания новых типов описаны в разделе image types. Переменная должна содержать разделённый пробелами список генерируемых типов образов.

Пример: "jffs2 tar.gz"

По умолчанию.: "jffs2"

FEED_URIS

Имена источников пакетов, по умолчанию прописываемых в образ. Каждая запись состоит из имени источника, двух символов решётки и URI источника.

Пример: FEED_URIS = "example##http://dist.example.com/ipkg-titan-glibc/"

По умолчанию: ""

FEED_DEPLOYDIR_BASE_URI

Если установлена, настраивает локальные проверочные источники пакетов с использованием содержимого deploy директории OE. Значением является URL, соответствующий deploy директории с ipk пакетами.

Пример: FEED_DEPLOYDIR_BASE_URI = "http://192.168.2.200/bogofeed/"

По умолчанию: ""

Обработка специальных файлов (fakeroot)

Специальные файлы, такие как /dev файлы, и файлы с особыми правами, например suid, обрабатываются с использованием fakeroot системы. Это означает, что при просмотре содержимого корневой файловой системы эти устройства выглядят некорректно созданными.

Переменные IMAGE_PREPROCESS_COMMAND и IMAGE_POSTPROCESS_COMMAND обрабатываются в том же экземпляре fakeroot, что и остальная часть класса.

Файлы устройств (/dev)

Для создания файлов устройств могут быть использованы две переменные. Новый метод поддерживает несколько таблиц устройств и поиск этих таблиц в ${BBPATH}, так что могут использоваться относительные пути.

Пример из machine/titan.conf показывает создание нескольких таблиц устройств:

# Add the SCI devices to minimal /dev
    IMAGE_DEVICE_TABLES = "
        files/device_table-minimal.txt 
        files/device_table_add-sci.txt 
        device_table_add-sm.txt"
    

В нём используются стандартные минимальные таблицы устройств, но при этом добавляются несколько дополнительных (в которых обычно нет необходимости):

files/device_table-minimal.txt

Стандартный минимальный набор файлов устройств.

files/device_table_add-sci.txt

Содержит детали создания /dev/SC{0,1,2} файлов, требуемых для SH процессоров на SCI и SCIF последовательных портах платы. На устройстве titan последовательная консоль обеспечивается через один из таких портов и поэтому должны существовать соответствующие файлы устройств.

device_table_add-sm.txt

Содержит детали создания файлов устройств /dev/sm0 и /dev/sm0p{0,1,2} для блочного драйвера и соответствующих разделов, используемых для управления встроенной флеш памятью на устройстве titan.

До поддержки нескольких таблиц устройств для этого потребовалось бы создание titan специфичных таблиц устройств.

Типы образов

Типы создаваемых образов файловых систем указываются через переменную IMAGE_FSTYPES. Полное описание доступных типов образов, настроек образов и подробности по созданию новых типов содержатся в разделе image types.

Источники пакетов

"Источники пакетов", или просто источники, это термин, используемый пакетным менеджером ipkg (наиболее часто встречающимся во встраиваемых системах), для названия репозитариев пакетов. Конструктивно, источник является директорией -- локальной, или удалённой на HTTP или FTP сервере, -- содержащей пакеты и файл-дескриптор пакетов с названием Packages или Packages.gz. Поддерживается несколько источников.

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

Метод 1: Использование существующих источников

Если у вас уже есть настроенные и доступные по некоторому URL источников, они могут быть добавлены к образу с использованием переменной FEED_URIS:

FEED_URIS = " \
        base##http://oe.example.com/releases/${DISTRO_VERSION}/feed/base \
        updates##http://oe.example.com/releases/${DISTRO_VERSION}/feed/updates"
        

FEED_URIS содержит список дескрипторов источников, разделённых пробелами и описанных согласно правилам, принятым в OE. Каждый дескриптор состоит из названия источника и его URL, соединённых "##". Имя источника является идентификатором, используемым ipkg для того, чтобы различать источники. Оно может быть произвольным, главное чтобы пользователю мог понять, какой источник для чего используется для того или иного действия.

Метод 2: Использование OE deploy директорий (только на этапе разработки)

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

Тем не менее, использование напрямую deploy директории как источника может быть полезным при разработке и тестировании, так как это позволяет разработчикам легко устанавливать вновь собранные пакеты без лишних действий. Для облегчения таких действий, OE предоставляет способ подготовки конфигурационных файлов источников для использования deploy директории как таковой. В первую очередь необходимо настроить локальный HTTP сервер для экспорта директории размещения пакетов. Допустим, вы выбрали URL "http://192.168.2.200/bogofeed" (где 192.168.2.200 -- адрес, доступный с устройства). Добавьте следующие строчки в ваш local.conf:

        FEED_DEPLOYDIR_BASE_URI = "http://192.168.2.200/bogofeed"
        

Теперь нужно настроить локальный HTTP сервер на экспорт директории. Для Apache это можно сделать следующим образом:

         
        Alias /bogofeed ${DEPLOY_DIR} 
        
        <Directory ${DEPLOY_DIR}>
            Options Indexes FollowSymLinks
            Order deny,allow
            Allow from 192.168.2.0/24
            </Directory>
        
        

Замените ${DEPLOY_DIR} на полный путь к deploy директории (путь будет оканчиваться на deploy/ipk).

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