Today I switched to the unstable nixpkgs channel and it gave me this:
trace: warning: The option set for `boot.loader.raspberrypi` has been recommended against
for years, and is now formally deprecated.
It is possible it already did not work like you expected.
It never worked on the Raspberry Pi 4 family.
These options will be removed by NixOS 24.11.
I’m currently using a raspberry pi 4 and the bootloader just works perfectly (despite the warning). I use it in order to overclock my raspberry (firmwareConfig option). When it will be removed how will I be able to overclock my device?
First of all: how did you verify that it works as expected? It might not actually work as expected.
Then, the whole option set for boot.loader.raspberryPi was never meant to work with the Raspberry Pi 4. I think it’s possible the config.txt ends-up working by luck, in how the format ended-up being forward-compatible. But then again, it is if the FAT partition is mounted under /boot, which I suspect it won’t, or else switching generations will be unlikely to even work given its default size of 30MiB.
Using an image built from any of the user-provided alternatives to build a Raspberry Pi 4 image.
Though even under these considerations, the firmware bits for the Raspberry Pi 4 will not have been updated as one would expect from these options.
NixOS only officially supports generic mainline Linux images with standard (enough) boot methods. That goes for x86_64, AArch64, and soon(?) RISC-V hopefully.
What are the migration steps?
It depends.
It depends a lot on what the thing you actually are running is. There might be just as many answers as there are users using these options.
Then what can I do?
First thing would be identifying in which situation you are. Knowing the current partition map + mount map for the system will help, and the initial installation method / repo used. That should give a good estimate for follow-ups. Anything else is pretty open-ended.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 223.6G 0 disk
├─sda1 8:1 0 30M 0 part
└─sda2 8:2 0 223.5G 0 part /nix/store
/
I just downloaded the sd image from Hydra one month ago and I added the availableKernelModules from nixos-hardware to make it boot.
EDIT: I noticed only now that the documentation says
This configuration assumes that the VFAT firmware partition is mounted to /boot. If it isn’t, options like boot.loader.raspberryPi.firmwareConfig will write their configuration to the wrong partition and have no effect.
If you want to edit the config.txt settings for the board, think of it like BIOS options. They are handled outside the lifecycle of a NixOS generation.
So what you should do is mount the 30MiB VFAT partition to e.g. /mnt, edit the config.txt manually, unmount, and then reboot. (Or way you want to mount and edit that file.)
The reasoning behind that is that this way all ARM platforms are abstracted away as “boots through U-Boot via extlinux-compatible OS boot flow”, the only reason the VFAT partition is there with the raspberry pi firmware files is that their boot schemes are so cumbersome to add to an SD image after the fact, that we don’t want to offload that entirely to the end-user.
(Though maybe having a final step to “burn” that firmware to the sd card via a script would help understand that mental model better…)
What about the DTB stuff? I had a lot of problems where I needed to use the firmware-provided DTB because of stuff I’d put in config.txt. Is this still the case? If so, the way NixOS resets it with a mainline DTB kinda messes with that, no?
Other than the exception I forget about where the Raspberry Pi firmware changes something, IIRC about the USB stack[citation needed], it’s all through hardware.deviceTree. (And that one also require the NixOS option)
If U-Boot was in the boot flow, anyway the device tree overlays “as applied by config.txt” were not ended-up used by the loaded operating system. (Though it is more nuanced than that, and gets confusing fast without a complete dive into the whole setup.)
You can still use other boot methods, including the Raspberry Pi specific boot flow, but it will require bringing your own set of options to manage them.
When you end-up requiring vendor-flavoured boot flows, you are in a situation that is not anyway supported by the mainline generic kernel boot situation. And anyway (puts on divination hat) when you use CM4-based systems it gets an awful lot more complex and is anyway not properly handled by those options.
I messed around with the deprecated config a while ago. If I remember, I did verify the overclocking worked, there’s some file in /proc I could check on. I believe I also changed the default size of /boot in the image and added it to fileSystems, since otherwise config.txt wouldn’t have been written to the partition. I guess it makes sense that it should be handled separately though.