68 pointsby leetrout3 days ago7 comments
  • jauntywundrkind3 days ago
    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-...

  • NewJazz3 days ago
    I've been meaning to try this other tool

    https://github.com/osbuild/bootc-image-builder

    • jordemort3 days ago
      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.
  • deanputney3 days ago
    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?
    • written-beyond2 days ago
      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.

    • thebruce87m2 days ago
      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.

    • sl-13 days ago
      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:

    • klysm3 days ago
      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.
      • ChocolateGod2 days ago
        If you install a UEFI bootloader on the Pi, I don't see why it couldn't work.
  • miladyincontrol3 days ago
    Yeah, systemd's particleOS relies on it. Pretty neat stuff
  • klysm3 days ago
    I really wish this worked for raspberry pi
  • mring336213 days ago
    What's the use-case for this?
    • af783 days ago
      It is used by the systemd team to test systemd on a bunch of distros.

      https://github.com/systemd/systemd/blob/main/.github/workflo...

    • mhitza3 days ago
      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).
    • its-summertime3 days ago
      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).
  • pmarreck3 days ago
    is this another case of "something that nix already definitively solves, but for the rest of us"?
    • bsammon3 days ago
      Or "something that nix already solve, but with documentation"
      • bketelsen3 days ago
        Normally I'd nod and smile at the nix documentation joke, but mkosi's documentation is the man pages, or the man pages.
        • jraph3 days ago
          It seems quite well written and easy to follow.