Debian image building
First steps in building Proxmox template for Debian VM I want a Proxmox VM template so that I can spin up Debian VMs up quickly and easily. Debian offers official cloud images that seem almost perfect fit for this purpose. Unfortunately they don’t include My first attempt was to use use Next I thought I can just build the image myself from scratch. The official Debian images are built using a tool called FAI. The first problem was that FAI is not packaged for Arch Linux. So I thought I could try doing the build in podman Debian container but that proved pretty quickly to be unfeasible (needs loop devices among other stuff). Ultimately I ended up creating a Debian VM for this image building. This had bit of a chicken and egg problem because the whole point of this process is to be able to run Debian VMs. Luckily using the official images is not that big of a problem, not having guest agent or terminfo is not a hard blocker, just annoying, and can be solved by installing the missing packages manually. With Debian VM at hand I could finally make some progress. First I just wanted to reproduce the official images to verify that everything was working ok. When running the Once I had that building cleanly I could start modifying the configurations. I added One final step was to convert the built image from raw format to qcow2. It is bit weird that the makefile is does not do that by default considering that the official images are distributed as qcow2. The command I used was: Again, idk what image format Proxmox actually prefers. But at least the qcow2 is significantly smaller: sidenote: it is bit annoying that the builder creates files as root :( While testing the images I noticed that the images configure automatic root login on serial port and tty1 (see source). Not sure if I want to keep that, it is bit weird. If I’m understanding the setup correctly that configuration is supposed to be only for “dev” images (see docs: “TYPE_DEV: development configs, add tty, set grub timeout”) but I don’t think there is anything that actually builds non-dev images. To do so I patched the Makefile: As far as I can tell the official images do not use “official” build-type?? Final sidenote, I used qemu-guest-agent package in the images. They also are missing terminfo files which makes them annoying to use. So I thought I could just add them in and move on. But that was not that simple…virt-customize to add the packages. Then I discovered that virt-sysprep might be better. But no matter which one I used the image went from 322 MB to ~630 MB. That felt unacceptable to me so I started looking for alternatives.make command for some reason the system tests failed :( I quickly hacked the tests to match my results but idk what is going on here, why this happens to me and isn’t noticed on Debians side?? Patch:---
+++
@@ -59,6 +59,8 @@ class TestEtc:
'input', 'kvm', 'render', 'sgx',
# From package uuid-runtime
'uuidd',
+ # ???
+ 'clock',
):
return
if name.startswith('_') or name.startswith('systemd-'):
@@ -98,6 +100,8 @@ class TestEtc:
'tcpdump',
# From package uuid-runtime
'uuidd',
+ # ???
+ 'dhcpcd',
):
return
if name.startswith('_') or name.startswith('systemd-'):qemu-guest-agent and ncurses-term packages, and also replaced screen with tmux. While doing this I also configured apt/debootstrap to use closer mirror instead of the global deb.debian.org. I have no idea if that actually helps anything these days; seems like deb.debian.org is behind fastly cdn anyways so I guess it is pretty decent option too.qemu-img convert -f raw -O qcow2 -c -o compat=1.1,compression_type=zstd image_trixie_genericcloud_amd64.raw image_trixie_genericcloud_amd64.qcow2-rw-r--r-- 1 debian debian 307M Feb 13 19:52 image_trixie_genericcloud_amd64.qcow2
-rw-r--r-- 1 root root 3.0G Feb 13 19:51 image_trixie_genericcloud_amd64.raw---
+++
@@ -18,6 +18,7 @@ image_%:
--version $(shell date '+%Y%m%d%H%M') \
--localdebs \
--output $(DESTDIR) \
+ --build-type official \
--override-name $@
clean:virt-diff to compare images as I was building them. It was ok tool, albeit clunky and slow. I just wanted to mention it here for future reference. Overall the virt-* suite of tools seems pretty comprehensive and useful, I have to keep them in mind in future.