Change:
# e.g. "defconfig" kernelBaseConfig = if defconfig != null then defconfig else stdenv.hostPlatform.linux-kernel.baseConfig or "defconfig"; <del> # e.g. "bzImage" kernelTarget = stdenv.hostPlatform.linux-kernel.target or "vmlinux"; </del> makeFlags = lib.optionals (stdenv.hostPlatform.linux-kernel ? makeFlags) stdenv.hostPlatform.linux-kernel.makeFlags ++ extraMakeFlags;

Discussion:
attribute exists in the derivation code, but it is never used. This is confusing to me as newcomer, and is probably a leftover from an unclean past refactoring. Steps to reproduce the behavior: with an override of the via standard target it generated. Ethier: overriding (i.e. from the to ) changes the actual build output to , or does not exist Ultimately, I need a way to build a kernel via nix but not for a nixos, so I can't understand how to override the properly without it affecting the rest of the system (i.e. I want to build the nixos kernel to use with my system, and this other kernel for use in my other system that I want a different target on). A similar issue is present at (which I actually use now, since I also need a custom config). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (not sure if you are the right people to ping, sorry if I'm mistaken) This shouldn't really matter, but: I'm also in a flake currently, but this needs to be portable for other environments...
There's no such attribute in the kernel derivation. The only mention of kernelTarget in Nixpkgs is an attribute of the kernel config file. It deosn't seem to do anything and can probably be removed. If you want to build a kernel with a custom target, that's a property of the platform being built for, so you should set linux- in localSystem or crossSystem appropriately when you import Nixpkgs.
Right, that's what I meant, it is just declared inline within the definition of fn. If you can confirm it doesn't do anything, I'd send a PR to remove it, as it surely is confusing. Got it! This is a bit more complicated than I expected as it seems I have rewire how the nixpkgs are used in my setup. My understanding is that I'll have to import a second instance of nixpkgs with a cross-build (even though it's not really a cross-build in a usual sense) and set the target settings on that. This seems like it would work, as long as nixpkgs itself is really pure, and doesn't pollute the global environment.

Thank you for the tip!
Unless you want to build multiple different kernels with different targets, you can just override localSystem on the Nixpkgs you're already importing, avoiding both cross compilation and multiple Nixpkgs instances.
Well, I'm currently focusing on just one, but eventually, I want to build two "standalone" kernels - one for the host os and one for the guest os - "standalone" in the sense that they won't be used as part of a nixos installation, but a custom one. These are sort of like two environments I need to maintain. In addition to that, I also have a nix shell defined with the same flake (), that is intended to be usable on the system I develop on - and this is the third nixpkgs environment I need to maintain. So, ultimately I think what would make sense would be to have the "default" nixpkgs import what I use in the , and two new imports, one for each "standalone" kernel.
this I wish I knew this earlier. Been fucking around with the buildKernel drvs wondering where it sources that stuff from. I didn't know these variables existed and if I wouldn't have found out I probably would have give up porting nixos to s390X (e.g Z10 mainframes as I happen to have one of these for a while)