Does seem to support cross-architecture image building, which is a feature that's kept me on Debian's multistrap and now mmdebstrap.
I should give this a go!
The README's reference page has some good write-ups et cetera! There's a good "re-introduction" on Lennart (creator of systemd, mkosi) site, from the current maintainer.
I've been having great success with this one at my day job. Being able to apply all the container workflows to VM images has been a boon.
Does this work for Raspberry Pi? Say for example I wanted to make an image that would auto-connect to my Tailscale network, or pre-install some software, would this be able to achieve that?
Use RPIOS [pi-gen](https://github.com/RPi-Distro/pi-gen), it's pretty versatile and stupid simple, I could not wrap my head around Yocto and Buildroot. Even set it up in CI so GitHub would build the image and id just get the final tar.gz file as an artifact.
It's all just bash scripts and you can basically strip the entire image down. I had no window manager and no display server I was using DRM to show my UI.
I use [pi-oven](https://github.com/keichi/pi-oven) for my raspberry images. Not perfect, but kind of works and removes a lot of hassle for the provisioning.
Could not quickly find out from the project page an example on how to bake rpi images with mkosi, but the descriptions do point towards somewhat similar use case :shrug:
Balena could do that for you. You make a usb stick for a fleet and anything flashed with the stick joins the fleet and downloads the latest release.
The releases are dockers via docker compose. You can manage all devices via a web interface too.
I've checked on this several times over the years, and I think the answer will probably be no for a long time, or forever. The RPi boot process is a bit arcane and specific. Systemd's philosophy seems to want to target the 95% use case, but maybe the sheer size of the RPi sphere will provide enough pressure.
If you install a UEFI bootloader on the Pi, I don't see why it couldn't work.
Yeah, systemd's particleOS relies on it. Pretty neat stuff
I really wish this worked for raspberry pi
What's the use-case for this?
It is used by the systemd team to test systemd on a bunch of distros.
Most likely context I'm going to try it is in a systemd-nspawn context. Lightweight process namespace ("containers") closer to the native modern linux server runtime (systemd all the way).
one image to deploy mostly without additional tooling on any systemd-based OS (which mounts the image and integrates the units from it), on a VM (just use it), or on bare metal (probably needs to be built on a full image but still can just use it assuming that is the case).
is this another case of "something that nix already definitively solves, but for the rest of us"?
Or "something that nix already solve, but with documentation"
Normally I'd nod and smile at the nix documentation joke, but mkosi's documentation is the man pages, or the man pages.
Does seem to support cross-architecture image building, which is a feature that's kept me on Debian's multistrap and now mmdebstrap.
I should give this a go!
The README's reference page has some good write-ups et cetera! There's a good "re-introduction" on Lennart (creator of systemd, mkosi) site, from the current maintainer.
https://github.com/systemd/mkosi?tab=readme-ov-file#referenc... https://0pointer.net/blog/a-re-introduction-to-mkosi-a-tool-...
I've been meaning to try this other tool
https://github.com/osbuild/bootc-image-builder
I've been having great success with this one at my day job. Being able to apply all the container workflows to VM images has been a boon.
Does this work for Raspberry Pi? Say for example I wanted to make an image that would auto-connect to my Tailscale network, or pre-install some software, would this be able to achieve that?
Use RPIOS [pi-gen](https://github.com/RPi-Distro/pi-gen), it's pretty versatile and stupid simple, I could not wrap my head around Yocto and Buildroot. Even set it up in CI so GitHub would build the image and id just get the final tar.gz file as an artifact.
It's all just bash scripts and you can basically strip the entire image down. I had no window manager and no display server I was using DRM to show my UI.
I use [pi-oven](https://github.com/keichi/pi-oven) for my raspberry images. Not perfect, but kind of works and removes a lot of hassle for the provisioning.
Could not quickly find out from the project page an example on how to bake rpi images with mkosi, but the descriptions do point towards somewhat similar use case :shrug:
Balena could do that for you. You make a usb stick for a fleet and anything flashed with the stick joins the fleet and downloads the latest release.
The releases are dockers via docker compose. You can manage all devices via a web interface too.
I've checked on this several times over the years, and I think the answer will probably be no for a long time, or forever. The RPi boot process is a bit arcane and specific. Systemd's philosophy seems to want to target the 95% use case, but maybe the sheer size of the RPi sphere will provide enough pressure.
If you install a UEFI bootloader on the Pi, I don't see why it couldn't work.
Yeah, systemd's particleOS relies on it. Pretty neat stuff
I really wish this worked for raspberry pi
What's the use-case for this?
It is used by the systemd team to test systemd on a bunch of distros.
https://github.com/systemd/systemd/blob/main/.github/workflo...
Most likely context I'm going to try it is in a systemd-nspawn context. Lightweight process namespace ("containers") closer to the native modern linux server runtime (systemd all the way).
one image to deploy mostly without additional tooling on any systemd-based OS (which mounts the image and integrates the units from it), on a VM (just use it), or on bare metal (probably needs to be built on a full image but still can just use it assuming that is the case).
is this another case of "something that nix already definitively solves, but for the rest of us"?
Or "something that nix already solve, but with documentation"
Normally I'd nod and smile at the nix documentation joke, but mkosi's documentation is the man pages, or the man pages.
It seems quite well written and easy to follow.