Kernel build uses more than 16 GB of space

I would not normally try to build a kernel myself but I need a kernel patch because right now I cannot update my system. The problem is that building the kernel takes up a huge amount of space. It eventually takes up all the space in my tmpfs for /tmp (16 GB). Now, I could try throwing more disk space at the problem by disabling the tmpfs for /tmp. But is that normal? What is happening here? Shouldn’t it be possible to build a kernel with less disk space?

A kernel build needing a lot of space is to be expected given all the .o files being created and such. My workaround for large builds so far has been giving the nix-daemon a different TMP directory that is on disk.

systemd.services.nix-daemon.environment.TMPDIR = "/nix/tmp";
systemd.tmpfiles.rules = [
  "d /nix/tmp 1777 root root 1d"
];

(the tmpflies rules clear that directory once a day)

3 Likes

Unless you have substantial amounts of RAM, you should not be using /tmp on tmpfs. I have 64 gigabytes of RAM for example, and it works out fine.

Okay, thanks for your answers. I finally did it. Used about 27 GB of disk space in the end. Although I have been using Linux for 15 year now, I had never had to compile a kernel. So, I did not know what to expect. I would not have imagined in my wildest dreams that it would take up that much space.

A buddy of mine told me when he compiles his Gentoo kernel he needs maybe 1 GB of disk space and he estimated that a normal build would maybe need 3 GB. But I guess he only builds the drivers and stuff he actually needs. And since he has been using Gentoo for decades he apparently just has no idea what a “normal” build of a Linux kernels actually requires. It seems Gentoo is just built different(ly). :laughing:

Edit: Typos, missing words

I’ve never tried it, but I bet we could do the same thing with Nix. If the idea is to build a kernel with a much smaller surface area, that sounds like passing the right structuredExtraConfig into the existing kernel derivation (figuring out just how much needs to be stuffed into structuredExtraConfig is the hard work). If the idea is that you want a kernel that Nixpkgs already ships but with a patched driver or something, you could probably write by hand a hybrid derivation that depends on the shipped kernel and the kernel source, compiles just the extra bit you need, and copies everything else over from the pre-built kernel.

In principle, Gentoo shouldn’t have an advantage here. The rough edges might not all be filed off in practice, though.

2 Likes

I do think this is a lil’ excessive as a former gentoo user. That’s a lot of disk space for compiled code. We sure there isn’t some lower hanging fruit here?

1 Like

depends on what exactly they try to do ig. If its adding a kernel module then one could just build that standalone without a full rebuild. But for a generic full size kernel that isn’t unheard of.

The default kernel configuration in NixOS is insanely bloated, don’t even try to compile it unless you have some server as a dedicated build farm. It can easily take hours to build on a desktop, even if you manage to get enough disk and memory to do it. So, you can’t simply add your patch to boot.kernelPatches and call it a day, but there is a way around.

You can generate a kernel configuration that enables only the modules you really need by looking at what is currently loaded: you have to run make localmodconfig in the kernel source tree, starting from a base configuration. There’s also this tool to help maintain the list up-to-date.

After you’ve got a tailored configuration, you can build your kernel with something like this:

boot.kernelPackages =
  let
    kernel = pkgs.linuxManualConfig {
      inherit (pkgs.linux_6_15) src version;
        configfile = ./kernel.config;
        allowImportFromDerivation = true;
        kernelPatches = lib.singleton
          { name = "my-important-patch";
            patch = pkgs.fetchurl { ... };
          };
      };
  in pkgs.linuxPackagesFor kernel;

Don’t worry too much about getting everything right the first time, because the compilation time will be of the order of a few minutes, so you can quickly iterate.

6 Likes

Note that upstream now has the fix and likely cached kernels will again be available.

1 Like