The Venusian: run Venus OS on top of Debian Stable (any architecture!)

The Venusian is an installer script that runs on any Debian Stable (“Trixie”) system. The only restriction is that the host architecture can not be “armhf”, thus the minimum requirement is a Raspberry Pi 3 with 64-bit userspace. But any old laptop or NAS server works.

The script downloads and unpacks the Venus 3.71 image, sets up a Venus user, and creates user-level systemd units that run the Venus services. You start the whole thing with systemctl start venusian@venus. If you need to, you stop it the same way. No reboot required.

You can even run more than one separate Venus installation on the same host system.

I’m using The Venusian in production. There still are a few rough edges in the UI (V2), but the system basically works.

You can get it from GitHub - M-o-a-T/venusian: Victron Energy's "venus" – on top of Debian · GitHub .

Some internals:

  • No svc. No /service directory. We use systemd --user.
  • No hogging the system DBus. We use a per-user session bus.
  • No logging to /var/volatile. We use the systemd journal.
  • No modification of the Venus image. We use overlays.
  • No probing of connected serial devices. We use a script that monitors dbus, and a config file.
  • The Venusian includes the twe-meters library, and a lightly-modified copy of dbus-serialbattery.
  • flashmq and its dbus plugin run natively.
  • Victron’s armhf binaries are emulated with qemu (except on arm64, where they run natively).
  • Venus’ Python scripts use the system’s Python installation. No virtual environment required.
  • Each Venus setup gets a separate IP address alongside the machine’s “real” address (if you want). No change to your network setup or routing changes required (as long as you don’t rely on WLAN).

Some bits and pieces which I don’t have hardware for and thus can’t test might not work (yet).
Patches gladly accepted.

2 Likes

Interesting choice of a name. You are aware Devuan is the attempt to remove systemd?

Yes I know what Devuan is about; I’m intentionally doing the exact opposite here.

I want combined logging which I can easily forward to a remote server with a disk and a persistent log. I want services to explicitly depend on each other instead of doing a crash-and-retry dance. I want actual events that I can monitor, if/when a service dies. And last-but-not-least I want a service that can be cleanly stopped and restarted, no matter which shenanigans with double-forking and whatnot it did under the hood while it was running.

Systemd gives me all of that, and more, out of the box.

Hi,

I been trying to make a go at this here on deb 13. I hit some hiccups in the installer but kind of got through those. However I still have problems with after signing into the web app stall out etc. So I am looking forward to getting that going eventually. I will probably need some help tho.

No problem, I’ll help.
I’ve set up a Discussions space on Github which is probably more suitable than getting into details here. Please share details (which hiccups? what exactly did you do?).

Ok great I will try to rerun through that over there in a bit. I need to spin up another deb vm since started putting battery monitors etc on this one and running some tests here. ;D