🛠️ Problemas al configurar Arch Linux en LXC sobre Proxmox (Guía avanzada)

El self-hosting con contenedores es un reto maravilloso, pero la plantilla de Arch Linux para LXC no viene lista para usar. Hay tres pasos que conviene hacer nada más crear el contenedor; si te los saltas, pacman no podrá descargar ni instalar nada.

A continuación, te detallo los problemas más comunes y cómo abordarlos.

1. Fallo con la Mirrorlist Inicial (Problema de Red)

En la plantilla de Arch, todos los servidores de /etc/pacman.d/mirrorlist vienen comentados. Por eso pacman falla al actualizar la base de datos de paquetes: no sabe dónde buscar los repositorios.

⚠️ Solución: Abre el archivo como root dentro del contenedor y quita el # de las líneas #Server = ... de los espejos más cercanos a tu ubicación (con dos o tres basta):

nano /etc/pacman.d/mirrorlist

2. Actualización de Claves Pacman (Keyring)

Una vez resuelto el mirror list, pacman necesita su base de claves GPG para poder verificar las firmas de los paquetes. Sin ella, rechazará todo lo que descargue.

Ejecuta estos comandos dentro del contenedor LXC recién instalado:

# 1. Inicializar la base de datos de claves
pacman-key --init

# 2. Poblar la base con las claves de Arch Linux
pacman-key --populate archlinux

# 3. Actualizar el sistema completo
pacman -Syu

3. Conflictos de Kernel y Bloqueo (El problema del Landlock)

Desde la versión 7, pacman descarga los paquetes en un sandbox: un proceso con un usuario sin privilegios (alpm), restringido con Landlock (un módulo de seguridad del kernel) y con filtros de llamadas al sistema. Dentro de un LXC, ese sandbox puede no llegar a crearse, porque el contenedor usa el kernel del host Proxmox y depende de cómo esté configurado. Verás errores como:

error: restricting filesystem access failed because landlock is not supported by the kernel!

Hay dos formas de resolverlo.

Opción A (recomendada): desactivar el sandbox de pacman en el contenedor

Edita /etc/pacman.conf y añade estas dos líneas dentro de la sección [options] (si ya existen comentadas, quítales el #). Son opciones de tipo interruptor: se escriben sin = true.

[options]
DisableSandboxFilesystem
DisableSandboxSyscalls

En pacman 7.0 la opción equivalente es una sola línea: DisableSandbox.

⚠️ Qué riesgo asumes: el sandbox solo protege la fase de descarga. Si un espejo o una conexión maliciosa lograra explotar un fallo en el código de descarga, ese código se ejecutaría como root dentro del contenedor, en lugar de quedar encerrado en el usuario alpm. Los paquetes siguen verificándose con sus firmas GPG, y el aislamiento del LXC frente al host no cambia. Es un riesgo acotado, aceptable en un homelab.

Opción B: activar Landlock en el host

Comprueba en el host Proxmox si Landlock está activo:

cat /sys/kernel/security/lsm

Si landlock no aparece en la lista, puedes añadirlo al parámetro lsm= de la línea de arranque del kernel del host. Esto requiere reiniciar el host y afecta a todas las VMs y contenedores, así que hazlo solo si sabes lo que estás cambiando.

🚫 Lo que no debes hacer

No conviertas el contenedor en privilegiado para que pacman funcione. En un LXC privilegiado, el root del contenedor es el root del host, así que cualquier fallo de aislamiento compromete todo el servidor. Es un precio mucho mayor que desactivar el sandbox de pacman.

---

📝 Checklist Resumen de Tareas:

1. Descomentar dos o tres espejos cercanos en /etc/pacman.d/mirrorlist.
2. Ejecutar pacman-key --init y pacman-key --populate archlinux.
3. Actualizar con pacman -Syu.
4. Si aparece el error de Landlock: añadir DisableSandboxFilesystem y DisableSandboxSyscalls en [options] de /etc/pacman.conf (o DisableSandbox en pacman 7.0), o activar Landlock en el kernel del host.
5. Mantener el contenedor como no privilegiado.