Rebuild error with latest raspberry-pi-nix and nixpkgs 24.05

[PowerUser64]

I was updating my system, when I got the following error:

       error: The option `boot.loader.generic-extlinux-compatible.enable' has conflicting definition values:
       - In `/nix/store/4f9cx80vcs558qa1i68aa74yhc0lxsk5-source/raspberry-pi/4': true
       - In `/nix/store/7sprarsdfz9qcd7859phvr9nvhi14mri-source/flake.nix': false
       Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

The first file listed in the error is from raspberry-pi-nix, and the second one is from nixpkgs. It seems that raspberry-pi-nix tries to set a value that nixpkgs also sets. I solved this by using lib.mkForce in my config, but it seems like something that should be solved in rpi nix or nixpkgs. I only started getting this error recently. Any idea where this should be solved?

Update: I'm now getting a subsequent error:

       error: The option `system.build.installBootLoader' is defined multiple times while it's expected to be unique.
       Only one bootloader can be enabled at a time. This requirement has not
       been checked until NixOS 22.05. Earlier versions defaulted to the last
       definition. Change your configuration to enable only one bootloader.

       Definition values:
       - In `/nix/store/7sprarsdfz9qcd7859phvr9nvhi14mri-source/nixos/modules/system/boot/loader/generic-extlinux-compatible': "/nix/store/gr0aydmfa2i3ivg1x85pmr4cr5rlq0bc-extlinux-conf-builder.sh -g 20 -t 5 -r -c"
       - In `/nix/store/7sprarsdfz9qcd7859phvr9nvhi14mri-source/nixos/modules/system/boot/loader/init-script/init-script.nix': <derivation init-script-builder.sh>
       Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

Not sure if I can lib.mkForce my way out of this one.

[PowerUser64]

I manually set boot.loader.generic-extlinux-compatible.enable to false with lib.mkForce to avoid the second error, and now my pi won't boot :face_with_diagonal_mouth:

I'm recovering it, with the main disk hooked up to my desktop. I'm not 100% sure what to do to satisfy nix here, but I'll post updates here as I go.

Still battling the same errors as mentioned before. Resolving the first one by setting boot.loader.generic-extlinux-compatible.enable (with mkForce) to false leads to no boot, and setting it to true causes the second error above. I can't resolve the second error by setting system.build.installBootLoader to anything because it causes another error saying the option doesn't exist.

[PowerUser64]

Turns out rpi-nix looks at the uboot option, and sets boot.loader.generic-extlinux-compatible.enable as well as boot.loader.initScript.enable automatically. nixpkgs looks at boot.loader.initScript.enable as its way of knowing whether to set this mysterious system.build.installBootLoader option.

I have uboot disabled (the default), which should cause rpi nix to disable both initScript and generic-extlinux-compatible. This causes nixpkgs to disable system.build.installBootLoader ... I'm going crazy trying to figure this out lol.

Anyway, what's happening is rpi-nix wants to enable an option (generic-extlinux-compatible), but nixpkgs wants it disabled. mkForcing the option to be disabled causes my pi to not boot, so I need to mkForce it to be enabled. But, if I do that, an internal nixpkgs option gets set for me (declaration: system.build.installBootLoader - set here) to a value that conflicts with one that rpi-nix changes through initScript. This feels like a circular dependency tree of things being broken and I don't know how to fix it.

Sorry if this reads more like a journal entry than a github issue, I'm trying to process what's going on and these are my observations.

@tstat I'm really lost with this, do you have any insight?

[PowerUser64]

I'm not sure if I can salvage the boot disk, I'm going to rebuild it from scratch and copy files over. It's not that big of a deal because I've been meaning to start from a fresh nix config for a while now. Just means more downtime.

By the way, @tstat it might be a good idea to mention somewhere in the readme that you need to set networking.networkmanager.plugins = lib.mkForce [] or else you have to build webkitgtk (in my experience). Found this using nix-tree.

[PowerUser64]

UPDATE: It's working now! I'm pretty sure the problem was that I had a really old eeprom version (from 2020). I think the eeprom I had wasn't compatible with booting with the extlinux options, and the recent removal of u-boot caused my system to break. Either way, I've updated the bootloader to the latest version following these steps on the nixos wiki and now I can boot!

I haven't tested booting with rpi-nix yet, but I'm pretty sure if I tried now it would work.

[tstat]

There is a lot in this issue. It's somewhat hard to follow. The first error you posted:

   error: The option `boot.loader.generic-extlinux-compatible.enable' has conflicting definition values:
  - In `/nix/store/4f9cx80vcs558qa1i68aa74yhc0lxsk5-source/raspberry-pi/4': true
  - In `/nix/store/7sprarsdfz9qcd7859phvr9nvhi14mri-source/flake.nix': false
  Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

Looks like a conflict that involves nixos-hardware and this repo. This repo uses the default rpi boot process by default, which uses the initScript bootloader. nixos-hardware used uboot last I saw, but I think maybe it is something else now.

But yes, you don't want to set both of these. By forcing both of them to be on it seems like further problems were encountered.

By the way, @tstat it might be a good idea to mention somewhere in the readme that you need to set networking.networkmanager.plugins = lib.mkForce [] or else you have to build webkitgtk (in my experience). Found this using nix-tree.

I don't use networkmanager personally. Does nixpkgs set enable some plugin that depends on webkitgtk?

Are you booting with uboot or the initscript method now?

[PowerUser64]

Looks like a conflict that involves nixos-hardware

Ohhh! I didn't know nixos-hardware sets that. I should've checked my other inputs. This could be another good thing to add a note about in the readme. Right now I have boot.loader.generic-extlinux-compatible enabled, but to be honest I'm not entirely sure what that implies. The rpi boot process (and things surrounding it like uboot, and extlinux-compatible) are black magic to me, and despite my research, I still don't know where it's documented to learn more about it. If you happen to know of anything you can point me to on this I would love to learn more about how it works! I might be able to have a more intelligent discussion about what's going on if I actually understood what I'm talking about.

Does nixpkgs set enable some plugin that depends on webkitgtk?

Yeah, I'm pretty sure it's the openconnect plugin, which is enabled by default, and depends on stoken, which in turn depends on gtk and a bunch of other graphical things.

Are you booting with uboot or the initscript method now?

I believe setting boot.loader.generic-extlinux-compatible means I'm using initscript, but I'm not 100% sure to be honest. I just tried switching back to raspberry-pi-nix again (and commented out my own boot settings as well as nixos-hardware) and it left me with no boot, so I'm really not sure what to make of it. (Don't worry though, I got it back and running in ~30 min by overwriting the boot partition with the one from the stock NixOS boot image on hydra.)

The method I'm using is going to be either what nixos-hardware sets or what the nixos stock boot image from hydra uses.

---

Thanks for getting back to me on this! And sorry about how fragmented everything in this issue is. I was very anxious and uncertain when I was writing most of it and I tried to document as much as I could since I didn't know where the red herrings were, but I think I just ended up making it confusing (just as I was in the moment :stuck_out_tongue:). I hope we can get to the bottom of whatever is going on! I could share a zip of my pi's config with you if you'd like. It's not public right now (it might be someday), but if I would be happy to share it with you if you think it would help figure out what's happening. Are you on matrix, IRC, or another chat platform? It might be easier to send a file privately (or a link to one) on another platform. I'm PowerUser64 in those places. I could also encrypt it with a public key of yours (gpg, ssh, or similar) and send it that way if you'd like!

[DerRockWolf]

Regarding webkitgtk:

webkitgtk is being rebuilt because it depends on libcamera & libpisp.

Another workaround would be raspberry-pi-nix.libcamera-overlay.enable = false;.

@tstat would it be possible to add the overlay only to packages that need it or is the overlay meant to be applied to all packages that depend on it?

[tstat]

Well, it was intended to be applied to all packages that depend on it, as I assume whatever changes were made in the fork are necessary and/or helpful if you want to use rpi hardware, but I don't know any details about that stuff.

We could just limit those packages to just be inputs to rpicam-apps, but I wouldn't be surprised if the mainline libcamera didn't work appropriately for rpi hardware with other downstream packages.