Создание .img из tarball: устройства / dev / loop

Я пытаюсь сделать .img из tarball, используя следующий скрипт, который я нашел:

#!/bin/bash # Packages required # dosfstools parted # Can be run on any Linux system # loop.max_part=15 must be in kernel cmdline (cmdline.txt for rpi) # then reboot echo "creating image to fit on 2Gb card" dd if=/dev/zero of=arch-rpi.img bs=1M count=1850 echo "Partitioning" fdisk arch-rpi.img <<EOF o n p 1 +100M t c n p 2 w EOF sleep 5 losetup -f arch-rpi.img sleep 5 echo "Formatting vfat" mkfs.vfat /dev/loop0p1 sleep 5 mkdir boot echo "Mounting boot" mount /dev/loop0p1 boot echo "Installing" echo "Formatting ext4" mkfs.ext4 /dev/loop0p2 sleep 5 mkdir root echo "Mounting root" mount /dev/loop0p2 root wget http://archlinuxarm.org/os/ArchLinuxARM-rpi-latest.tar.gz echo "Installing" bsdtar -xpf ArchLinuxARM-rpi-latest.tar.gz -C root sync mv root/boot/* boot sync umount boot root losetup -d /dev/loop0p1 losetup -d /dev/loop0p1 losetup -d /dev/loop0 echo "All complete, image arch-rpi.img created, compressing...." zip -9 arch-rpi.img.zip arch-rpi.img 

Я делаю это на моей малине Pi – Raspbian Wheezy. И когда он добирается до строки mkfs.vfat /dev/loop0p1 он говорит, что такого файла / каталога нет. Я достаточно читал о Linux, чтобы знать, что я пытаюсь подключить .img как устройство цикла, а затем использовать mkfs для подготовки изображения для tarball, но я не совсем понимаю, почему файлов loop0p # там нет, они перечислены fdisk -l . Что мне нужно для того, чтобы получить этот скрипт, который я нашел?

    2 Solutions collect form web for “Создание .img из tarball: устройства / dev / loop”

    В драйвере loop поддержка разделов является необязательной, определяемой аргументом max_part при загрузке драйвера. Значение по умолчанию равно 0, поэтому драйвер цикла даже не ищет разделы; с ненулевым значением, драйвер поддерживает это множество разделов. В зависимости от параметров сборки ядра драйвер может быть включен в ядро, и в этом случае вам нужно передать loop.max_part=… в командной строке ядра во время загрузки или загрузить в качестве модуля, и в этом случае вам понадобится передать max_part=… при загрузке модуля.

    В Debian wheezy loop – это модуль, и аргумент max_part не передается. Чтобы получить поддержку раздела, выгрузите модуль и загрузите его с помощью аргумента max_part (сначала вам нужно деактивировать любое существующее устройство цикла с помощью losetup -d ):

     if lsmod | grep -wq loop; then rmmod loop; fi modprobe loop max_part=31 

    Вы можете сделать это по умолчанию, добавив options loop max_part=31 в /etc/modprobe.conf .

    Если вы не можете позволить выгрузить модуль (или перезагрузиться, в дистрибутиве, где loop встроен в ядро), вы можете вместо этого рассчитать смещение раздела вручную и использовать параметр -o для losetup . См. Чтение файловой системы со всего образа диска

    С более новыми дистрибутивами вы можете использовать losetup -P при настройке устройства loop :

     … losetup -P -f arch-rpi.img … 

    но пакет util-linux на Debian wheezy слишком стар, чтобы иметь этот вариант.

    Вам нужно использовать losetup -P для создания устройства с петлями -P , или вам нужно разбить исходное устройство-контур, а затем partx -u pdate таблицу разделов ядра после этого. Устройства /dev/loop0p появятся после того, как ядро ​​узнает, что раздел действительно был разделен. Вероятно, это отчасти то, что намерение за спиной sleep 5 – но это почти наверняка будет sync – или и то, и другое – вместо этого.

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

     sudo sh -s <<\IN losetup -D fallocate "-l$((1024*1024*1024))" loop printf %s\\nn '' '' '' '' wy | gdisk loop sync; losetup -f loop lsblk /dev/loop* IN 

    Таким образом, указанная выше последовательность -D выдает все текущие устройства loop (если есть), fallocate sa 1GB tmp-файл, записывает в него таблицу разделов GPT и делает на нем один раздел, затем sync файловую систему и назначает ее в -first доступное устройство цикла, прежде чем пытаться перечислить с помощью lsblk все доступные петлевые устройства. Он печатает:

     NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1G 0 loop 

    Но если я losetup строку losetup образом:

     losetup -fP loop 

    … он вместо этого печатает:

     NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1G 0 loop ├─loop0p1 259:0 0 1023M 0 loop └─loop0p2 259:1 0 1007K 0 loop 

    … потому losetup сначала losetup сканирует файл резервной losetup для таблицы разделов. Как вы можете видеть, это не очень хорошо – вместо того, чтобы отметить лишнюю 1M (что почти наверняка является последней таблицей разделов последней итерации), как нераспределенное пространство, которое она интерпретирует как отдельный раздел, но это, вероятно, потому, что я пишу к tmpfs (дважды подряд) в верхней части отверстия в 1 ГБ файла – работа с фактическими данными будет намного более точной (и обнуление файла резервной копии, так как ваш скрипт w / dd будет обрабатывать это в любом случае) . В любом случае – я могу свободно mkfs.whatever на реальном разделе там, а затем mount его. partx -u на /dev/loop0 достигнет тех же результатов.

    Linux и Unix - лучшая ОС в мире.