Intereting Posts
Как я могу использовать Linux в качестве шлюза? Изменение аутентификации SMTP в mutt на основе От адреса электронной почты Можете ли вы использовать grub для загрузки файла раздела RW, хранящегося на жестком диске FAT32? Как создать резервную копию виртуальных дисков с помощью PlayOnLinux? Инструмент для измерения нарисованного на экране прямоугольника? Что произойдет, если я удалю все пароли пользователей? Не допускайте множественные нажатия клавиш после префикса в tmux Разбор строки по awk и получить только элементы без труб или полуколонок Как я могу заставить gmake предоставить мне список всех включенных make-файлов? Разрешить только определенный исходящий трафик на определенных интерфейсах XML-файл с символами `^ @`? Синтаксис строки для макроса kbd в Emacs find и rsync оба дросселя по нечетно названному файлу Несколько gcc и связь между ними Отключение с нажатием клавиатуры не работает

Почему мой initrd имеет только один каталог, а именно «ядро»?

Я использую debian live-build для работы с загрузочной системой. К концу процесса я получаю типичные файлы, используемые для загрузки живой системы: файл squashfs, некоторые модули GRUB и файлы конфигурации и файл initrd.img.

Я могу нормально загружать эти файлы, передавая initrd в ядро ​​через

initrd=/path/to/my/initrd.img 

в командной строке загрузчика. Но когда я пытаюсь проверить содержимое моего образа initrd, вот так:

 $file initrd.img initrd.img: ASCII cpio archive (SVR4 with no CRC) $mkdir initTree && cd initTree $cpio -idv < ../initrd.img 

дерево файлов, которое я получаю, выглядит так:

 $tree --charset=ASCII . `-- kernel `-- x86 `-- microcode `-- GenuineIntel.bin 

Где фактическое дерево файловой системы, с типичным / bin, / etc, / sbin …, содержащим фактические файлы, используемые во время загрузки?

Указанный метод пропуска cpio не работает надежно. Это потому, что изображения initrd, которые я получал, не имели обоих архивов, объединенных на границе 512 байтов.

Вместо этого сделайте следующее:

 apt-get install binwalk legolas [mc]# binwalk initrd.img DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 ASCII cpio archive (SVR4 with no CRC), file name: "kernel", file name length: "0x00000007", file size: "0x00000000" 120 0x78 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86", file name length: "0x0000000B", file size: "0x00000000" 244 0xF4 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode", file name length: "0x00000015", file size: "0x00000000" 376 0x178 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/GenuineIntel.bin", file name length: "0x00000026", file size: "0x00005000" 21004 0x520C ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000" 21136 0x5290 gzip compressed data, from Unix, last modified: Sat Feb 28 09:46:24 2015 

Используйте последний номер (21136), который для меня не ограничен 512-байтной границей:

 legolas [mc]# dd if=initrd.img bs=21136 skip=1 | gunzip | cpio -tdv | head drwxr-xr-x 1 root root 0 Feb 28 09:46 . drwxr-xr-x 1 root root 0 Feb 28 09:46 bin -rwxr-xr-x 1 root root 554424 Dec 17 2011 bin/busybox lrwxrwxrwx 1 root root 7 Feb 28 09:46 bin/sh -> busybox -rwxr-xr-x 1 root root 111288 Sep 23 2011 bin/loadkeys -rwxr-xr-x 1 root root 2800 Aug 19 2013 bin/cat -rwxr-xr-x 1 root root 856 Aug 19 2013 bin/chroot -rwxr-xr-x 1 root root 5224 Aug 19 2013 bin/cpio -rwxr-xr-x 1 root root 3936 Aug 19 2013 bin/dd -rwxr-xr-x 1 root root 984 Aug 19 2013 bin/dmesg 

Оказывается, initrd, созданный Live-build от Debian (и, к моему удивлению, принятый ядром), на самом деле является конкатенацией двух изображений:

  • архив CPIO, содержащий обновления микрокода для применения на процессоре;
  • gzip-ed cpio archive, который фактически содержит дерево файлов initrd (с каталогами / etc / bin / sbin / dev …, которые ожидались).

После извлечения исходного initrd.img, прямо из выхода live-build, я получил этот вывод:

 $cpio -idv ../initrd.img kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin 896 blocks 

Это означает, что извлечение cpio закончилось после разбора 896 блоков по 512 байт каждый. Но исходный initrd.img был больше, чем 896 * 512 = 458752B = 448 КБ:

 $ls -liah initrd.img 3933924 -r--r--r-- 1 root root 21M Oct 21 10:05 initrd.img 

Таким образом, фактическое изображение initrd, которое я искал, было добавлено сразу после первого cpio-архива (тот, который содержит обновления микрокода), и к нему можно было получить доступ с помощью dd:

 $dd if=initrd.img of=myActualInitrdImage.img.gz bs=512 skip=896 

Если вы знаете, что ваш initrd.img состоит из несжатого cpio-архива, за которым следует сжатый gz-архив cpio, вы можете использовать следующее, чтобы извлечь все файлы (из обоих архивов) в ваш текущий рабочий каталог (проверенный в bash):

 (cpio -id; zcat | cpio -id) < /path/to/initrd.img 

Вышеупомянутая командная строка передает содержимое initrd.img качестве стандартного ввода в подоболочку, которая выполняет две команды cpio -id zcat | cpio -id и zcat | cpio -id zcat | cpio -id последовательно. Первая команда ( cpio -id ) завершается, как только она считывает все данные, принадлежащие первому архиву cpio. Оставшееся содержимое затем передается в zcat | cpio -id zcat | cpio -id , который распаковывает и распаковывает второй архив.

Если вам нужно часто выполнять эту задачу, вам может понадобиться создать небольшую функцию bash, например следующую (и, возможно, добавить ее в ваш .bashrc):

 initramfs-extract() { local target=$1 local offset=$(binwalk -y gzip $1 | awk '$3 ~ /gzip/ { print $1; exit }') shift dd if=$target bs=$offset skip=1 | zcat | cpio -id --no-absolute-filenames $@ } 

Код основан на ответе Марка, но он значительно быстрее, поскольку binwalk будет искать только файлы gzip. Вы можете вызвать его, например:

 $ initramfs-extract /boot/initrd.img -v 

Вам понадобится binwalk чтобы он работал.