Running a Devuan VM inside incus - is it possible without system d?

Incus
1

Hi, I’m new to lxc and incus. I installed incus on debian bookworm and also the incus web ui - and it works great; Great project! During installation I chose incus to have a managed bridge from the dedicated servers enps0f0 to the eth0 bridge provided by incus.
I purchased an additional ipv4 (172.x.x.x )(necessary) from the server provider, created a virtual machine on debian bookworm, instlled ssh, etc, and setup a network forward from the ipv4 to the ipv4 that incus chose to assign to the VM (10.x.x.x). Now I can ssh in to the vm.

I need to install a hosting system which requires an ipv4 and which installs via a bash/shell script which reboots the vm many times as it moves the VM to devuan daedalus (thus removing systemd in the process) - and the script fails at some point leaving no openssh-server operational on the vm, so I can no longer ssh in to manage it.

My questions are:

  1. can an incus vm run without systemd ? (it seems like incus-agent needs systemd to run, and the vm needs incus-agent to run properly and to be managed.). If this is the problem would you suggest this fix:
    incus-init-scripts/etc/init.d/incus-containers at main · MoltenArmor/incus-init-scripts · GitHub

  2. the script which I am trying to get working on the vm normally requires /etc/network/interfaces to have eth0 set for ipv4 (inet). On the vm there is no /etc/network/, no /etc/netplan/ etc … so, is there a way to “spoof” this required “eth0” for networking? (It seems as if the incus bridge is on eth0!). If I created a /etc/network/interfaces file on the vm and put eth0 inet static ,etc. - would that conflict with what incus is doing, or would that be OK?

Here are the results of those commands run on the main dedicated server on which I installed incus (not on the vm):

root@server1:~# netstat -lnp | grep 67
udp 0 0 0.0.0.0:67 0.0.0.0:* 8680/dnsmasq
unix 2 [ ACC ] STREAM LISTENING 19635 1676/python3 /var/run/fail2ban/fail2ban.sock
unix 2 [ ACC ] STREAM LISTENING 20742 2676/[lxc monitor] @/var/lib/incus/containers/container1/command
root@server1:~# netstat -lnp | grep 53
tcp 0 0 10.37.153.1:53 0.0.0.0:* LISTEN 8680/dnsmasq
tcp6 0 0 fe80::216:3eff:fe96::53 :::* LISTEN 8680/dnsmasq
tcp6 0 0 fd42:ec31:3b10:7918::53 :::* LISTEN 8680/dnsmasq
udp 0 0 10.37.153.1:53 0.0.0.0:* 8680/dnsmasq
udp 0 0 main.server.ip-v4:123 0.0.0.0:* 1706/ntpd
udp 0 0 10.37.153.1:123 0.0.0.0:* 1706/ntpd
udp6 0 0 fd42:ec31:3b10:7918::53 :::* 8680/dnsmasq
udp6 0 0 fe80::216:3eff:fe96::53 :::* 8680/dnsmasq
root@server1:~#

Are there any obvious problems here? Thanks for your help/advice.

“incus config show” on the dedicated running the master incus returns:
root@server1:~# incus config show
config:
acme.agree_tos: “true”
acme.email: server1@example.com
core.https_address: ‘[::]:8443’

When try to use the Incus Web UI terminal for the VM when the VM fails to allow reconnection in ssh, I get this error: Error

The connection was closed abnormally, e.g., without sending or receiving a Close control frame

Best,
Ed

2

Our default images indeed use systemd to start the incus-agent, at least on most distros.
We do also set it up on at least OpenRC for some other distros, so it’s definitely possible to have it start from another init system, but you’ll need to write the suitable init script.

For networking, it’s likely a similar story. I suspect the Debian images use a config file in /etc/systemd/network/ to have networkd bring up the network. As you’re removing networkd, you’ll need to install an alternative like ifupdown and move the configuration to an equivalent configuration.

In general, you should make sure to set a root password before doing any of that so you can use incus console --type=vga to access the VM and configure things through that until you get the agent back up and running.