Bering-uClibc 5.x - User Guide - Appendices - Working with Disk Image Files

From bering-uClibc
Jump to: navigation, search
Appendices - Working with Disk Image Files
Prev Bering-uClibc 5.x - User Guide Next


Introduction

Under some circumstances, especially when developing and testing Bering-uClibc 5.x using a Virtual PC, it can be convenient to work with a "virtual" disk drive image rather than "physical" disk drive media. The following notes provide hints and tips on how to do this using various standard Linux tools.

Many readers will already be familiar with mounting disk image files (in particular ISO9660 .iso image files) using a "loopback device", for example with commands like:

mount -o loop image.iso /mnt/

The main complication arises when disk partitions are involved, since it is typically necessary to work with the complete disk image at one level, in order to create and manipulate the partitions, and then to work with individual partition images at another level in order to work with files in those partitions. The problem is that the partitions start at different places within the overall disk image file and it can be difficult to work out what "offset" to use when loop-mounting individual partitions. The kpartx utility provides a neat solution to this problem.

The commands on this page were developed and tested on Fedora 15. Some commands must be run as user root (prefixed with '#') whereas other commands can be run as any user (prefixed with '$').


Raw Hard Disk Image Files

Create a Blank Image File

There are several ways of creating an empty disk image file. One of the easiest is to use the QEMU image manipulation utility:

$ qemu-img create -f raw sda.raw 256M

Work with the Whole Disk Image

The whole disk image cannot be "mounted" since it doesn't directly contain a filesystem. It can however be mapped as a loopback device:

# losetup /dev/loop0 sda.raw

At this point it is possible to manipulate the disk partition table using the usual tools: fsdisk, cfdisk, parted etc. For example:

# parted /dev/loop0 print 

Once the disk image contains a partition table use the kpartx tool to map the partitions:

# kpartx -a /dev/loop0

This creates additional device files in the /dev/mapper/ directory corresponding to each Partition within the disk image. For example, if there are two partitions:

$ ls  /dev/mapper/loop*
/dev/mapper/loop0p1  /dev/mapper/loop0p2

Work with a Disk Partition Image

If not already formatted each disk partition needs a filesystem. For example:

# mkfs.vfat /dev/mapper/loop0p1

Once formatted the disk partition can be mounted:

# mount /dev/mapper/loop0p1 /mnt/

The files on the partition can then be manipulated using all the usual tools.

Unmounting

When finished:

# umount /mnt/
# kpartx -d /dev/loop0
# losetup -d /dev/loop0


Further information at:


Virtual Machine Disk Image Files

Virtual Machine technologies such as VMware, VirtualBox and QEMU use their own file formats which are typically more efficient than "raw" image files. One disadvantage of these file formats is they cannot be processed directly by native Linux tools.

The QEMU qcow2 file format is used as an example.

Some utilities (such as qemu-nbd) can help with specific virtual image formats and the guestfish utility provides a very flexible and generic solution for many disk operations.

Create a Blank Image File

$ qemu-img create -f qcow2 sda.qcow2 256M

Using qemu-nbd

A qcow2 image cannot be mounted directly since it doesn't use a file format that the standard tools recognize. The workaround is to use a QEMU tool which presents a qcow2 image as a Network Block Device. Before this can be used the kernel module must be loaded:

# modprobe nbd max_part=8

The qemu-nbd command is a lot like the losetup command. It is used to associate a pseudo device with a disk image file. For example:

# qemu-nbd -c /dev/nbd0 sda.qcow2

From then on everything is the same as when using /dev/loop0. For example:

# cfdisk /dev/nbd0
# kpartx -a /dev/nbd0
# mkfs.vfat -n LEAF_BUC_V4 /dev/mapper/nbd0p1
# syslinux /dev/mapper/nbd0p1
# kpartx -d /dev/nbd0
# qemu-nbd -d /dev/nbd0

Using guestfish

The guestfish utility, part of libguestfs, is a tool for manipulating virtual disk image files. See the guestfish man page for more information. A key benefit is that it does not need "root" permissions. It can be a little slow though since it runs a virtual machine in the background.

Some examples:

  • List the partitions in image file sda.qcow2:
    $ guestfish add sda.qcow2 : run : part-list /dev/vda
  • Copy all the files in the /tmp/file.tar.gz file on the host OS to the root directory of the first partition within the disk image file, then list the files:
    $ guestfish add sda.qcow2 : run : mount /dev/vda1 / : tgz-in /tmp/file.tar.gz / : ls /

When the guestfish command is run with no arguments it enters an interactive command-line session.


Full Procedure to Create a Bootable Disk Image for Bering-uClibc

This section is divided in two parts, where first a raw disk image is build, to add later either a pre-build image or add a self-created image based on Packages you build yourself, e.g. for another architecture.

Create a basic "raw" disk

Here is a full procedure to create a "raw" disk image for Bering-uClibc.

  1. Create a blank disk image file:
    $ qemu-img create -f raw /tmp/sda.raw 123379200
    • The last argument is the size in bytes. Works out as: 63 sectors-per-track (assumed as a default by some utilities) x 255 heads (assumed as a default by some utilities) x 512 bytes per sector x 15 cylinders
    • This can probably be copied to a 128MB or larger flash drive and is just big enough to hold a full Bering-uClibc 4.x disk image
  2. Connect a loopback device to the disk image:
    # losetup /dev/loop0 /tmp/sda.raw
  3. Create one Primary partition occupying the whole disk:
    # echo ,,6,* | sfdisk -D -S 63 -H 255 /dev/loop0
    • That ",,6,*" is a bit cryptic. Refer to the man page for sfdisk(8) for full details but in summary it means:
      • Start the first partition at the default location (no value before the first comma)
      • Give it the default size (no value before the second comma)
      • Give it partition type 0x6 (FAT16)
      • Make it bootable (the "*")
  4. Install the Master Boot Record:
    # dd bs=440 count=1 conv=notrunc if=/usr/share/syslinux/mbr.bin of=/dev/loop0
    • This commmand syntax is recommended by the Syslinux Wiki
    • The file mbr.bin might be in a different location on your machine
  5. Create per-Partition device files:
    # kpartx -a /dev/loop0
    • Sometimes get errors like "/dev/mapper/loop0p1: mknod for loop0p1 failed: File exists" even though the command works OK
  6. Create a FAT16 file system on the first Partition:
    # mkfs.vfat -n "LEAF BUC" /dev/mapper/loop0p1
    • The "-n" just specifies a name for the file system - very much optional but a nice touch
  7. Install SYSLINUX on the first Partition:
    # syslinux /dev/mapper/loop0p1
  8. Remove per-Partition device files:
    # kpartx -d /dev/loop0
  9. Disconnect the loopback device:
    # losetup -d /dev/loop0
    • At this point is it sensible to preserve a copy of the disk image file to avoid having to repeat the above steps

Testing a pre-build disk image

These steps are necessary to test an image, where the LEAF Bering-uClicb developers already provides either an image or a buildimage setup to build one.

  1. Load the files from one of the downloadable Bering-uClibc "disk images", for example:
    $ guestfish add /tmp/sda.raw : run : mount /dev/vda1 / : tgz-in /tmp/Bering-uClibc_5.0_i486_syslinux_vga.tar.gz /
  2. Boot the disk image with QEMU:
    $ qemu -hda /tmp/sda.raw

Testing a self-build image from packages directory

This procedure describes, how to build quickly an image for yourself and test it with qemu. It's especially useful when testing architectures the LEAF Bering-uClibc developers do not provide an image for and you have build Packages yourself with the toolchain. The example below describes the steps for the arm-versatile flavor and starts at the point that all Packages has been already build. They are stored in package/armv5te-unknow-linux-uclibcgnueabi, the place where we start the procedure.

  1. Copy the arm-versatile kernel into the directory and rename it to linux:
    cp ../../build/armv5te-unknown-linux-uclibcgnueabi/kernel/linux-3.2.31-versatile linux
  2. Add a proper leaf.cfg file, a minimal one looks like this:
LRP="root license dhcpcd keyboard shorwall dnsmasq dropbear" 
PKGPATH=/dev/sda1:vfat
syst_size=60M
log_size=8M 
  1. Build a tar-gzipped image:
    tar cvf - * | gzip -9 -c - > /tmp/img.tgz
  2. Add your image to the raw disk:
    sudo guestfish add /tmp/sda.raw : run : mount /dev/vda1 / : tgz-in /tmp/img.tgz /
    A tar error message like Cannot change ownership to uid 1000, gid 1000: Operation not permitted can be ignored.
  3. Concatenate initmod.lrp and initrd.lrp into one initrd. This is a necessary because qemu does not support more than one entry for the option -initrd :
    cat initrd.lrp initmod-versatile.lrp > initrd-versatile.lrp
  1. Boot from the raw disk image with qemu
qemu-system-arm -m 256 -machine versatilepb -cpu arm926 -kernel linux -initrd initrd-versatile.lrp -hda /tmp/sda.raw \
-append "rw root=/dev/ram0 LEAFCFG=/dev/sda1:vfat" -serial stdio



Prev Up Next