I work in the embedded space. I'd absolutely love to have a tool to build immutable, signed distro images which I can push to devices with a/b style updates. I imagine you can do this with mkosi, but it doesn't quite feel like the intended use case.
Most immutable distros (this included) are developed with the idea that you'd run local commands on the machine, and update a single OS image in place. That gets pretty unwieldy to manage across a fleet of devices.
Right now the industry standard tooling for building truly immutable images for embedded devices is Yocto. It works well, but it's incredibly complicated and has ridiculous build times because it insists on building every single package from source. It's utter madness that building a Linux image for a common ARM64 processor requires me to compile the Rust compiler myself.
You don't have to build ParticleOS images on the machine itself, it's perfectly possible to build them offline somewhere else and download them from the target machine when doing an update with systemd-sysupdate. It's just that we haven't quite gotten to ironing out all the details there. We're adding support to OBS (OpenSUSE Build System) to build ParticleOS images and will eventually start publishing prebuilt images there which can then be consumed by systemd-sysupdate.
For the embedded space you'd just build the ParticleOS images on your own build system, publish them somewhere and consume them with systemd-sysupdate, doesn't have to be OBS of course.
But we don't do stuff like only downloading diffs with systemd-sysupdate and such yet, so your milleage may vary.
Hey there,
I'm attempting to make a particleos VM, and have run into a few different issues. I now know more than I ever known about mkosi, and have gotten that working. My issue following the directions on github is after mkosi -B -f I get Unknown setting Profiles. Is there a Discord where I can ask a group or such. I would love to test this out. Thanks
That's interesting. I've been looking for an angle on embedded Linux software updates for my deployment tool (currently limited to updating desktop and server apps only).
When you say push, do you literally mean push or do you mean the devices would still pull updates on their own schedule where you get to control rollout percentages, channels, etc centrally? Mostly devices have to be assumed to be behind NAT, right?
What I'm thinking here is maybe it'd be useful to have a mode in Conveyor [1] that builds a standalone ARM Linux that can boot and pull updates for everything including the app, but which coordinates with the userspace app to decide when it's time to restart and for which the build to update to is controlled by server-supplied metadata so you can divide the fleet by tag, etc.
The problem with immutable images is you need a complimentary config management tool to manage them at scale. That's why we built Etcha[0] (config management for 1000+ devices) and then built an immutable OS (EtchaOS) around it--they're meant to work together instead of "cloud-init is good enough". cloud-init is terrible at scale, especially outside of public cloud.
We at darkscience used buildroot for a simple ZNC SBC[0] distribution which we deployed to an Orange Pi Zero that we sold at 33C3[1].
It was great! I highly recommend!
It didn't take long to get started and while the compile times were pretty large (wonder if NIX or Bazel could help here?) it ended up with absolutely microscopic resource requirements.
I've had a reasonable amount of luck with a combination of Buildroot and Bazel. I use Buildroot to assemble a minimal Base OS with just the kernel, bootloader and a few system services. Then the application layer is built with Bazel and assembled into a set of squashfs images which are mounted as overlay filesystems at boot time. The whole thing is shipped as a SWUpdate file built with the Bazel layer.
Because most of the iteration is happening in the Bazel layers I can generate a full system update in about 15 seconds with everything being fully reproducible.
> Most immutable distros (this included) are developed with the idea that you'd run local commands on the machine, and update a single OS image in place. That gets pretty unwieldy to manage across a fleet of devices.
This is how it always has been on enterprise network devices like switches, routers, etc. It’s pretty trivial to automate updates.
Most immutable distros (this included) are developed with the idea that you'd run local commands on the machine, and update a single OS image in place. That gets pretty unwieldy to manage across a fleet of devices.
Right now the industry standard tooling for building truly immutable images for embedded devices is Yocto. It works well, but it's incredibly complicated and has ridiculous build times because it insists on building every single package from source. It's utter madness that building a Linux image for a common ARM64 processor requires me to compile the Rust compiler myself.