Cpio linux как распаковать

Обновлено: 05.07.2024

Во многих наших проектах используются open-source библиотеки. Когда разработка ведется под одну конкретную платформу, нет смысла собирать одни и те же библиотеки из исходников каждый раз, когда к проекту подключается новый разработчик. Кроме того, установка библиотек а-ля make && sudo make install считается плохим тоном, поскольку система засоряется «бесхозными» файлами, о которых нет информации в базе данных менеджера пакетов RPM.

В качестве решения предлагается из скомпилированных библиотек собирать RPM-пакеты и хранить их в едином репозитории, доступном для всех разработчиков. Ниже приводится инструкция и некоторые советы по сборке пакетов.

Инструкция будет основываться на примере Red Hat Enterprise Linux 6, но с небольшими изменениями ее можно будет адаптировать и для других дистрибутивов. Для примера будем собирать пакет из библиотеки zeromq.

Перед сборкой пакета

rpmbuild

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

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

rpmbuild при запуске будет искать файлы пакета в директории

/rpmbuild/BUILDROOT/<имя_пакета>. Разберемся, как именуются RPM-пакеты, на примере zeromq:

zeromq — собственно, имя пакетируемого ПО;
3.2.4 — версия ПО;
1.rhel6 — номер сборки пакета (release number) — сколько раз данная версия ПО собиралась в rpm-пакет. Суффиксом rhel6 или el6 обычно обладают пакеты для Red Hat Enterprise Linux 6;
x86_64 — процессорная архитектура, под которую скомпилировано ПО.

Итак, создаем директорию для zeromq в BUILDROOT:

Сборка библиотеки

Само собой, перед сборкой бинарного пакета, нужно скомпилировать саму библиотеку. Если библиотека использует систему сборки GNU Autotools, то обычно это делается командами:

Теперь устанавливаем библиотеку в созданную нами директорию в BUILDROOT:

Параметр DESTDIR не всегда обрабатывается в мейкфайлах. Например, qmake генерирует мейкфайлы, которые игнорируют этот параметр. Если библиотека использует систему сборки, отличную от GNU Autotools, то прочитайте в соответствующем руководстве, какие параметры нужно передать при сборке, чтобы установить библиотеку в указанную директорию.

spec-файл для сборки пакета

В RPM-пакетах помимо заархивированного дерева файлов хранится метаинформация об этом пакете. При сборке она должна задаваться в spec-файле, который находится в папке

/rpmbuild/SPECS. Рассмотрим пример файла zmq.spec для библиотеки zeromq:

В начале файла указывается минимальный набор полей с информацией о пакете. Из значений первых трех полей (Name, Version, Release) формируется имя пакета, поэтому важно, чтобы там были указаны правильные значения. Если значения не будут соответствовать имени каталога с деревом файлов собираемого пакета, rpmbuild выдаст ошибку. Поле License также является обязательным — без него rpmbuild откажется собирать пакет.

Назначение секции %description очевидно. Секции %post и %postun содержат скрипты, выполняющиеся после установки файлов пакета в систему и после удаления файлов пакета из системы, соответственно. Это полезно, если пакет устанавливает динамические библиотеки (.so) в нестандартные директории (т. е. не в /lib, /usr/lib, /lib64 или /usr/lib64). В этом случае пакет должен предоставлять файл конфигурации для ldconfig и устанавливать его в /etc/ld.so.conf.d. Команда ldconfig обновляет кэш динамического загрузчика, добавляя в него все библиотеки, найденные в директориях, указанных в конфигурационных файлах.

В секции %files указывается список файлов, которые пакуются в rpm. Директива %defattr указывает атрибуты файлов по умолчанию в формате:

%defattr(<file mode>, <user>, <group>, <dir mode>)

<file mode> указывается в восьмеричном виде, например, «644» для rw-r--r--. Атрибут <dir mode> может быть опущен. Вместо атрибутов, которые не должны меняться для устанавливаемых файлов, можно указать дефис. Директории, указанные в секции %files, будут внесены в пакет вместе со всем их содержимым.

Дальше самое интересное. Фактически существует два типа RPM-пакетов библиотек. В одних находятся собственно сами файлы динамических библиотек, необходимые для работы программ, которые скомпонованы с этими библиотеками. Например, пакет zeromq-3.2.4-1.rhel6.x86_64.rpm предоставляет только два файла: /usr/lib64/libzmq.so.3.0.0 и символьную ссылку на него, /usr/lib64/libzmq.so.3. Другой тип пакетов содержит файлы, необходимые для разработки приложений с использованием предоставляемой библиотеки. К имени таких пакетов добавляется суффикс "-devel", например, zeromq-devel-3.2.4-1.el6.x86_64.rpm. В таких пакетах обычно содержатся заголовочные файлы C/C++, документация, статические библиотеки (.a), и эти пакеты являются зависимыми от пакетов первого типа.

В приведенном выше spec-файле директива %package позволяет собрать «дочерний» пакет одним запуском rpmbuild. Значения полей заголовков дочернего пакета наследуются от родительского, но их можно переопределить. Поле Requires задает дополнительную зависимость от родительского пакета. Заметьте, что секция %files пакета zeromq-devel содержит файл /usr/lib64/libzmq.so. Это символьная ссылка на настоящий файл с динамической библиотекой. Он необходим компоновщику ld на этапе сборки приложения с использованием библиотеки, поскольку он ищет файлы динамических библиотек, начинающиеся на «lib» и заканчивающиеся на ".so".

Сборка

Перед сборкой нужно иметь в виду две вещи.
Первое: при успешной сборке пакета rpmbuild очистит директорию BUILDROOT. Так что на всякий случай сделайте резервную копию пакетируемых файлов.
Второе: никогда не собирайте пакеты с правами root. Здесь объясняется, почему так нельзя делать.

Теперь все готово для сборки пакета. Запускаем rpmbuild:

Параметр -bb означает «build binary», то есть, собрать бинарный пакет. Помимо бинарных пакетов есть еще пакеты исходных кодов, но они здесь не обсуждаются.

В случае успеха полученный rpm-пакет будет сохранен в папке RPMS.

Пара советов

Если не знаете, что писать в полях заголовка spec-файла для пакетируемой библиотеки, можно взять RPM-пакет для другого дистрибутива c указанных выше ресурсов и посмотреть, что пишут там:

Здесь «q» означает «режим запросов (query)», «i» — получение информации о пакете, «p» — получение информации об указанном файле пакета (без этой опции будет получена информация о пакете, установленном в системе, если он установлен).

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

Утилита rpm2cpio пишет в стандартный вывод cpio-архив, хранящийся в rpm-пакете; утилита cpio распаковывает архив, принятый из стандартного ввода. Параметр «i» включает режим распаковки, а «d» создает нужные директории.

Посмотреть, какие файлы предоставляет пакет, можно и не распаковывая его, с помощью опции «l»:

Архивация cpio по сути представляет собой поток файлов и каталогов в единый архив, зачастую получающий расширение .cpio. Архив имеет заголовочную информацию, позволяющую приложению, такому, как например, GNU cpio, извлекать файлы и каталоги в файловую систему. Заголовок архива cpio также содержит дополнительную информацию, как например, имя файла, время создания, владельца и права доступа (разрешения).
cpio-архив по функциональности схож с tar-архивом и создавался для хранения бэкапов на ленточных устройствах (например, стримерах) последовательным способом. Как и формат tar, CPIO-архивы часто сжимаются при помощи Gzip и поставляются в виде файлов с расширением .cpgz (или .cpio.gz).
Oracle поставляет значительную часть своего программного обеспечения в формате cpio.

Использование cpio

Архивация

Если вы хотите заархивировать целиком дерево каталогов (перед этим: cd нужная папка), то команда find может передать список файлов и папок в cpio:
% find ./* | cpio -o > tree.cpio

Копирование

Cpio копирует файлы из одного дерева каталогов в другой при этом сочетая шаги copy-out и copy-in без «настоящего» использования архивации. Она считывает список файлов для копирования из стандартного потока ввода; целевой каталог, в который их нужно скопировать, указывается как обязательный аргумент.

Извлечение

Для извлечения файлов из cpio-архива, передайте имя архива утилите cpio через стандартный ввод.
Внимание! Это произведёт перезапись файлов без подтверждения!

Флаг -i указывает cpio считать архив для извлечения файлов, а флаг -d говорит cpio создать при необходимости соответствующие каталоги. Вы также можете указать флаг -v для вывода списка имён извлечённых файлов.
Все дополнительные аргументы командной строки являются shell-образными glob-шаблонами; только те файлы в архиве, чьи имена совпадают по крайней мере с одним шаблоном, могут быть скопированы из архива. В следующем примере извлекается etc/fstab из архива (формат содержимого архива должен сначала проверяться командой `cpio -l` для проверки того, как хранится путь) :

Как распаковать архив, созданный CPIO и GZIP

В чём разница между CPIO и TAR

Хорошее описание про различие между этими программами:

cpio полагается на использование внешней команды find, результат которой будет использован в качестве списка файлов для помещения в архив. Для упаковки архива также нужна внешняя команда.

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

CPIO — это достаточно старый (1990 год), но в то же время очень удобный вариант архива. Он достаточно прост, и, возможно поэтому, получил широкое распространение. Например данный формат используют RPM, initramfs ядра Linux, а также установщик архивов «pax» от Apple.

Данный архив позволяет собирать любое число файлов, директори и других объектов файловой системы (символических ссылок и т.д.) в единый поток байт.

Давайте на примерах рассмотрим формат этого архива.

Каждый объект файловой системы в таком архиве состоит из заголовка с базовыми метаданными, за которым следует полный путь к объекту и содержимое этого объекта. Заголовок содержит набор целочисленных значений, которые во многом повторяют поля структуры stat(2) файла в *nix системах. Конец архива помечается специальной записью (аналогичной остальным) с названием 'TRAILER. '.

Формат Файла.

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

Заголовок формата записи имеет следующую структуру:

Здесь предполагается, что тип unsigned short имеет размер 16 бит.

c_magic
Целочисленное значение, равное 070707 (в восьмеричной СС), или 0x71c7 (в шестнадцатеричной СС). Используется для определения порядка байт (little-endian vs big-endian).

c_dev,c_ino
Номера устройства и инода (inode) с диска. Соответствуют значениям, в структуре stat. Если значение inode больше 65535, то старшие разряды будут утеряны.

c_mode
Поле одновременно определяет права доступа и тип объекта:

0170000	Маскирует биты типа файла
0140000	Сокет
0120000	Символическая ссылка. Для символических ссылок, тело ссылки будет содержать путь к файлу, на который та ссылается.
0100000	Обычный файл
0060000	Специальное блочное устройство
0040000	Каталог
0020000	Специальное символьное устройство
0010000	Именованный канал(named pipe) или очередь(FIFO).
0004000	SUID
0002000	SGID
0001000	Sticky bit.
0000777	Младшие 9 бит определяют права доступа к объекту.

c_uid,c_gid
Идентификаторы пользователя и группы владельца файла.

c_nlink
Количество ссылок на этот файл. Для каталогов значение этого поля всегда не меньше двух.

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

c_mtime
Время последнего изменения файла. Формат соответствует количеству секунд,
прошедшего с начала эпохи UNIX. 32-битное целое записывается как массив двух
16-битных целых: сначала старшие разряды, потом младшие.

c_namesize
Длина строки полного пути к файлу включая терминальный NULL.

c_filesize
Размер файла.

Сразу за заголовком помещается полный путь к объекту. Если длина строки пути не кратна степени двойки, то в конец добавляется еще один NULL. Затем помещается содержимое файла. Если размер содержимого не кратен степени двойки, то дополняется нулями.

Пример архива.

Теперь давайте возьмем микроскоп. Я в качестве микроскопа возьму Bless. Не скажу, что мне этот hex-редактор очень нравится, но название того, который мне нравится я забыл.

Создадим простой каталог:

Здесь testl.txt — это символическая ссылка на файл test.txt.
Содержимое файла test.txt:

Затем создадим архив:

и откроем получившийся архив в любимом hex-редакторе.

У меня этот архив выглядит так:

Ну что ж, давайте разбираться.

0x71c7 = 070707 — начало заголовка. И мы уже можем сказать, что порядок байт при создании архива — little-endian.
0x0809 — это c_dev — номер устройства на котором находится файл.
0x349a — это c_ino — inode. В данном случае как раз старшие разряды были утеряны.
0x41fd = 0040775 — c_mode. То есть заголовок описывает каталог с правами доступа 0775.
0x01f4 = 500 — c_uid.
0x01f4 = 500 — c_gid.
0x0002 — c_nlink. На каждый каталог существует как минимум две ссылки (. и ..)
0x0000 — c_rdev.
0x4e8c и 0x3109 — это старший и младший разряды 32-битного значения времени модификации файла. 0x31094e8c = 1317810441.
0x000a — длина имени каталога.
0x00000000 — у каталога нет тела.
Далее идет название каталога.

Затем сразу следует заголовок следующей записи. Не будем подробно на ней останавливаться — только заметим некоторые отличия:
c_mode: 0x34a2 = 0100664 — показывает, что это обычный файл с правами доступа 664.
0x0000001e — размер содержимого файла.
В остальном запись похожа не описание каталога.

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

Вот таким не хитрым образом создается архив CPIO. В будущем хотелось бы в аналогичной манере рассмотреть формат файла, создаваемого Gzip. В частности при помощи связки cpio+gzip создается ramfs, используемая ядром GNU/Linux.

В комментариях к статье “Прошиваем роутер Upvel UR-313N4G на OpenWRT” между вашим покорным слугой и уважаемым Maysoft завязался спор насчет различий в структуре образов uImage и sysupgrade прошивки OpenWRT. Я обещал Maysoft разобраться в проблеме, и вот перед вами эта статья.

Как известно, в каталоге загрузок OpenWRT доступны, по большей части, прошивки двух типов — uImage и sysupgrade, например:

Официальный FAQ пишет об их различиях весьма скупо:

What is the difference between the different image formats?
a factory image is one built for the bootloader flasher or stock software flasher
a sysupgrade image (previously named trx image) is designed to be flashed from within openwrt itself
The two have the same content, but a factory image would have extra header information or whatever the platform needs. Generally speaking, the factory image is to be used with the OEM GUI or OEM flashing utilities to convert the device to OpenWrt. After that, use the sysupgrade images.

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

Отлично, сравним размер прошивок:

openwrt-15.05-rc3-ramips-rt305x-dir-320-b1-initramfs-uImage.bin — 3253035 байт.

openwrt-15.05-rc3-ramips-rt305x-dir-320-b1-squashfs-sysupgrade.bin — 3407876 байт.

Ого, прошивка sysupgrade почти на 140 Кб больше uImage, а по документации они должны быть примерно одного размера, причем uImage за счет этой самой “extra header information” — немного больше.

Конечно, достаточно посмотреть в сборочные скрипты, чтобы понять, чем различаются uImage и sysupgrade-образы, но это, согласитесь, неспортивно. Сегодня мы будем анализировать прошивки “в лоб”, как будто у нас нет исходников, а уже в конце заглянем в сборочные скрипты, чтобы подтвердить наши догадки.

Основным средством анализа прошивок на данный момент является утилита binwalk, доступная под Linux. Переименуем файлы прошивок покороче, чтобы нам было удобнее, и начнем анализ.

Кажется, вся прошивка представляет собой образ uImage — в начале следует заголовок длиной 64 (0x40) байт, а вслед за нам — поток данных, сжатый алгоритмом LZMA, размером 3252971 байт. Сложим 64 и 3252971, получим 3253035 байт, то есть размер скачанного образа. Следовательно, кроме образа uImage в файле больше ничего нет. Binwalk умеет распаковывать найденные LZMA-потоки. В принципе, можно вручную отрезать от файла первые 64 байта и распаковать остаток командой lzma -d, но зачем, когда есть такой удобный инструмент?

Посмотрим, что у нас получилось

Файл с именем 40 (смещение в исходном файле) — и есть распакованный поток. Натравим на него binwalk:

А здесь у нас что-то, на первый взгляд, непонятное — binwalk обнаружил ядро Linux по смещению 0x2AEB14 и три сжатых потока данных, следующих за ядром. Дело в том, что binwalk для анализа использует эвристики и то, что получается у него на выходе — не истина в последней инстанции, а информация к размышлению.
Здравый смысл подсказывает, что ядро должно начинаться со смещения 0, а сжатый поток — быть один и содержать initramfs — начальную файловую систему, загружаемую в RAM. О том же говорит и документация на ядро:

What is initramfs?
— All 2.6 Linux kernels contain a gzipped «cpio» format archive, which is extracted into rootfs when the kernel boots up. After extracting, the kernel checks to see if rootfs contains a file «init», and if so it executes it as PID 1.

Populating initramfs:
— The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary. By default, this archive is empty (consuming 134 bytes on x86).

Здесь же упоминается и формат потока — CPIO.

Посмотрим, что binwalk сможет извлечь из нашего образа:

Итак, успешно распаковался только поток по смещению 33E2C8. Если мы все правильно делаем, то это должен быть CPIO-контейнер с файловой системой:

В конце архива мы видим файл с именем TRAILER. который. согласно документации, является меткой конца архива.

Значит, структура прошивки initramfs-uImage такова:

Теперь возьмемся за образ squashfs-sysupgrade. Из названия следует, что в образе содержится (кроме ядра) файловая система squashfs. Посмотрим, так ли это:

Возьмемся за арифметику: 64 + 1142606 (image size) = 1142670, как раз по этому смещению начинается образ squashfs, а заканчивается он по смещению 1142670 + 2221946 = 3364616. Размер образа, между тем, 3407876 байт, значит, у нас есть еще 3407876 — 3364616 = 43260 байт неидентифицированной информации. Посмотрим, что там, hexdump’ом

Тут явно какая-то заглушка. Вернемся к ней позднее.

Посмотрим, что у нас в каталоге с распакованным образом:

Распакуем LZMA-поток по смещению 40:

Здесь у нас ядро Linux и небольшой initramfs-образ с четырьмя файлами. Остальное, видимо, переместилось в образ squashfs:

Действительно, основная файловая система содержится в образе squashfs.

Теперь разберемся с заглушкой в конце образа. Есть подозрение, что она как-то относится к ФС JFFS2, потому что при прошивке образа sysupgrade и последующей загрузке в dmesg появляются строки:

а при прошивке и загрузке образа uImage этих строк нет. Поиск в “ванильном“ ядре по этим строкам ничего не дает, а вот в дереве исходных кодов OpenWRT такие строки есть:

Ага, вот и наша заглушка 0xDEADCODE. Если драйвер JFFS2 находит эту метку, то он считает ее концом предыдущей файловой системы и стирает все, начиная с нулевого байта метки и заканчивая концом накопителя. Таким образом сама метка также затирается.
После этого драйвер создает на этом месте новый экземпляр JFFS2.
Итак, получается следующая структура образа:

uImage содержит минимально необходимый функционал для запуска OpenWRT и за счет этого его структуру можно легко изменить так, чтобы она проходила проверки на корректность в Web-интерфейсах оригинальных прошивок.
Sysupgrade устроен сложнее и использует Linux-специфичные инструменты — SquashFS и JFFS2.
Оба типа образов не содержат начального загрузчика (и не должны)
При прошивке через начальный загрузчик (через UART или аварийное восстановление) можно сразу шить sysuprade.
При прошивке через mtd_write, если эта утилита доступна через telnet из официальной прошивки, также можно сразу шить sysupgrade.

В заключении заглянем сборочные скрипты OpenWRT, чтобы убедиться в своих выводах. Начнем с файла /target/linux/ramips/Makefile. Но если вы думаете, что это обычный GNU Makefile, то это не так. Вот как описывают улучшенный Makefile сами разработчики:

Looking at one of the package makefiles, you'd hardly recognize it as a makefile. Through what can only be described as blatant disregard and abuse of the traditional make format, the makefile has been transformed into an object oriented template which simplifies the entire ordeal.

Кажется, сборка образа запускается в строке 564:

Цель BuildFirmware/Default8M описана в строках 195 и 196:

Она состоит из двух позиций: squashfs и initramfs. Цели BuildFirmware/OF и BuildFirmware/OF/initramfs описаны в том же файле чуть выше

По имени цели MkImageLzmaDtb можно догадаться, что она создает образ uImage по описанию из DTS-файла. Для цели BuildFirmware/OF/initramfs к этому образу добавляется раздел initramfs с основной файловой системой, после чего образ копируется в выходной каталог. Для цели BuildFirmware/OF исходный образ обрабатывается функцией MkImageSysupgrade, которая с помощью команды “cat” прицепляет к нему раздел squashfs, а затем, взывает функцию prepare_generic_squashfs, определенную в файле image.mk.

А утилита padjffs2, написанная на C, записывает отметку 0xDEADCODE в конец файла образа:

В общем, мир OpenWRT прекрасен и удивителен, особенно доставляют комментарии типа:

Читайте также: