NixOS Automatic GC and Generation Retention: Bootloader Limit Behavior Needs Diagnosis

Retention Boundaries Between Boot Menu Limits and Store Deletion

NixOS derives system state from a declarative configuration and keeps prior generations in the Nix store so rollbacks remain possible. Garbage collection is not automatic unless a systemd timer or manual invocation triggers it, while the bootloader's configurationLimit controls how many generations appear in the boot menu.

The unresolved point is the boundary between these two mechanisms. A boot menu limit may only affect which entries are displayed, leaving older store paths intact until GC runs; alternatively, it may act as a retention floor that GC respects. The distinction matters on small root partitions, where automatic GC is often enabled to avoid disk exhaustion but where removing too many generations reduces recovery options.

Behavior may vary by NixOS release, so any conclusion should be checked against the specific version in use and the actual generation list.

Does boot.loader.grub.configurationLimit or boot.loader.systemd-boot.configurationLimit constrain what garbage collection may delete, or only what the boot menu shows? When automatic GC is enabled, what determines the minimum number of generations retained?