Unfortunately, I believe the standard tools can’t handle the situation where /boot is already full. Because they first move the new data to /boot, update the menu, then remove the data that’s no longer needed. That’s good for atomicity, but bad if /boot is full, since they can’t break out of the error condition.
Afaik the only way to get things working again is to manually delete the kernels/initrds from some old generations out of /boot to make enough space for the script to operate again, then run a rebuild. (After you’ve garbage collected enough generations to avoid a repeat of the same problem.)
There are options that can help you avoid the same thing in the future, like boot.loader.<your_bootloader>.configurationLimit, and/or setting up an automatic gc on a schedule that keeps the number of generations down.
After all else failed, I had to sudo rm -rf system-50-link after which I was able to rebuild. The main Problem I think is that my /boot is way to small, this might have to do with the fact that I installed NixOs next to an existing Windows and did not think about the size of /boot while installing NixOs.
I ran into this a while ago. I did the garbage collection and that didn’t help. but I found that garbage collection /plus/ rebooting did help. not sure why. I just assumed that some items were marked as ‘clear’ but not actually removed until the reboot.