nixos: Formally deprecate boot.loader.raspberryPi
#241534
Conversation
The whole option set was recommended against since mid-2019, and never worked with the Raspberry Pi 4 family of devices. We should have deprecated it in early 2020 for removal by 2021. At the time I did not feel confident in making such a decision, and never ended-up getting around to it. The ***only*** supported-by-NixOS boot methods for AArch64 are standards-based boot methods, namely UEFI or the pragmatically almost-standard extlinux-compatible for U-Boot. You can quote me on that.
|
👍 These clear deprecation notices would have saved me a bunch of time spent going down blind alleys. |
|
@samueldr Sorry, I have a question: I don't know much about the details of these parameters, but I do use |
|
@samueldr I also have some questions. The NixOs Wiki doesn't recommend against the raspberry bootloader at all. See: https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi . Much to the contrary, some documentation in that article seems to me to only work correctly when using that bootloader. My installation is also just a year old and I did not even know that I did something unsupported until today. Can you update the Wiki with an official recommendation or upgrade path and also add a link to the error message with information regarding this deprecation? |
|
Thanks for noticing this discrepancy. The NixOS wiki instructions on that page are from contributions written before the change, and have never been updated to remove those recommendations. They do not work as expected. The NixOS wiki pages for the Raspberry Pi are outdated. Note that the "current" Raspberry Pis have their own pages:
(If anyone else wanted to remove this all and make a note.) I'll try going back to this, but I've been relatively busy recently. |
|
@samueldr , thank you for the heads up. I left a warning on this page about the deprecation: https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi |
|
@samueldr I noticed this deprecation warning again today while doing some maintenance on my Pi and I would still appreciate some pointers on what the migration path for |
|
Device tree overlays, probably. |
|
I've tried to migrate from |
On rPi, the actual bootloader is located on the first SD card partition. You have several options how to fix this
The last one would be really neat. If At that point you could just grab that using something like and it could also be used by the update mechanism. I can help with all this I think. Edit: this was actually previously done by https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/raspberrypi/raspberrypi.nix#L146 |
|
Thanks, that's very helpful. I'm actually booting from a SSD drive via USB (and using a ZFS / ephemeral setup as well), so it looks a bit different for me: But, looking at the nix files you linked, it looks like the stuff from the 'old' boot setup is sitting in my So I think if I do follow the script in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/sd-card/sd-image-aarch64.nix#L22 I should just splat all these files into |
I'm not sure I understand this correctly, but it might be misleading.
We have mechanisms to update The first partition shouldn't be mounted ever, unless you want to manually edit The migrations step will be varied from situation to situation due to the myriad ways to setup a system. Looking at your If you want to have the rootfs on a filesystem unsupported by U-Boot, you will need to at least have a |
Oh, the mountpoint is defined but has 'noauto' and the directory is missing. Cool! You are right that this depends on the setup as well, I mostly use SD images. Still the firmware update mechanism would be nice. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Trying to make my use case less vague: I set this up ~a year ago, so I wouldn't call it 'the olden times', but it is a custom install, based on https://grahamc.com/blog/erase-your-darlings/ , with added Raspberry flavour. I have uploaded a gist with the (sanitized) version of my configuration and the custom scripts I used, along with the README I keep with it, and a (reduced) diff of my config: https://gist.github.com/SFrijters/665686199c915804f993a4ee4002d33e/ . I hope this retains enough info to be helpful but is small enough to not scare people off. The firmware update mechanism @sorki mentioned is I think what I expected to happen when I removed the EDIT: Indeed I boot without SD card, after the initial setup as described in the gist. The system has been working fine, but I do recall it being a bit finicky with respect to actually booting from USB the first time, so I would prefer not to nuke my current setup, even with the supposed reproducibility of my scripts and config. |
|
That's neat @SFrijters! Regarding act and power LED configuration you can try my module from https://github.com/pi-bouncer/pi-bouncer/blob/3fcf4b5b2f1bc28821a31ba8ada4a34f0c9d08bb/modules/rpi.nix (don't know how to do eth leds tho). Thank you @samueldr for deprecating this, it will cause a lot of pain for users using it but it is the right thing to do long-term. |
|
@sorki Thanks! This is how I'm doing it now, all based on the device tree overlays - at least I'm fairly confident it will work once I can actually switch into the new boot generation! https://gist.github.com/SFrijters/206d2c09656affb04284f076c75a1969 |
|
All is well that ends well: I did not like having to do this migration (and I still think it would've been nice to get better documentation on a migration path as a part of this PR instead of just a "not like this" deprecation warning), but I really appreciate @sorki and @samueldr for their help. Using #261857 to move to the new bootloader and the overlays in https://gist.github.com/SFrijters/206d2c09656affb04284f076c75a1969 to replace my |
|
I just landed here due to the deprecation notice: If I am understanding the comments around here the solution isn't as simple as just as replacing the raspberry-related settings with: What are the steps to migrate? @SFrijters I am also booting from SSD and I also remember a painful experience making it work, which steps did you follow to migrate? I don't have a need for device tree overlays though. |
|
@dbarrosop: I ended up using https://github.com/NixOS/nixos-hardware (which sets Then I used this procedure (taken from a comment in my config so I don't forget it myself): Generating contents for /boot: #261857
{
imports = [
./modules/installer/sd-card/sd-image-aarch64.nix
];
nixpkgs = {
crossSystem.system = "aarch64-linux";
overlays = [ ];
};
}
Hope this helps! |
|
Yes, that's extremely helpful, and terrifying, thanks! |
I have the a similar question. Does anyone know what the replacement is for driving default GPIO values via |
Sort-of already in this thread 😄
This should still work (i.e. if it's already in the |
|
Thanks for the pointers to I looked at the conversation about device trees, but I do not think that solves my problem since I need the GPIOs driven low very quickly (before the kernel starts) after boot to work around a hardware bug. My understanding of device trees is that they are all kernel-space and will not do anything to the low-level boot firmware (e.g. |
Correct but the |
It absolutely did, thank you @SFrijters. None of these are built by the
|
See NixOS/nixpkgs#241534 for more information.
The whole option set was recommended against since mid-2019, and never worked with the Raspberry Pi 4 family of devices.
We should have deprecated it in early 2020 for removal by 2021. At the time I did not feel confident in making such a decision, and never ended-up getting around to it.
The only supported-by-NixOS boot methods for AArch64 are standards-based boot methods, namely UEFI or the pragmatically almost-standard extlinux-compatible for U-Boot.
You can quote me on that.
Description of changes
Added a deprecation warning, and added note and schedule for deprecation in release notes.
Things done
Ran:
Also built documentation, and checked the result is as expected for options
As expected, no warnings.
Was not tested: Using those options, as I have no system that are using those options. I know it sucks sending "untested" changes, but I'm at least honest with what I have done.
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)