Proposal: use make-disk-image.nix instead of sd-image.nix

[rcambrj]

I would like to propose a change regarding the image creation process.

TLDR: what do you think about switching from sd-image.nix to make-disk-image.nix?

Currently, this repository uses a variant of sd-image.nix. While this approach works well for generating images which boot on real hardware, I believe there’s an opportunity to better align with the NixOS testing infrastructure.

The NixOS testing framework uses qemu-vm.nix, which depends on make-disk-image.nix which is designed for generating disk images for use in virtualized environments like QEMU, it also happens to do quite well at making disk images which boot on physical x86_64 hardware. Unfortunately make-disk-image.nix lacks the same options that sd-image.nix provides for installing the necessary files to boot on a Raspberry Pi.

I made a module rcambrj/nix-pi-loader which shows that make-disk-image.nix can make something which boots on Raspberry Pis 3 and 4. It implements a variant copy of boot.loader.generic-extlinux-compatible where the system.build.installBootLoader functionality is expanded to permit specifying those extra files needed for booting a Raspberry Pi. I must admit, I did the bulk of this work before discovering the nix-community/raspberry-pi-nix repository, so I used nixpkgs' sd-image.nix as my main inspiration. It currently supports Raspberry Pi 3 & 4 only.

My proposal is to modify nix-community/raspberry-pi-nix to use make-disk-image.nix for image creation. As this module does considerably more than my waste of time proof of concept mentioned above, aside from using a modified boot.loader.generic-extlinux-compatible, it may also be necessary to make modifications to make-disk-image.nix to support mounting the boot partition in the right place (/boot/firmware instead of /boot), although I'm not yet sure whether this is necessary during the image creation phase.

The README in this repository's root suggests that there is some CI-testing already happening against the example, but I couldn't find anything in the source code which directed me to it (#85). Regardless, this proposal would be a step towards making automated validation of Raspberry Pi images (including bootloader, not using direct boot) more accessible to the public - ideally using one of QEMU's machine profiles, although I believe that qemu-vm.nix would also require some modifications to support selecting these machine profiles.

I don't see a reason why these modifications can't be made in a way where they can be eventually upstreamed, improving the wider ecosystem in the long term.

I would greatly appreciate feedback, suggestions and criticism from the maintainers of this repository on this proposal. To be clear, I'm not asking for you to work on this, but rather seeking either approvals or any reasons why I shouldn't sink some time into this myself.

Thanks for taking the time to read my wall of text.

[tstat]

Hey @rcambrj! I would love to move in this direction, so I'm excited to collaborate on this.

Some useful context: this repository was created as I attempted to get nixos raspberry pi builds that "just work". I have no motivation to do this other than I think it's a fun way to spend some of my spare time. In my efforts to accomplish this, I repeatedly ran into obstacles resulting from device tree differences and whatnot, which led me to the current design. So, it evolved as I learned more about the raspberry pi boot process, the linux boot process, and nixos.

In light of the above, it's no surprise that the current design isn't what I would have done if I started over. The sd image generation was just hacked together and left alone mostly. So, I'm happy to move to make-disk-image. I will likely merge #79 soon, which separates the image generation bits and allows for a normal nixos install process. I simply did not know about system.build.installBootLoader until recently, so I have been installing the boot loader in non-standard ways (activation scripts originally, and now a systemd script). So, I would like to switch to using system.build.installBootLoader.