I have a hard time making NixOS work on my Rockpro64s. Installer ISO boots fine through TOW-boot UEFI but installed system never boots. The github projects to produce images don’t actually work for current version (something related to what’s available in hydra aparently) and even if I use the old versions as soon as I update the kernel it breaks. It simply doesn’t boot.
Meanwhile Fedora 40 installs like a champ from the default aarch64 iso with just a warning about EFI variables (which is expected since tow-boot is not really providing a complete uefi environment).
I suspect it’s probably some voodoo formula to manage the device trees. Those github flakes to generate imsges are pulling an entire root tarball from hydra so I’m assuming there is something done there that is not obvious.
If you're using random ARM boards (even well known ones), the way I've found most useful (since I seldom use them as desktops anyway) is to install a minimal Armbian (or similar, with barely anything besides the networks stack) and use LXC/LXD - https://taoofmac.com/space/blog/2024/07/18/0900
I tried systemd-nspawn which is similar but NixOS will complain about sandboxing if run from any kind of container layer. Fedora 40 works for me without any workarounds. It runs on a very recent 6.9x kernel with bcachefs and everything so at this point I’d rather just install nix on top of it.
I'm using Guix System on my rockpro64. I patched uboot to allow it to boot via SATA. (One of the patches I needed was to ignore a spurious CPU reset while enumerating SATA devices.)
Disclaimer is that nowadays I moved on from ARM (at least for non-UEFI systems), because I feel like working with the preboot environments is just not worth the hassle if you need to reliably boot remote servers.
I have a nix flake that builds an ISO for the Pi. It is a readonly system and only does network bridging between the wifi iface and the ethernet (bc. my internet acces is... difficult). It's pragmatic an probably not best-practice, but it works:
I build the sdImage using nixos-generators. I then redeploy the same configuration using `nixos-rebuild switch --target-host=`. It’s rather neat because my flake will export both, and the configuration is a module I don’t need to repeat.
Doesn’t come with FDE, but I use tmpfs for payloads.
I've been wanting to try NixOS, but I've also had great success running Alpine on my raspberry pis as a read only OS from ram. Rock solid, simple, and good package availability.
19 comments
[ 77.8 ms ] story [ 333 ms ] threadMeanwhile Fedora 40 installs like a champ from the default aarch64 iso with just a warning about EFI variables (which is expected since tow-boot is not really providing a complete uefi environment).
I suspect it’s probably some voodoo formula to manage the device trees. Those github flakes to generate imsges are pulling an entire root tarball from hydra so I’m assuming there is something done there that is not obvious.
For NixOS specific instructions, see https://juuso.dev/blogPosts/ipxe-rpi4/ipxe-nixos-edk2-uefi-b...
Disclaimer is that nowadays I moved on from ARM (at least for non-UEFI systems), because I feel like working with the preboot environments is just not worth the hassle if you need to reliably boot remote servers.
https://git.sr.ht/~tobtobxx/gatetobtob
Doesn’t come with FDE, but I use tmpfs for payloads.