[Vmdebootstrap-devel] Clarifying the ARM support in vmdebootstrap

[Neil Williams]

I've added a section to the manpage and a shorter section to the README
to clarify the purpose of vmdebootstrap. I've done this after spending
a considerable amount of time trying to create a generalised mechanism
to work with u-boot, until it became obvious that there is a
distinction which needs to be made.

The new section in the README is as follows:

`vmdebootstap` is aimed principally at creating virtual machines, not
installers or prebuilt installation images. It is possible to create
prebuilt installation images for some devices but this depends on the
specific device. (A 'prebuilt installation image' is a single image file
which can be written to physical media in a single operation and which
allows the device to boot directly into a fully installed system - in a
similar way to how a virtual machine would behave.)

* `vmdebootstrap` assumes that all operations take place on a local
  image file, not a physical block device / removable media.
* `vmdebootstrap` is intended to be used with tools like `qemu` on the
   command line to launch a new virtual machine. Not all devices have
   virtualisation support in hardware.

This has implications for `u-boot` support in some cases. If the device
can support reading the bootloader from a known partition, like the
Beaglebone-black, then `vmdebootstrap` can provide space for the
bootloader and the image will work as a prebuilt installation image. If
the device expects that the bootloader exists at a specific offset and
therefore requires that the bootloader is written as an image, not as a
binary which can be copied into an existing partition, `vmdebootstrap`
is unable to include that bootloader image into the virtual machine
image.

It is possible to wrap `vmdebootstrap` in such a way as to prepare a
*physical block device* with a bootloader image and then deploy the
bootstrap on top. However, this does require physical media to be
inserted and removed each time the wrapper is executed. Once you have
working media, an image can be created using ``dd`` to read back from
the media to an image file, allowing other media to be written with a
single image file. To do this, use the `--tarball` option to
`vmdebootstrap` instead of the `--image`` option. Then setup the
physical media and bootloader image as required for the device,
redefine the partitions to make space for the rootfs, create a
filesystem on the physical media and unpack the `vmdebootstrap` tarball
onto that filesystem.

...

So Cubietruck and Wandboard examples in vmdebootstrap will focus on
being VM images, not prebuilt installation images. I have got a wrapper
for wandboard but the uboot support for that isn't complete. (Patches
welcome).

The problem, as I see it, is that u-boot images get applied to physical
media at an offset and then the partitions are mangled into place
around that image. Doing the same with a file instead of media means
that the file is truncated to the size of the bootloader image -
resizing the image then breaks the bootloader image. This may be
fixable but I'm not going to spend more time on it.

Please note that there is a parallel effort ongoing on the debian-arm
mailing list "Providing (armhf) u-boot images together with d-i
images?" [0], so this work would seem to cover the needs of installing
an ARMMP image on bare metal. vmdebootstrap is going to concentrate on
virtual images - on x86 and ARM and any other architecture for which
someone can devise some examples.

[0] https://lists.debian.org/debian-arm/2014/12/msg00006.html

Therefore, there will be two types of examples available with
vmdebootstrap - prebuilt installation images (like the beaglebone-black)
and virtual machine images (cubietruck and wandboard). ARM devices
which do not support hypervisor mode and which also rely on the
bootloader being at a specific offset instead of using a normal
partition will *not* be supportable by vmdebootstrap. Similarly, devices
which support hypervisor will only be supported using virtual machine
images, unless the bootloader can be executed from a normal partition.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/vmdebootstrap-devel/attachments/20150102/44e4daba/attachment.sig>