Incus on OpenSuse(Tumbleweed, MicroOS)

1

I am a big fan on incus, also a fan of Suse’s MicroOS and Tumbleweed.

Although I hear much of how next version of Fedora, Debian, and Ubuntu will get incus, I hear nothing of Suse. LXD is included in Suse, so it surprises me that there was so little done about incus as of yet.

I checked the open build system, and didn’t find any working, recent Incus build, so I branched one I found, and updated it with the latest 0.5.1, added the web UI, added SELinux configuration, and added some overlooked dependencies needed for VMs to work.

This is my branch on the open build system.

I also made web UI available here.

The problem is, this is actually the first project I have attempted of this nature, and I think it is hacky, not tidy, and not done properly. I think too much is hard coded, too much is haphazard, and often I feel I don’t know what I’m doing etc. Although I made it to a stage where everything works, I’m not happy with the way I get there.

I am hoping someone could take a look at it, maybe help make it cleaner or more ‘as it should be’ in the .spec file and so on, or even branch it or take the next steps, with the ultimate goal to get it included in Suse in the very near future. At least, we can have a ‘good’ repository to use like they have on debian, fedora, etc.

But, if someone is a Suse user who really wants incus, feel free to use the RPMs built from here. I will try to at least keep it up to date.

1 Like
2

Yeah, we’ve been nagging @cyphar quite repeatedly about it but he’s been a bit busy lately :wink:

3

I’m surprised already to receive a response, and from the god himself :smile:
I rely on you for my zfs module, my kernel, and my incus setup on .deb distributions, so thank you very much for all your work.

I see, he is the one who does the suse-related matters. In this case, maybe just a matter of time. I look forward to seeing it hopefully be included soon.

4

Yeah, Aleksa is the original creator of Incus and the long time packager of LXD in OpenSUSE.

He did mention some issues with newer liblxc related to the version of meson in SUSE, this is what caused LXD to be stuck on an older version and caused some difficulty in getting Incus packaged too. Hopefully that gets resolved soon though!

5

I’m experimenting with MicroOS at the moment (seems great for a low maintenance container host) - many thanks for packaging incus.

I’ve been building a custom iso with kiwi-ng inside a privileged tumbleweed podman container. Mounting a zram device to the build directory makes builds complete in around 4 mins (& cleaning the build directory very quick) - see my notes for kpartx & how to create a build container at that link.

  • In my image I use systemd daemons & busybox applets as much as possible (so breakage should be zero even with a rolling release)

  • To use encrypted passwords in image configuration:

SALT=$(LC_ALL=C tr -dc '[:alnum:]' < /dev/urandom | head -c50)
openssl passwd -1 -salt $SALT YOUR_PASSWORD

In your build environment setup the kiwi-ng repo & install the depends:

zypper in git kiwi-systemdeps-iso-media kiwi-systemdeps-bootloaders kiwi-systemdeps-disk-images
  • Building the oem image type generates a qemu image & an iso image:
sudo kiwi-ng --profile Standard system build \
--description $DEVOPS/kiwi/build-tests/x86/tumbleweed/test-image-MicroOS \
--target-dir $DEVOPS
  • if testing images with qemu / Virtual Machine Manager - remove the iso image in the vm configuration / apply & add it back again / apply - after each build - libvirt seems to keep the old iso in memory (but possibly this is due to my use of zram)
6

This is killing me, literally :wink: any news on this ? Packages on the official repos for SLE Micro / Leap Micro ?

7

@cyphar any update?

1 Like
8

The current distribution method of the project appears to be a bottleneck. While Debian/Ubuntu repositories provided by @stgraber cater to production and enterprise use cases effectively, there’s a noticeable gap for the EL family and OpenSUSE/SUSE.

Distributions like Archlinux, Gentoo, NixOS, Void Linux, and Fedora have community-maintained packages, which are commendable efforts targeting more specialized or workstation-oriented use cases. However, these do not fully address the broader needs.

An officially supported package in EPEL could potentially encompass all use cases for the EL family. The SRPM or spec file from this effort could then be adapted for SUSE/OpenSUSE or vice-versa. Alternatively, distributing the packages under the Linux Containers project could ensure uniform building and testing processes.

This bottleneck may be impeding the wider adoption of Incus. Collaborative efforts from EL packagers to create a high-quality, packaged product could significantly reduce individual efforts.