installer: split sd cards -> base for bespoke sd images

[blaggacao]

Motivation for this change

https://discourse.nixos.org/t/sd-images-are-they-really-installation-devices/11190

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

resolved

Regardless of the future of this PR, I'd really appreciate tutoring on how to make this properly backwards compatible. I had thought of:

• putting the old files in place
• redirecting to the new files
• issue a deprecation warning

But I've no experience with backwards compatibility.

There might also be references to those files all over the place, that I would need to update as well. How to best find those? I've never proposed such a "fundamental" change.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/sd-images-are-they-really-installation-devices/11190/1

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/casual-nixpkgs-contributions/9607/10

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/sd-images-are-they-really-installation-devices/11190/9

[mohe2015]

Looks good, didn't test it though.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-deprecate-a-module-path/11247/1

[blaggacao]

@samueldr May I ask you for a review (maybe even merge)? You seem rather familiar with that portion of the code.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/40

[mohe2015]

Didn't test it but otherwise LGTM. Also seems to be backward compatible and a change I also have thought about.

Edit: Hint: Look at the commit-wise diff. Github messes up the whole PR diff.

[blaggacao]

squashed & rebased

[blaggacao]

/cc @flokli @lopsided98 @jslight90 please consider a review to help me get this merged.

[lopsided98]

This seems to make sense based on a quick look at the older version, but since you squashed the commits it is very hard to review because I can't distinguish renames from meaningful changes. I would prefer if you rebased to remove the merge commits but kept the individual commits.

[mohe2015]

@blaggacao IMHO you should undo the squash as the previous commits were semantically easy to parse and would make more sense in the git history.

[lopsided98]

git reflog?

[blaggacao]

git reflog?

Thx! Wasn't familiar with this command. Pretty useful!

[blaggacao]

As for 68afbf9 : should we leave any well-known regexable for the release manager of the next-next release?

[mohe2015]

Didn't test it but LGTM. Also seems to be backward compatible and a change I also have thought about.

Hint: Look at the commit-wise diff. Github messes up the whole PR diff.

[mohe2015]

As for 68afbf9 : should we leave any well-known regexable for the release manager of the next-next release?

I don't know.

[lopsided98]

I haven't tested this, but the possibility of breakage seem limited assuming everything evals.

One thought I had (not necessarily a suggestion for this PR) is that we might not need sd-image-aarch64-new-kernel.nix and sd-image-raspberrypi4.nix. It makes sense to provide the -installer versions so users can download them, but for building custom images they don't really offer much since they only override one option.

[blaggacao]

It makes sense to provide the -installer versions so users can download them, but for building custom images they don't really offer much since they only override one option.

On the discourse thread, some people raised that this is avery valid use case. I doubt it in a way, omce you ever tried tu build something on the pi (takes days and usually hangs). I think this split will allow for a better re-assessment some poimt in the future.

One thought I had (not necessarily a suggestion for this PR) is that we might not need sd-image-aarch64-new-kernel.nix and sd-image-raspberrypi4.nix.

Let's leave that for another PR, indeed. But I agree, it might ne wise to deduplicate a little and reduce here.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/352

[lopsided98]

On the discourse thread, some people raised that this is avery valid use case. I doubt it in a way, omce you ever tried tu build something on the pi (takes days and usually hangs).

I'm not really sure what you mean. If someone doesn't already have another aarch64 machine, how would they install NixOS without downloading one of the prebuilt images? Modern aarch64 SBCs are also pretty capable builders, not necessarily the RPi <=3, but certainly the RPi 4, or RK3328/RK3399 boards (which can use the prebuilt installer image as well if you manually install the bootloader).

[blaggacao]

I'm not really sure what you mean. If someone doesn't already have another aarch64 machine, how would they install NixOS without downloading one of the prebuilt images? Modern aarch64 SBCs are also pretty capable builders, not necessarily the RPi <=3, but certainly the RPi 4, or RK3328/RK3399 boards (which can use the prebuilt installer image as well if you manually install the bootloader).

I definitley failed with pi3, indeed. I was hoping that nix proper cross building would save me here. It might also be slightly more convenient to work off my powerful workstation.

Actually, the driving use case for this PR is to explore cross build in the context of divnix/digga#72

I'm not actually trying to dismiss the installer version. I can imagine that cross builds are actually more user friendly and convenient, though.

[roberth]

To summarize, this moves modules around so that their file paths actually make sense and extracts parts of them into new files so that they can be used independently, all without modifying existing installer image configurations.

[dramforever]

@blaggacao

Sorry for the necrobump. Someone pointed me to this topic elsewhere, which prompted me to read this whole thread. I saw this bit:

On the discourse thread, some people raised that this is avery valid use case. I doubt it in a way, omce you ever tried tu build something on the pi (takes days and usually hangs). I think this split will allow for a better re-assessment some poimt in the future.

Yeah I'm one of the people who said that. I was thinking about why your experience of building on rpi is described is so different from mine when I realized: I use aarch64-linux on a Raspberry Pi 4. There's official binary cache for aarch64-linux.

This means that most of the time taken to rebuild the system is to download the packages, not build them. If I need to cross-compile an image, I need to build everything, which takes hours on my laptop (yes I've tried) for the first time, and then hours whenever there's a major update. But since the native stuff is all on cache.nixos.org, rebuilding on an rpi takes a negligible amount of time compared to me testing things out and debugging stuff. Not to mention avoiding the pain of needing to physically move the SD card around to write new images.

(If I remember right, there's an unofficial 32-bit ARM binary cache, but I couldn't remember the details.)

So I hope that when it comes to see whether the installer targets should stay or should leave, the fact that you just simply don't have to build that much stuff when there's binary cache available is taken into consideration.

Or I could have horribly misunderstood what this means, in which case I'm happy to be corrected or even ignored.

[blaggacao]

@dramforever Thanks for the context, fortunately this change is a pareto-improvement and I (at least) don't plan to follow up on removing anything. 😉