Charlz' Realm

How to Build an Incus Buster Image

Thu, 09 Oct 2025 00:01:09 -0300

It’s always nice to have container images of Debian releases to test things, run applications or explore a bit without polluting your host machine. From some Brazilian friends (you know who you are ;-), I’ve learned the best way to debug a problem or test a fix is spinning up an incus container, getting to it and finding the minimum reproducer. So the combination incus + Debian is something that I’m very used to, but the problem is there are no images for Debian ELTS and testing security fixes to see if they actually fix the vulnerability and don’t break anything else is very important.

Well, the regular images don’t materialize out of thin air, right? So we can learn how they are made and try to generate ELTS images in the same way - shouldn’t be that difficult, right? Well, kinda ;-)

The images available by default in incus come from images.linuxcontainers.org and are built by Jenkins using distrobuilder. If you follow the links, you will find the repository containing the yaml image definitions used by distrobuilder at github.com/lxc/lxc-ci. With a bit of investigation work, a fork, an incus VM with distrobuilder installed and some magic (also called trial and error) I was able to build a buster image! Whooray, but VM and stretch images are still work in progress.

Anyway, I wanted to share how you can build your images and document this process so I don’t forget, so here we are…

Building Instructions

We will use an incus trixie VM to perform the build so we don’t clutter our own machine.

incus launch images:debian/trixie <instance-name> --vm

Then let’s hop into the machine and install the dependencies.

incus shell <instance-name>

And…

apt install git distrobuilder

Let’s clone the repository with the yaml definition to build a buster container.

git clone --branch support-debian-buster https://github.com/charles2910/lxc-ci.git
# and cd into it
cd lxc-ci

Then all we need is to pass the correct arguments to distrobuilder so it can build the image. It can output the image in the current directory or in a pre-defined place, so let’s create an easy place for the images.

mkdir -p /tmp/images/buster/container
# and perform the build
distrobuilder build-incus images/debian.yaml /tmp/images/buster/container/ \
            -o image.architecture=amd64 \
            -o image.release=buster \
            -o image.variant=default  \
            -o source.url="http://archive.debian.org/debian"

It requires a build definition written in yaml format to perform the build. If you are curious, check the images/ subdir.

If all worked correctly, you should have two files in your pre-defined target directory. In our case, /tmp/images/buster/container/ contains:

incus.tar.xz  rootfs.squashfs

Let’s copy it to our host so we can add the image to our incus server.

incus file pull <instance-name>/tmp/images/buster/container/incus.tar.xz .
incus file pull <instance-name>/tmp/images/buster/container/rootfs.squashfs .
# and import it as debian/10
incus image import incus.tar.xz rootfs.squashfs --alias debian/10

If we are lucky, we can run our Debian buster container now!

incus launch local:debian/10 <debian-buster-instance>
incus shell <debian-buster-instance>

Well, now all that is left is to install Freexian’s ELTS package repository and update the image to get a lot of CVE fixes.

apt install --assume-yes wget
wget https://deb.freexian.com/extended-lts/archive-key.gpg -O /etc/apt/trusted.gpg.d/freexian-archive-extended-lts.gpg
cat <<EOF >/etc/apt/sources.list.d/extended-lts.list
deb http://deb.freexian.com/extended-lts buster-lts main contrib non-free
EOF
apt update
apt --assume-yes upgrade

Making KGB less noisy

Mon, 01 Sep 2025 21:18:09 -0300

This past month I did setup KGB to send notifications to #debian-lts when new merge requests were created in the LTS website’s repo and I learned a couple cool things. I’ve been trying to document things more so I don’t have to research the same topic months later, hence the blog seemed like a good idea, specially since many debianites have KGB set on their favorite IRC channel and this post will go to planet.debian.org.

Selecting What Goes to IRC

Salsa (Debian’s GitLab instance) can generate a lot of events for things that happen on a repository and a lot of them can be pushed to KGB via webhooks. Generally I prefer a minimal set enabled otherwise it’s too much clutter on the IRC side, but it’s important to go through each option to see what makes sense or not. From the experience I had, the following ones are the most useful to have it on:

Push events
Tag push events
Comments
Issue events
Merge request events
Pipeline events

Reducing the Noise

For Debian packaging, one may find it useful to add a pattern filter so only the packaging branch updates go to IRC. If you are using DEP-14, that’s pretty easy, “debian/*” will do the job.

Notably, “Job events” are left out. Basically it’s just too much info, you get one alert when a job is scheduled, then when it’s started and another one when it’s completed. Well, each pipeline has at least a few of them, multiply by three and you can understand my point.

Besides that, pipelines also generate the same amount of events as jobs, so it might be a problem too. Well, KGB comes to the rescue. It allows you to filter pipeline events, because you really only care about the pipeline when it fails ;-) To do just that, pipeline_only_status=failed.

Another interesting option is limiting the commits shown when the push event has too many of them. One can do that with squash_threshold=3. Remember I want less clutter?! Three commits is my limit here.

Final Result

The final URL for me looks like this (newlines added for clarity):

http://kgb.debian.net:9418/webhook/?channel=debian-<your_preferred_channel>&
                                    network=oftc&
                                    private=1&
                                    use_color=1&
                                    use_irc_notices=1&
                                    squash_threshold=3&
                                    pipeline_only_status=failed

You can see there are more options than the ones I described earlier, well, now it’s your time to go through KGB’s documentation and learn a thing or two ;-)

Hello World

Sun, 01 Dec 2024 23:18:09 -0300

Or how it took more than a year for me to set up this website -

As the computer science tradition demands, we must start with a Hello World.

Though I have to say this hello world took quite a long time to reach the internet. I’ve been thinking about setting up this website for way over a year, but there are always too many things to decide - what Static Site Generator will I use? Where should I get a domain from? Which registrar would be better now? What if I want to set up a mail server, is it good enough? Oh, and what about the theme, which one to choose? Can I get one simple enough to not fetch javascript or css from external sources?

This was taking so long that even my friends were saying “Please, just share your screen and let’s do it now!”. Well, rejoice friends, now it’s done!