Current setup is needlessly non-generic, stateful, while paradoxically also overcomplicated

[WizardUli]

I apologize for sounding harsh but since this is under nix-community owner on Github, it may be the first thing newcomers find when trying to build RPi images. Here are some issues (relevant at least when not using uboot):

• The whole firmware/kernel/config migration process is very unnecessary hack for a problem which does not exists. Correct and simple way is to use system.build.installBootLoader.
  • Good example is https://github.com/NixOS/nixpkgs/tree/20fd6eb0111ac6fd666c7d206574575e5dccdb3f/nixos/modules/system/boot/loader/systemd-boot That is a relatively nice piece of code.
  • Note that config.txt DOES support multiple boot entries (with distinct settings, kernel, initramfs) but they are switched using configured pins (I think there are other additional mechanisms) in contrast to GUI boot screen (Many RPi installations do not have a screen anyway). (Just a note: config.txt also supports including other files which may be handy in general.).
  • Old NIxOS also used system.build.installBootLoader albeit with only one boot entry.
• There is no need to hard-code any part of disk setup at all.
• Optional autoresize on the first boot is the only thing that needs to be stateful.
• The whole sd-image is a mess and the fact that it comes from nixpkgs does not make it correct or good. It makes it sad.
  • It does NOT need to be stateful at all doing anything at the first boot except the optional resizing which could be moved to a systemd service and flag files (like the current migration).
  • It can be replaced with just nixos-install executed in QEMU. Which is of course slow so for example I run only some finishing touches under emulation (when on x86_64). See https://codeberg.org/Uli/nixsauce/src/commit/747a3eec343896a7a60a843f9f161427e7b0a884/lib/rpi-image

Here is my own setup https://codeberg.org/Uli/nixsauce/src/commit/747a3eec343896a7a60a843f9f161427e7b0a884/nixos-configurations/rpi if you want a proof of concept:

• I use ephemeral / which could be easily transformed to truly RO image. But the disk setup can be easily changed to anything.
• Image building is done as described above.
• I do not use multiple boot entries yet or config.txt generation from attrset.
• There are tons of non-generic parts but they are clearly identifiable. I'm providing this just as a proof of concept that it all can be done much simpler at least in my personal opinion.

That was a piece of my acquired knowledge, do what you wish with it.