| VMDEBOOTSTRAP(8) | System Manager's Manual | VMDEBOOTSTRAP(8) |
vmdebootstrap - install basic Debian system into virtual disk image
vmdebootstrap is a helper to install basic Debian system into virtual disk image. It wraps debootstrap. You need to run vmdebootstrap as root. If the --verbose option is not used, no output will be sent to the command line. If the --log option is not used, no output will be sent to any log files either.
To use the image, you probably want to create a virtual machine using your preferred virtualization technology, such as kvm or qemu. Configure the virtual machine to use the image you've created. Then start the virtual machine and log into it via its console to configure it. The image has an empty root password and will not have networking configured by default. Set the root password before you configure networking.
$ sudo vmdebootstrap --image=FILE --size=SIZE [--mirror=URL] [--distribution=NAME]
"S0:23:respawn:/sbin/getty \-L ttyS0 115200 vt100"
The --enable-networking option uses the /etc/network/interfaces.d/ source directory, with the default settings for lo and eth0 being added to /etc/network/interfaces.d/setup. Other networking configuration can be specified using a customisation script. Localhost settings would be:
auto lo iface lo inet loopback
If --enable-dhcp is specified, these settings are also included into /etc/network/interfaces.d/setup:
auto eth0 iface eth0 inet dhcp
In addition, wheezy images do not boot if the roottype is specified as the default of ext4, so vmdebootstrap will fail if a --roottype is not specified or is specified as ext4.
In addition, systemd in jessie or later introduces PredictableNetworkInterfaceNames which are enabled using the systemd-networkd service. If this option is disabled, traditional interface names (like eth0) will be used and the predictable names masked using udev. Implementing the mask requires updating the initramfs, so the --update-initramfs option must not be disabled.
If DHCP is also enabled, the following configuration is used:
/etc/systemd/network/99-dhcp.network
systemd will use the first available match, so this can be overridden by putting another file into place using the customisation scripts, using a lower sorting filename.
There is no need to use the --enable-dhcp option when using systemd for networking with stretch or sid. systemd-resolved is enabled instead if systemd-networkd is specified. (--enable-dhcp would simply add an unused entry to /etc/network/interfaces for eth0.)
[Match] Name=en* [Network] DHCP=yes
Unless the --no-extlinux or --grub options are specified, the image will use extlinux as a boot loader. bootsize is not recommended when using extlinux --- use grub instead.
NOTE:
VMs using ext4 may not boot when using extlinux - unless the build is performed on Jessie. Builds using ext2 and ext3 work normally.
IMPORTANT:
Version 1.6 of vmdebootstrap adds a warning but allows the build to proceed (to allow for the bug to be fixed). Sadly, downgrading the version of extlinux to the version in Jessie does not fix the problem when building on stretch or sid. Hence, vmdebootstrap can only output a warning.
SEE ALSO:
Grub2 in wheezy can fail to install in the VM, at which point vmdebootstrap will fall back to extlinux. It may still be possible to complete the installation of grub2 after booting the VM as the problem may be related to the need to use loopback devices during the grub-install operation. Details of the error will appear in the vmdebootstrap log file, if enabled with the --log option.
NOTE:
vmdebootstrap also supports EFI. See UEFI.
Use --use-uefi to use grub-efi instead of grub-pc. If the default 5MB is not enough space, use the --esp-size option to specify a different size for the EFI partition. Registered firmware is not supported as it would need to be done after boot. If the system you are creating is for more than just a VM or live image, you will likely need a larger ESP, up to 500MB.
UEFI support requires Grub and vmdebootstrap contains a configuration table of the UEFI components required for supported architectures.
There are issues with running UEFI with QEMU on some architectures and a customisation script is available for amd64:
# vmdebootstrap --verbose --image jessie-uefi.img --grub --use-uefi \
--customize ./examples/qemu-efi-bochs-drm.sh
vmdebootstrap supports UEFI for images and for squashfs but the necessary behaviour is different. With an image, an ESP vfat partition is created. With squashfs, the EFI files will be copied into an efi/ directory in the squashfs output directory instead.
There is EFI firmware available to use with QEMU when testing images built using the UEFI support, but this software is in Debian non-free due to patent concerns. If you choose to install ovmf to test UEFI builds, a secondary change is also needed to symlink the provided OVMF.fd to the file required by QEMU: bios-256k.bin and then tell QEMU about the location of this file with the -L option:
$ qemu-system-x86_64 -L /usr/share/ovmf/ -machine accel=kvm \
-m 4096 -smp 2 -drive format=raw,file=test.img
To test the image, also consider using the qemu-wrapper.sh:
$ /usr/share/vmdebootstrap/qemu-wrapper.sh jessie-uefi.img amd64 /usr/share/ovmf/
UBoot needs manual configuration via the customisation hook scripts, typically support requires adding u-boot using --package and then copying or manipulating the relevant u-boot files in the customisation script. Examples are included for beaglebone-black.
Some u-boot examples recommend the use of the lba flag on the boot partition, so use the --bootflag option where relevant.
:file:vmdebootstrap 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 or directory, 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.
The beagleboneblack.sh script in the examples/ directory provides a worked example to create a prebuilt installation image. However, the beagleboneblack itself does not support virtualisation in hardware, so is unable to launch a virtual machine. Other devices, like the Cubietruck or Wandboard need u-boot at a predefined offset but can launch a virtual machine using qemu, so the cubietruck and wandboard6q scripts in the examples/ directory relate to building images for virtual machines once the device is already installed and booted into a suitable kernel.
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. To do this, use the --tarball option instead of the --image option. Then setup the physical media and bootloader image manually, 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. 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 create an image for the stable release of Debian:
sudo vmdebootstrap --image test.img --size 1G \
--log test.log --log-level debug --verbose \
--mirror http://mirror.lan/debian/
To run the test image, make sure it is writeable. Use the --owner option to set mode 0644 for the specified user or use chmod manually:
sudo chmod a+w ./test.img
If --log is also used, consider using --log-mode as well so that the logfile is readable by the owner. By default, the log file permissions are 0o600. The logfile itself will be owned by root.
Execute using qemu, e.g. on amd64 using qemu-system-x86_64:
qemu-system-x86_64 -drive format=raw,file=./test.img
(This loads the image in a new window.) Note the use of -drive file=<img>,format=raw which is needed for newer versions of QEMU.
There is a bin/qemu-wrapper.sh <image> <arch> script for simple calls where the --owner option is used, e.g.:
$ /usr/share/vmdebootstrap/qemu-wrapper.sh jessie.img amd64
There is EFI firmware available to use with QEMU when testing images built using the UEFI support, but this software is in Debian non-free due to patent concerns. If you choose to install ovmf to test UEFI builds, a secondary change is also needed to symlink the provided OVMF.fd to the file required by QEMU: bios-256k.bin and then tell QEMU about the location of this file with the -L option:
$ qemu-system-x86_64 -L /usr/share/ovmf/ -machine accel=kvm \
-m 4096 -smp 2 -drive format=raw,file=test.img
To use the -nographic option, ensure that the --serial-console option is supplied to vmdebootstrap and use -monitor none when booting the image with QEMU.
For further examples, including u-boot support for beaglebone-black, see /usr/share/vmdebootstrap/examples
If you get problems with the bootstrap process, run a similar bootstrap call directly and chroot into the directory to investigate the failure. The actual debootstrap call is part of the vmdebootstrap logfile. The debootstrap logfile, if any, will be copied into your current working directory on error.
debootstrap will download all the apt archive files into the apt cache and does not remove them before starting the configuration of the packages. This can mean that debootstrap can fail due to a lack of space on the device if the VM size is small. vmdebootstrap cleans up the apt cache once debootstrap has finished but this doesn't help if the package unpack or configuration steps use up all of the space in the meantime. Avoid this problem by specifying a larger size for the image.
CAUTION:
It is advisable to change the mirror in the example scripts to a mirror closer to your location, particularly if you need to do repeated builds. Use the --apt-mirror option to specify the apt mirror to be used inside the image, after boot.
There are two types of examples for ARM devices 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.
If the host device has a limited amount of RAM or simply to use a different TMP directory when preparing the filesystems, set the TMPDIR or TEMP or TMP environment variables, in line with the underlying support in the python tempfile module.
vmdebootstrap uses yarn for the test suite, available in the cmdtest package. YARN is a scenario testing tool. Scenarios are written in mostly human readable language, however, they are not free form text. For more information on YARN see the homepage:
$ sudo apt -y install cmdtest
All commits must pass at least the fast tests. All merges into master need to pass a full test. All additions of new functionality must add fast and build tests --- fast tests for any new options and build tests which exercise the new functionality. Build tests can add checks for particular support on the machine running the test and skip if not found or add new environment settings to selectively run some build tests instead of all.
If no arguments are given, the full test suite will be executed:
$ yarns/run-tests
WARNING:
When limiting the run to specific tests, each --env option needs to be specified separately:
$ sudo yarns/run-tests --env TESTS=build --env MIRROR=http://mirror/debian
To run a single test, use the --run option to specify the name of the scenario (option can be repeated).
All vmdebootstrap developers need to run the fast tests as a pre-commit hook --- any patches which fail this test will be rejected:
$ ln -s ../../pre-commit.sh .git/hooks/pre-commit
The pre-commit hook just runs the fast tests which do not require sudo.
The fast checks validate the handling of incompatible option arguments:
$ yarns/run-tests --env TESTS=fast
Fast tests typically take a few seconds to run.
The slow / build tests build multiple images and use sudo --- a local mirror is strongly recommended.
$ sudo yarns/run-tests --env TESTS=build --env MIRROR=http://mirror/debian
If MIRROR is not specified, a default mirror of http://httpredir.debian.org/debian/ will be used.
There is an example lava-submit.py script which can be edited to automatically submit QEMU tests to a specified LAVA instance. The images themselves will use local file:// URLs and therefore the lava-dispatcher needs to be installed locally. Configuring LAVA for these tests is a separate topic --- please ask on the vmdebootstrap mailing list.
Neil Williams
2019, Neil Williams
| March 31, 2019 | 1.11 |