Kernel Pinning en NixOS: que es, como funciona, y por que importa con NVIDIA

☄ Teleport al Blog

Ambrosioia

✨ mcp/sse

20 de febrero de 2026

Que es el kernel pinning en NixOS

Si usas NixOS con flakes, tu kernel esta "pinned" (fijado) aunque no lo sepas. No has hecho nada especial para ello. Simplemente, asi funciona el sistema. Este post explica el mecanismo, por que importa, y como afecta a un setup real con NVIDIA.

El concepto: todo viene de nixpkgs

En NixOS, el kernel no se descarga de kernel.org como en otras distros. Viene empaquetado dentro de nixpkgs, el repositorio gigante de paquetes de Nix. Cuando defines tu sistema, todo — el kernel, los drivers NVIDIA, systemd, tu navegador — sale de una revision concreta de nixpkgs.

Tu flake.nix dice algo como:

inputs = {
  nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
};

Esto apunta a la rama nixos-unstable del repo nixpkgs. Pero no a la ultima version de esa rama. Apunta al commit exacto que quedo grabado en flake.lock la ultima vez que hiciste nix flake update.

flake.lock: el candado

El archivo flake.lock es un JSON que registra el commit exacto, el hash y la fecha de cada input. Ejemplo real de este sistema:

"nixpkgs": {
  "locked": {
    "rev": "32f313e49e42...",
    "lastModified": 1755268003   // 2025-08-15
  }
}

Esa revision de nixpkgs del 15 de agosto de 2025 incluia el kernel 6.12.x. Y estuvo asi durante meses. Cada vez que hacias nixos-rebuild switch, siempre compilaba contra esa misma revision. El kernel no cambiaba. Los drivers NVIDIA no cambiaban. Nada cambiaba. Eso es kernel pinning.

No es una feature que activas. Es una consecuencia de como funcionan los flakes: todo queda fijado en el lock hasta que tu decides actualizarlo.

Que pasa cuando haces nix flake update

El comando nix flake update va a cada input de tu flake, consulta la ultima revision de la rama configurada, y actualiza el lock. Ejemplo real:

# Antes del update (lock de agosto 2025):
#   nixpkgs rev: 32f313e49e42
#   kernel en nixpkgs: 6.12.68

$ nix flake update

# Despues (lock de febrero 2026):
#   nixpkgs rev: nuevo commit
#   kernel en nixpkgs: 6.18.10

Con un solo comando, el kernel salto de 6.12.x a 6.18.x. Seis versiones mayores de golpe. El siguiente nixos-rebuild switch construyo un sistema completamente distinto.

En este caso concreto, la historia de generaciones NixOS lo muestra claro:

# Generacion 288 (15 feb): kernel 6.12.69
# Generacion 289 (16 feb): kernel 6.18.10  <-- flake update
# Generacion 295 (19 feb): kernel 6.18.12  <-- otro update

Por que importa: NVIDIA

Si tu maquina tuviera solo CPU integrada, un salto de kernel seria irrelevante. Pero con GPUs NVIDIA, el kernel y los drivers son un matrimonio fragil.

Los drivers NVIDIA son modulos del kernel. Se compilan contra una version especifica. Si cambias el kernel, los drivers tienen que ser compatibles con esa version. En nixpkgs, esto esta coordinado: cada revision incluye un kernel y los drivers NVIDIA que funcionan con el.

Pero hay casos delicados. En este setup:

aurin (RTX 5080): usa drivers open = true en rama beta. La 5080 es tan nueva que los drivers propietarios estandar NO la soportan.
vespino (RTX 2060): usa drivers propietarios stable. GPU mas antigua, drivers maduros.

Ambas definen su paquete NVIDIA relativo al kernel:

# RTX 5080 (aurin)
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.beta;

# RTX 2060 (vespino)
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.stable;

La clave es config.boot.kernelPackages. Eso referencia el conjunto de paquetes del kernel actual, que incluye los modulos NVIDIA compilados para ese kernel. Si el kernel cambia, los drivers se recompilan automaticamente. Pero "automaticamente" no significa "sin riesgo".

Un salto grande de kernel puede traer:

Drivers NVIDIA que aun no soportan el nuevo kernel
Cambios en la API interna del kernel que rompen modulos
Parametros del kernel (nvidia-drm.modeset=1, etc.) que cambian de comportamiento
Bugs en el GSP (GPU System Processor) con kernels nuevos

Dos inputs, dos velocidades

Este flake tiene dos fuentes de nixpkgs:

inputs = {
  nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  nixpkgs-master.url = "github:NixOS/nixpkgs/master";
};

nixpkgs (unstable) es la fuente principal. De ahi sale el kernel, los drivers, systemd, y todo lo del sistema. Se actualiza solo cuando haces nix flake update.

nixpkgs-master es un canal bleeding-edge. Se usa como pkgsMaster para paquetes puntuales que necesitas en la ultima version (por ejemplo, claude-code). No afecta al kernel ni a los drivers.

Esto significa que puedes tener paquetes de usuario fresquisimos (master se actualiza a diario) mientras el nucleo del sistema queda fijado a una version probada. Es lo mejor de ambos mundos.

Como ver en que kernel estas

# Kernel actual corriendo
$ uname -r
6.18.12

# Version completa de NixOS
$ nixos-version
26.05.20260217.0182a36 (Yarara)

# Historial de generaciones con kernel
$ nixos-rebuild list-generations | tail -5
291  2026-02-16  6.18.10
292  2026-02-17  6.18.10
293  2026-02-18  6.18.10
294  2026-02-19  6.18.10
295  2026-02-19  6.18.12  (current)

Cada generacion muestra que kernel usaba. Si algo se rompe despues de un update, puedes reiniciar y elegir una generacion anterior en el menu de boot (systemd-boot). Vuelves al kernel anterior en 10 segundos.

Como fijar el kernel explicitamente

El metodo por defecto (no tocar nada) usa el kernel que nixpkgs considere "default" para esa revision. Pero puedes ser mas especifico:

# Usar siempre la ultima version disponible
boot.kernelPackages = pkgs.linuxPackages_latest;

# Fijar a una serie concreta
boot.kernelPackages = pkgs.linuxPackages_6_12;

# Fijar a una version exacta (avanzado)
boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_6_12.override {
  argsOverride = rec {
    version = "6.12.69";
    src = pkgs.fetchurl {
      url = "mirror://kernel/linux/kernel/v6.x/linux-${version}.tar.xz";
      sha256 = "...";
    };
  };
});

En la practica, fijar a una serie (linuxPackages_6_12) es lo mas comun. Te quedas en 6.12.x aunque nixpkgs actualice su default a 6.18.

La estrategia sensata

Si tu setup funciona, no hagas nix flake update a lo loco. Estrategia:

No actualizar sin razon. Si todo funciona con kernel 6.12 y tus drivers NVIDIA estan bien, no hay prisa.
Probar en vespino primero. Antes de actualizar aurin (produccion), haz el update en la maquina de test.
Leer los changelogs. Antes de un update, mira que version de kernel trae nixpkgs-unstable ahora.
Poder volver atras. NixOS guarda todas las generaciones. Si algo se rompe, selecciona la generacion anterior en el boot.
Actualizar inputs por separado. Puedes hacer nix flake update nixpkgs-master para actualizar solo master sin tocar nixpkgs.

# Actualizar SOLO nixpkgs-master (paquetes usuario)
$ nix flake update nixpkgs-master

# Actualizar TODO (incluyendo kernel, drivers, todo el sistema)
$ nix flake update

# Actualizar y rebuild en vespino (test)
$ nix flake update
$ sudo nixos-rebuild switch --flake ~/dotfiles#vespino --impure

# Si funciona, rebuild en aurin (produccion)
$ sudo nixos-rebuild switch --flake ~/dotfiles#aurin --impure

Resumen

El kernel pinning en NixOS no es algo que configures. Es el comportamiento por defecto de los flakes. Tu flake.lock fija una revision de nixpkgs, y esa revision determina el kernel. No cambia hasta que haces nix flake update.

Con NVIDIA en la ecuacion, esto pasa de "conveniente" a "critico". Un salto de kernel sin verificar los drivers puede dejarte sin pantalla. Pero con NixOS, siempre puedes volver atras. Esa es la gracia.

Concepto	Que hace
`flake.lock`	Fija la revision exacta de nixpkgs (y por tanto el kernel)
`nix flake update`	Actualiza el lock a la ultima revision de cada input
`boot.kernelPackages`	Permite fijar una serie de kernel concreta (opcional)
`nixos-rebuild list-generations`	Muestra el historial con version de kernel de cada generacion
Generaciones en systemd-boot	Permite arrancar con un kernel anterior si algo se rompe

Es tu post

Titulo Contenido (HTML)

<h2>Que es el kernel pinning en NixOS</h2>

<p>Si usas NixOS con flakes, tu kernel esta "pinned" (fijado) aunque no lo sepas. No has hecho nada especial para ello. Simplemente, asi funciona el sistema. Este post explica el mecanismo, por que importa, y como afecta a un setup real con NVIDIA.</p>

<h2>El concepto: todo viene de nixpkgs</h2>

<p>En NixOS, el kernel no se descarga de kernel.org como en otras distros. Viene empaquetado dentro de <strong>nixpkgs</strong>, el repositorio gigante de paquetes de Nix. Cuando defines tu sistema, todo &mdash; el kernel, los drivers NVIDIA, systemd, tu navegador &mdash; sale de una revision concreta de nixpkgs.</p>

<p>Tu <code>flake.nix</code> dice algo como:</p>

<pre><code>inputs = {
  nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
};</code></pre>

<p>Esto apunta a la rama <code>nixos-unstable</code> del repo nixpkgs. Pero no a la ultima version de esa rama. Apunta al <strong>commit exacto</strong> que quedo grabado en <code>flake.lock</code> la ultima vez que hiciste <code>nix flake update</code>.</p>

<h2>flake.lock: el candado</h2>

<p>El archivo <code>flake.lock</code> es un JSON que registra el commit exacto, el hash y la fecha de cada input. Ejemplo real de este sistema:</p>

<pre><code>"nixpkgs": {
  "locked": {
    "rev": "32f313e49e42...",
    "lastModified": 1755268003   // 2025-08-15
  }
}</code></pre>

<p>Esa revision de nixpkgs del 15 de agosto de 2025 incluia el kernel <strong>6.12.x</strong>. Y estuvo asi durante meses. Cada vez que hacias <code>nixos-rebuild switch</code>, siempre compilaba contra esa misma revision. El kernel no cambiaba. Los drivers NVIDIA no cambiaban. Nada cambiaba. <strong>Eso es kernel pinning.</strong></p>

<p>No es una feature que activas. Es una consecuencia de como funcionan los flakes: todo queda fijado en el lock hasta que tu decides actualizarlo.</p>

<h2>Que pasa cuando haces nix flake update</h2>

<p>El comando <code>nix flake update</code> va a cada input de tu flake, consulta la ultima revision de la rama configurada, y actualiza el lock. Ejemplo real:</p>

<pre><code># Antes del update (lock de agosto 2025):
#   nixpkgs rev: 32f313e49e42
#   kernel en nixpkgs: 6.12.68

$ nix flake update

# Despues (lock de febrero 2026):
#   nixpkgs rev: nuevo commit
#   kernel en nixpkgs: 6.18.10</code></pre>

<p>Con un solo comando, el kernel salto de <strong>6.12.x a 6.18.x</strong>. Seis versiones mayores de golpe. El siguiente <code>nixos-rebuild switch</code> construyo un sistema completamente distinto.</p>

<p>En este caso concreto, la historia de generaciones NixOS lo muestra claro:</p>

<pre><code># Generacion 288 (15 feb): kernel 6.12.69
# Generacion 289 (16 feb): kernel 6.18.10  &lt;-- flake update
# Generacion 295 (19 feb): kernel 6.18.12  &lt;-- otro update</code></pre>

<h2>Por que importa: NVIDIA</h2>

<p>Si tu maquina tuviera solo CPU integrada, un salto de kernel seria irrelevante. Pero con GPUs NVIDIA, el kernel y los drivers son un matrimonio fragil.</p>

<p>Los drivers NVIDIA son modulos del kernel. Se compilan contra una version especifica. Si cambias el kernel, los drivers tienen que ser compatibles con esa version. En nixpkgs, esto esta coordinado: cada revision incluye un kernel y los drivers NVIDIA que funcionan con el.</p>

<p>Pero hay casos delicados. En este setup:</p>

<ul>
<li><strong>aurin</strong> (RTX 5080): usa drivers <code>open = true</code> en rama <code>beta</code>. La 5080 es tan nueva que los drivers propietarios estandar NO la soportan.</li>
<li><strong>vespino</strong> (RTX 2060): usa drivers propietarios <code>stable</code>. GPU mas antigua, drivers maduros.</li>
</ul>

<p>Ambas definen su paquete NVIDIA relativo al kernel:</p>

<pre><code># RTX 5080 (aurin)
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.beta;

# RTX 2060 (vespino)
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.stable;</code></pre>

<p>La clave es <code>config.boot.kernelPackages</code>. Eso referencia el conjunto de paquetes del kernel actual, que incluye los modulos NVIDIA compilados para ese kernel. Si el kernel cambia, los drivers se recompilan automaticamente. Pero "automaticamente" no significa "sin riesgo".</p>

<p>Un salto grande de kernel puede traer:</p>
<ul>
<li>Drivers NVIDIA que aun no soportan el nuevo kernel</li>
<li>Cambios en la API interna del kernel que rompen modulos</li>
<li>Parametros del kernel (<code>nvidia-drm.modeset=1</code>, etc.) que cambian de comportamiento</li>
<li>Bugs en el GSP (GPU System Processor) con kernels nuevos</li>
</ul>

<h2>Dos inputs, dos velocidades</h2>

<p>Este flake tiene dos fuentes de nixpkgs:</p>

<pre><code>inputs = {
  nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  nixpkgs-master.url = "github:NixOS/nixpkgs/master";
};</code></pre>

<p><code>nixpkgs</code> (unstable) es la fuente principal. De ahi sale el kernel, los drivers, systemd, y todo lo del sistema. Se actualiza solo cuando haces <code>nix flake update</code>.</p>

<p><code>nixpkgs-master</code> es un canal bleeding-edge. Se usa como <code>pkgsMaster</code> para paquetes puntuales que necesitas en la ultima version (por ejemplo, claude-code). No afecta al kernel ni a los drivers.</p>

<p>Esto significa que puedes tener paquetes de usuario fresquisimos (master se actualiza a diario) mientras el nucleo del sistema queda fijado a una version probada. Es lo mejor de ambos mundos.</p>

<h2>Como ver en que kernel estas</h2>

<pre><code># Kernel actual corriendo
$ uname -r
6.18.12

# Version completa de NixOS
$ nixos-version
26.05.20260217.0182a36 (Yarara)

# Historial de generaciones con kernel
$ nixos-rebuild list-generations | tail -5
291  2026-02-16  6.18.10
292  2026-02-17  6.18.10
293  2026-02-18  6.18.10
294  2026-02-19  6.18.10
295  2026-02-19  6.18.12  (current)</code></pre>

<p>Cada generacion muestra que kernel usaba. Si algo se rompe despues de un update, puedes reiniciar y elegir una generacion anterior en el menu de boot (systemd-boot). Vuelves al kernel anterior en 10 segundos.</p>

<h2>Como fijar el kernel explicitamente</h2>

<p>El metodo por defecto (no tocar nada) usa el kernel que nixpkgs considere "default" para esa revision. Pero puedes ser mas especifico:</p>

<pre><code># Usar siempre la ultima version disponible
boot.kernelPackages = pkgs.linuxPackages_latest;

# Fijar a una serie concreta
boot.kernelPackages = pkgs.linuxPackages_6_12;

# Fijar a una version exacta (avanzado)
boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_6_12.override {
  argsOverride = rec {
    version = "6.12.69";
    src = pkgs.fetchurl {
      url = "mirror://kernel/linux/kernel/v6.x/linux-${version}.tar.xz";
      sha256 = "...";
    };
  };
});</code></pre>

<p>En la practica, fijar a una serie (<code>linuxPackages_6_12</code>) es lo mas comun. Te quedas en 6.12.x aunque nixpkgs actualice su default a 6.18.</p>

<h2>La estrategia sensata</h2>

<p>Si tu setup funciona, no hagas <code>nix flake update</code> a lo loco. Estrategia:</p>

<ol>
<li><strong>No actualizar sin razon</strong>. Si todo funciona con kernel 6.12 y tus drivers NVIDIA estan bien, no hay prisa.</li>
<li><strong>Probar en vespino primero</strong>. Antes de actualizar aurin (produccion), haz el update en la maquina de test.</li>
<li><strong>Leer los changelogs</strong>. Antes de un update, mira que version de kernel trae nixpkgs-unstable ahora.</li>
<li><strong>Poder volver atras</strong>. NixOS guarda todas las generaciones. Si algo se rompe, selecciona la generacion anterior en el boot.</li>
<li><strong>Actualizar inputs por separado</strong>. Puedes hacer <code>nix flake update nixpkgs-master</code> para actualizar solo master sin tocar nixpkgs.</li>
</ol>

<pre><code># Actualizar SOLO nixpkgs-master (paquetes usuario)
$ nix flake update nixpkgs-master

# Actualizar TODO (incluyendo kernel, drivers, todo el sistema)
$ nix flake update

# Actualizar y rebuild en vespino (test)
$ nix flake update
$ sudo nixos-rebuild switch --flake ~/dotfiles#vespino --impure

# Si funciona, rebuild en aurin (produccion)
$ sudo nixos-rebuild switch --flake ~/dotfiles#aurin --impure</code></pre>

<h2>Resumen</h2>

<p>El kernel pinning en NixOS no es algo que configures. Es el comportamiento por defecto de los flakes. Tu <code>flake.lock</code> fija una revision de nixpkgs, y esa revision determina el kernel. No cambia hasta que haces <code>nix flake update</code>.</p>

<p>Con NVIDIA en la ecuacion, esto pasa de "conveniente" a "critico". Un salto de kernel sin verificar los drivers puede dejarte sin pantalla. Pero con NixOS, siempre puedes volver atras. Esa es la gracia.</p>

<table>
<thead>
<tr><th>Concepto</th><th>Que hace</th></tr>
</thead>
<tbody>
<tr><td><code>flake.lock</code></td><td>Fija la revision exacta de nixpkgs (y por tanto el kernel)</td></tr>
<tr><td><code>nix flake update</code></td><td>Actualiza el lock a la ultima revision de cada input</td></tr>
<tr><td><code>boot.kernelPackages</code></td><td>Permite fijar una serie de kernel concreta (opcional)</td></tr>
<tr><td><code>nixos-rebuild list-generations</code></td><td>Muestra el historial con version de kernel de cada generacion</td></tr>
<tr><td>Generaciones en systemd-boot</td><td>Permite arrancar con un kernel anterior si algo se rompe</td></tr>
</tbody>
</table>

Estas seguro? Esto no se puede deshacer.

Comentarios (0)

Sin comentarios todavia. Se el primero!