You can delete the old-hda.qcow once you’ve checked that the new qcow2 file works.)
Don’t try it while the VM is running! You then need to update your QEMU command line to say “format=qcow2” rather than “format=qcow”. If you created a qcow image by mistake, you can convert it to qcow2 with mv hda.qcow2 old-hda.qcow & qemu-img convert -O qcow2 old-hda.qcow hda.qcow2. (Oops - an earlier version of this blogpost created a “qcow” format image, which will work but is less efficient. I picked a 5GB disk but you can make it larger if you like.
QEMU’s “virt” board automatically creates a device tree internally and passes it to the kernel, so we don’t need to provide one.) Installingįirst we need to create an empty disk drive to install onto. (If we were installing on real hardware we would also need a “device tree” file to tell the kernel the details of the exact hardware it’s running on. Saving them locally as installer-vmlinuz and installer-initrd.gz means they won’t be confused with the final kernel and initrd that the installation process produces. To install on QEMU we will want the multiplatform “armmp” kernel and initrd from the Debian website: I suggest creating a subdirectory for these and the other files we’re going to create. I also use libguestfs to extract files from a QEMU disk image, but you could use a different tool for that step if you prefer. I’m going to assume you have a Linux host, and a recent version of QEMU (at least QEMU 2.6). Because we’re installing a full distribution rather than a cut-down embedded environment, any development tools you need inside the VM will be easy to install later. Why Debian?ĭebian has had good support for ARM for a long time, and with the Debian Jessie release it has a “multiplatform” kernel, so there’s no need to build a custom kernel. The only thing it doesn’t have out of the box is graphics, but graphical programs on a fully emulated system run very slowly anyway so are best avoided. This is a purely virtual platform designed for use in virtual machines, and it supports PCI, virtio, a recent ARM CPU and large amounts of RAM. My recommendation is that if you don’t know for certain that you want a model of a specific device, you should choose the “virt” board. Many of QEMU’s models are annoyingly limited because the real hardware was also limited - there’s no PCI bus on most mobile devices, after all, and a fifteen year old development board wouldn’t have had a gigabyte of RAM on it. A kernel which is expecting to run on one system will likely not run on another. This wild profusion reflects a similar diversity in the real hardware world: ARM systems come in many different flavours with very different hardware components and capabilities. QEMU has models of nearly 50 different ARM boards, which makes it difficult for new users to pick one which is right for their purposes. Update : I have now written that post about installing a 64-bit ARM guest. (I may do a followup post for 64-bit ARM later.)
There are a lot of older tutorials out there which suggest using boards like “versatilepb” or “vexpress-a9”, but these days “virt” is a far better choice for most people, so some documentation of how to use it seems overdue. In this post I’m going to describe how to set up Debian on QEMU emulating a 32-bit ARM “virt” board.