What to do with a full /boot partition?

ashkan-leo · April 9, 2020, 3:09am

My /boot is only 30m. I can’t even build a single generation. Any suggestion how to increase that?

gilescope · July 24, 2021, 10:59am

This is a BUG. It’s extremely not good that a system can get broken by continuing to do nixos-rebuild switch (because nixos is meant to be a fearless tinkering system - that’s meant to be its strength).

If there’s only space for one more generation then it should fail with an error saying “Please run nixos-garbage-collect first and then rerun this command with --force.”

gilescope · July 24, 2021, 3:47pm

Just to note as this has happened to several people. If you start getting locale problems with perl (and in my case gnome-terminal didn’t want to start). That could be due to the /boot partition running out of space. If you set it in the gui to something then that seems to fix it again (not something that nixos-rebuild would fix unfortunately).

bbjubjub · July 24, 2021, 6:17pm

My two cents since I’ve had issues with that on my Raspberry Pi: the root cause of the bug is putting more things than strictly necessary on firmware/EFI partitions. This has been solved for RPi for a while, and it’s where it happens most often. However, an UEFI system with 512MB /boot partitions as specified in the manual could potentially encounter this issue too, albeit more rarely. Should we consider moving that to /boot/efi there as well?

gilescope · July 25, 2021, 6:55pm

I had windows slapped on the box as wasn’t sure if nixos would take (and chillblast doesn’t have a nixos preinstalled option yet) but the /boot partition is 100mb and 25mb seems to be windows boot which is mostly fonts!

gilescope · December 18, 2021, 4:47pm

Thank you - that saved the day when it was full and I was reinstalling nix from a liveusb but it was complaining about a full boot disk. Pointing it at the mounted drive worked wonders:

nix-env -p /mnt/nix/var/nix/profiles/system --delete-generations +2

cetera · October 1, 2023, 2:24pm

Manually make some space in boot. Find your kernels and rm them.

Thanks for the instructions. How do I know which files are safe to delete?

Seemed like this question was never explicitly answered which left me confused about what to do exactly for step 3. Here’s what you should do exactly:

First, determine your current kernel version:

$ uname -r
6.1.38

Any file in /boot/EFI/nixos that doesn’t include those numbers is (presumably) safe to delete. Err on the side of caution and only delete the oldest few versions. My oldest version was 5.15.74, so I personally ran sudo rm -rf /boot/EFI/nixos/*-5.15.74* to get space back.

Repeat with more old versions until sudo nixos-rebuild switch stops throwing “No space left on device” errors.

TLATER · October 1, 2023, 3:01pm

And since it has apparently not been mentioned in this thread, you should probably tune the configurationLimit of your bootloader so that it removes the oldest ones automatically.

I don’t think most desktop use cases will need more than a handful of generations at any point in time, so the default of infinite or ~100 (which can still eventually grow to ~3GBs worth of kernel+initrds) is a bit excessive, even if there are good arguments for keeping it high by default.

aflux · December 14, 2023, 1:06am

And since it has apparently not been mentioned in this thread, you should probably tune the configurationLimit of your bootloader so that it removes the oldest ones automatically.

How and where is boot.loader.systemd-boot.configurationLimit declared please? I had a look at the linked search, but in my newb-ness it isn’t clear to me how to do that.

TLATER · December 14, 2023, 10:52pm

Normally you would add it to /etc/nixos/configuration.nix, looking somewhat like this: https://github.com/TLATER/dotfiles/blob/444a85b014ad86dc5a9fa9e5e38c585dcb7958f7/nixos-config/default.nix#L81

That said, this is a pretty basic question. The actual docs on how to use NixOS are in the NixOS manual; have a read through at least that chapter and open a separate thread when you run into issues. This one is quite old and basic usage of NixOS is a bit out of scope.

nosferatu · February 23, 2025, 1:36am

I dug around to find why sometimes I have left over kernels in /boot/EFI/nixos
I found that the function below copies the kernels from the nix store to the folder.

github.com

NixOS/nixpkgs/blob/a716c173ff7fac03038e3a564820c251146985b4/nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py#L151


      
              sortKey = systemdBootExtension.get('sortKey', 'nixos')
              devicetree = systemdBootExtension.get('devicetree')
              return BootSpec(
                  **bootspec_json['org.nixos.bootspec.v1'],
                  specialisations=specialisations,
                  sortKey=sortKey,
                  devicetree=devicetree,
              )
          
          
          def copy_from_file(file: str, dry_run: bool = False) -> str:
              store_file_path = os.path.realpath(file)
              suffix = os.path.basename(store_file_path)
              store_subdir = os.path.relpath(store_file_path, start=STORE_DIR).split(os.path.sep)[0]
              efi_file_path = f"{NIXOS_DIR}/{suffix}.efi" if suffix == store_subdir else f"{NIXOS_DIR}/{store_subdir}-{suffix}.efi"
              if not dry_run:
                  copy_if_not_exists(store_file_path, f"{BOOT_MOUNT_POINT}{efi_file_path}")
              return efi_file_path
          
          
          def write_entry(profile: str | None, generation: int, specialisation: str | None,

It’s called in the function write_entry:

github.com

NixOS/nixpkgs/blob/5c978e28528081e3dab8183501de4f4dec1928fa/nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py#L161


      
          def copy_from_file(file: str, dry_run: bool = False) -> str:
              store_file_path = os.path.realpath(file)
              suffix = os.path.basename(store_file_path)
              store_subdir = os.path.relpath(store_file_path, start=STORE_DIR).split(os.path.sep)[0]
              efi_file_path = f"{NIXOS_DIR}/{suffix}.efi" if suffix == store_subdir else f"{NIXOS_DIR}/{store_subdir}-{suffix}.efi"
              if not dry_run:
                  copy_if_not_exists(store_file_path, f"{BOOT_MOUNT_POINT}{efi_file_path}")
              return efi_file_path
          
          
          def write_entry(profile: str | None, generation: int, specialisation: str | None,
                          machine_id: str | None, bootspec: BootSpec, current: bool) -> None:
              if specialisation:
                  bootspec = bootspec.specialisations[specialisation]
              kernel = copy_from_file(bootspec.kernel)
              initrd = copy_from_file(bootspec.initrd)
              devicetree = copy_from_file(bootspec.devicetree) if bootspec.devicetree is not None else None
          
              title = "{name}{profile}{specialisation}".format(
                  name=DISTRO_NAME,
                  profile=" [" + profile + "]" if profile else "",

These lines are what place those files in /boot/EFI/nixos:

kernel = copy_from_file(bootspec.kernel)
initrd = copy_from_file(bootspec.initrd)

I don’t know what would cause the other kernels from not being removed but I think at some point the boot process should ensure this folder is cleared prior to the copy.

You can run:

ls -l /run/booted-system/kernel /run/booted-system/initrd

To see what your currently used kernels are and

find /boot/EFI/nixos ! -name ‘filename1’,‘filename2’ -type f -exec rm -f {} +

obviously replace the filenames with the kernels you need to keep

ElvishJerricco · February 23, 2025, 1:44am

@nosferatu Old kernels / initrds / etc. are removed here: nixpkgs/nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py at a8b68f204c3e07fe12133e7ad6e97c758c0f30a1 · NixOS/nixpkgs · GitHub

In fact, it’s actually overly effective, and removes everything every time, only to copy them right back to where they were, instead of just deleting the obsolete files. So it doesn’t make sense to me that you have obsolete kernels lingering around.

nosferatu · February 23, 2025, 1:56am

I have no idea then.

Raikiri · April 16, 2025, 6:43am

Recently had a problem with a brand new top-end laptop (alienware) shipping with a 4TB ssd and 256MB boot partition(I don’t know what they were thinking). I decided to dual boot install NixOS on it and naturally very quickly ran out of space in its boot partition. So I decided to use gparted to increase the boot partition size while booting from a usb stick. Unfortunately, it turns out that gparted is incapable of resizing fat32 partitions that are 256MB or smaller, more info here: Failure to move / resize fat32 partitions less than 256 MB in size / Newbie Corner / Arch Linux Forums

It also looks like there’s not a single alternative to gparted that I could find that’s capable of resizing the boot partition, and everybody recommends “just use gparted”, but in order for gparted to work, the partition needs to be larger than 256MB, and my partition is exactly 256MB. So it’s a catch 22 situation.

The recommended workaround is to format the partition as ext4, resize, format it back to fat32. Naturally, this loses all of the data, so I had to back it up first then restore. However, this also changes the fat32 UUID (or whatever its 8-digit analog for fat32 is called). After this operation nixos attempts to boot just fine, but then gets stuck and the systemd log says that it tries to mount the boot partition by its old UUID (before formatting).

Since nixos does not allow direct modification of fstab, I couldn’t just modify it to mount the boot partition by its new UUID. I tried to go into hardware-configuration.nix and change the boot partition to be mounted by its label, but that lead to even stranger kernel panics for some reason.

Every attempt at trying to define a new UUID of the boot from in an existing NixOS install also failed and ultimately led to kernel panics at various stages of the boot process (sorry, don’t have the logs), because NixOS kept trying to boot from the drive using its stale UUID, I have no idea where it got it from, because I modified it in hardware-configuration.nix and rebuilt the system.

The only thing that did work for me was to modify the UUID of the formatted boot partition to match the previous one, using

mkdosfs -i 1227C0DE /dev/sda0

and that did end up working.

But man, what a journey. Still not sure why I couldn’t change the boot partition to be mounted by its label rather than the UUID, but hopefully this can help somebody.

PS I really recommend to use gnome-disks/disks program (comes with nixos live image) to create a backup of your boot partition first. You can mess with the partition all you want and then just restore it from the image no problems. It’s almost guaranteed that you’ll brick it multiple times in the process of trying to get it to work, but restoring from the image seems to work reliably well.