Instalación de Void Linux: la distro minimalista que se siente sorprendentemente moderna

Por qué Void se siente moderno a pesar de ser minimalista

Void Linux es minimalista en un sentido que tiene sentido operativo. No recibes un enredo de “servicios de marco” que no pediste.
Obtienes un sistema de archivos limpio, un gestor de paquetes sensato y un sistema init que prefiere claridad sobre ambición.
Esa última parte importa: el perfil de fiabilidad de un sistema a menudo lo dictan el arranque y la supervisión de servicios.

Void usa runit para init y supervisión. No es algo de moda. Sin embargo, es notablemente directo:
los servicios son directorios con scripts run; la habilitación es un enlace simbólico; los logs pueden manejarse con un servicio compañero.
Cuando algo falla, normalmente puedes ver exactamente qué intentó ejecutar y por qué no funcionó.

El gestor de paquetes es xbps. Es rápido, consistente y refrescantemente poco teatral.
No hay una “ópera del resolvedor de dependencias” antes de cada transacción. Instala paquetes, verifica integridad y sigue.
Para una distro minimalista, esa es la modernidad correcta: centrarse en la mecánica que reduce la fricción operativa.

Una cita que debería imprimirse en el interior de la tapa de cada portátil:
Idea parafraseada (Werner Vogels): todo falla eventualmente; diseña sistemas para que la falla sea esperada y recuperable.

La fuerza de Void es que no finge que la falla no ocurrirá. Te da menos piezas móviles y mejor visibilidad.
Eso no elimina los errores. Simplemente los hace más fáciles de diagnosticar, y esa es la verdadera victoria.

Datos y contexto interesantes (las partes que la gente olvida)

• Void es independiente: no deriva de Debian/Ubuntu/Fedora. Esa independencia se refleja en las herramientas y los valores por defecto.
• Línea de runit: runit data de principios de los 2000 y se ha usado en contextos de producción como sistemas embebidos y appliances.
• xbps no es un wrapper: es un sistema de paquetes nativo (paquetes binarios + repositorios), no una interfaz de otro gestor.
• Compilaciones glibc y musl: Void mantiene ambas, permitiéndote elegir compatibilidad (glibc) o una libc más pequeña (musl).
• Lanzamiento rolling, pero curado: es rolling, sin embargo los paquetes tienden a ser coherentes—menos “ruleta de reconstrucción diaria”.
• Filosofía del instalador: la ISO live es intencionalmente espartana; no obtienes un asistente que oculte el diseño del disco tras animaciones alegres.
• Modelo por etapas de runit: el arranque se divide en etapas, y el “árbol de supervisión de servicios” es explícito en lugar de emergente.
• xbps-alternatives: Void usa un sistema de alternativas para gestionar implementaciones predeterminadas (p. ej., qué editor es “vi”).
• XBPS guarda metadatos localmente: puedes inspeccionar qué está instalado y por qué con consultas simples, sin llamar a casa.

Broma 1/2: Void se llama “Void” porque empieza vacío; la ventaja es que también empieza sin drama.

Decisiones que debes tomar antes de bootear el instalador

glibc vs musl

Elige glibc salvo que tengas una razón específica para no hacerlo. La mayoría de binarios de terceros asumen glibc.
musl es excelente para ciertas cargas de trabajo (algo estático, contenedores, sistemas más pequeños), pero puede ser un impuesto de compatibilidad
que no quieres en un equipo de uso diario o estación de trabajo.

UEFI vs BIOS legacy

Si tu máquina es de la última década, casi con toda seguridad usa UEFI. Úsalo correctamente:
particionado GPT, una partición EFI (ESP) y un gestor de arranque que coincida con tu modelo de amenaza y tolerancia a trastear.

Elección del sistema de archivos (la bifurcación aburrida que importa después)

Si quieres un sistema de archivos que se comporte, elige ext4.
Si trabajas con archivos enormes y te importa E/S paralela, XFS está bien (pero respeta el redimensionado).
Si quieres snapshots y estás dispuesto a aprender disciplina operativa, btrfs puede ser excelente.
Si eres un especialista en almacenamiento y quieres checksumming + send/receive a escala, ZFS es una opción legítima—solo no finjas que es “configurar y olvidar.”

Cifrado

Para portátiles y cualquier cosa que salga del rack, usa cifrado de disco completo. LUKS2 es la opción habitual.
Las dos preguntas reales: ¿quieres un /boot separado sin cifrar, y necesitas desbloqueo remoto?
Si no lo sabes, mantenlo simple: ESP sin cifrar, raíz cifrada y acepta teclear una frase de paso en el arranque.

Swap e hibernación

Si hibernas, necesitas swap dimensionado apropiadamente y configurado correctamente.
Si no, el swap sigue siendo útil como válvula de presión. Un pequeño archivo o partición de swap está bien.
No hagas “no swap nunca” por costumbre, a menos que disfrutes ver cómo el OOM killer liquida compiladores.

Instalación: una guía práctica (UEFI + ext4 + opción de cifrado)

El instalador de Void es directo. El modo de fallo más común no es “el instalador está roto.”
Es “hiciste una suposición sobre el diseño del disco que no verificaste.”
Así que verificaremos todo a medida que avanzamos, y preferiremos comandos que muestren su trabajo.

Paso 0: arranca la ISO live y confirma el modo del firmware

Si crees que estás en modo UEFI pero no lo estás, tu ESP se quedará ahí como un cajón bien etiquetado en una casa sin puertas.

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  fw_platform_size  runtime  runtime-map  systab

Qué significa la salida: Si /sys/firmware/efi existe y contiene entradas, iniciaste en modo UEFI.
Decisión: Procede con GPT + ESP. Si falta, reinicia y selecciona la entrada de arranque UEFI en el firmware.

Paso 1: identifica el disco objetivo (no adivines)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL
NAME   SIZE TYPE FSTYPE MODEL
sda   476.9G disk        Samsung SSD 860
├─sda1  512M part vfat
└─sda2 476.4G part

Qué significa la salida: Ves discos y particiones, con tamaños y (si están) tipos de sistema de archivos.
Decisión: Confirma que vas a instalar en el dispositivo correcto (/dev/sda aquí). Si estás en un servidor con múltiples discos, detente y etiquétalos.

Paso 2: particionar (ejemplo de diseño)

Diseño UEFI mínimo:
una ESP (512 MiB) + una partición root (el resto). Si cifras, la raíz será un contenedor LUKS.

cr0x@server:~$ sudo parted -s /dev/sda mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sda mkpart ESP fat32 1MiB 513MiB
cr0x@server:~$ sudo parted -s /dev/sda set 1 esp on
cr0x@server:~$ sudo parted -s /dev/sda mkpart primary 513MiB 100%
cr0x@server:~$ sudo parted -s /dev/sda print
Model: Samsung SSD 860 (scsi)
Disk /dev/sda: 512GB
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB                ESP   boot, esp
 2      538MB   512GB   511GB                primary

Qué significa la salida: Existe GPT, la partición 1 está marcada como ESP, la partición 2 es la carga principal.
Decisión: Si las banderas no muestran boot, esp en la partición 1, arréglalo ahora. Los problemas de arranque UEFI suelen ser autoinfligidos.

Paso 3: formatear sistemas de archivos (ruta sin cifrado)

cr0x@server:~$ sudo mkfs.vfat -F32 -n EFI /dev/sda1
mkfs.fat 4.2 (2021-01-31)
cr0x@server:~$ sudo mkfs.ext4 -L void-root /dev/sda2
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 124999680 4k blocks and 31250432 inodes
Filesystem UUID: 9f6b7f39-3c4a-4cb2-8f54-5c3c2f9911a2
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000

Qué significa la salida: La ESP es FAT32, la raíz es ext4 con una etiqueta y UUID.
Decisión: Si planeas usar cifrado, no formatees /dev/sda2 como ext4 todavía—usa la ruta cifrada a continuación.

Paso 3b: ruta de cifrado (LUKS2 + ext4 dentro)

cr0x@server:~$ sudo cryptsetup luksFormat /dev/sda2
WARNING: Device /dev/sda2 already contains a 'ext4' superblock signature.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda2:
Verify passphrase:
cr0x@server:~$ sudo cryptsetup open /dev/sda2 cryptroot
Enter passphrase for /dev/sda2:
cr0x@server:~$ sudo mkfs.ext4 -L void-root /dev/mapper/cryptroot
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 124900352 4k blocks and 31227904 inodes
Filesystem UUID: 5c1a1d6b-6a4f-4b2e-88fb-f0b4af56c0a3

Qué significa la salida: La partición ahora es un contenedor cifrado, abierto como /dev/mapper/cryptroot, y ext4 vive dentro de él.
Decisión: Anota el UUID de LUKS más tarde para crypttab/dracut. También decide si necesitas un keyfile (normalmente no en portátiles).

Paso 4: montar el diseño objetivo

cr0x@server:~$ sudo mount /dev/mapper/cryptroot /mnt
cr0x@server:~$ sudo mkdir -p /mnt/boot/efi
cr0x@server:~$ sudo mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount | grep -E '(/mnt|efi)'
/dev/mapper/cryptroot on /mnt type ext4 (rw,relatime)
/dev/sda1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Qué significa la salida: La raíz y la ESP están montadas donde el instalador colocará el sistema y los artefactos de arranque.
Decisión: Si la ESP está montada en otro lugar, arréglalo. Quieres un único punto de montaje ESP obvio.

Paso 5: ejecuta el instalador y mantenlo honesto

Void proporciona un instalador TUI. Úsalo. Pero verifica lo que hizo: ahora eres el ingeniero on-call, no el instalador.

Después de la instalación, chrootea o arranca en el nuevo sistema y verifica lo fundamental: fstab, bootloader, initramfs, red, hora, usuarios.
El resto son preferencias.

Paso 6: mentalidad de validación en el primer arranque

Tu primer arranque no es “llega a un indicador de login.” Tu primer arranque es “entiendo cómo se comportará en el peor día de mi semana.”
Eso significa: cómo inician los servicios, dónde van los logs, cómo se aplican las actualizaciones y cómo se recupera la máquina si la red falla.

Tareas prácticas: comandos, salidas y qué decides después

Estas son las comprobaciones que hago en cualquier instalación fresca. No son ceremoniales.
Cada una está ahí porque he visto la ausencia de la misma convertirse en un ticket.

Tarea 1: confirma que arrancaste con el kernel que crees haber instalado

cr0x@server:~$ uname -a
Linux voidbox 6.6.15_1 #1 SMP PREEMPT_DYNAMIC Thu Jan 18 10:22:01 UTC 2024 x86_64 GNU/Linux

Qué significa la salida: Versión del kernel y arquitectura.
Decisión: Si el kernel es más antiguo de lo esperado, probablemente arrancaste la entrada equivocada o no instalaste el paquete meta del kernel que querías.

Tarea 2: revisa UUIDs y etiquetas de disco antes de escribir fstab

cr0x@server:~$ blkid
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7C2A-1B3D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="e2b7c5a1-6d8d-4e5c-a2b3-7f3a0d4b9b0c"
/dev/sda2: UUID="f1b2c3d4-1111-2222-3333-abcdefabcdef" TYPE="crypto_LUKS" PARTUUID="7a9c8d6e-aaaa-bbbb-cccc-1234567890ab"
/dev/mapper/cryptroot: LABEL="void-root" UUID="5c1a1d6b-6a4f-4b2e-88fb-f0b4af56c0a3" BLOCK_SIZE="4096" TYPE="ext4"

Qué significa la salida: Identificadores estables para montajes y mapeo de cifrado.
Decisión: Usa UUIDs en /etc/fstab y (si está cifrado) en tu cmdline/config de dracut; evita /dev/sdaX crudos.

Tarea 3: valida opciones de montaje y espacio disponible

cr0x@server:~$ df -hT
Filesystem              Type   Size  Used Avail Use% Mounted on
/dev/mapper/cryptroot   ext4   468G  2.6G  441G   1% /
/dev/sda1               vfat   511M   12M  500M   3% /boot/efi
tmpfs                   tmpfs  3.1G     0  3.1G   0% /run

Qué significa la salida: Tipos de sistemas de archivos, tamaños y puntos de montaje.
Decisión: Asegúrate de que /boot/efi no esté en el sistema de archivos raíz. Si lo está, tus artefactos UEFI podrían no ser persistentes.

Tarea 4: comprueba que init es realmente runit

cr0x@server:~$ ps -p 1 -o pid,comm,args
  PID COMMAND         COMMAND
    1 runit           runit

Qué significa la salida: PID 1 es runit.
Decisión: Si PID 1 no es runit, no estás en Void como esperabas, o estás en un contenedor/chroot.

Tarea 5: lista los servicios habilitados (lo que arrancará al inicio)

cr0x@server:~$ ls -l /var/service
total 0
lrwxrwxrwx 1 root root  16 Jan 20 09:10 dhcpcd -> /etc/sv/dhcpcd
lrwxrwxrwx 1 root root  14 Jan 20 09:10 sshd -> /etc/sv/sshd
lrwxrwxrwx 1 root root  15 Jan 20 09:10 socklog-unix -> /etc/sv/socklog-unix
lrwxrwxrwx 1 root root  13 Jan 20 09:10 nanoklogd -> /etc/sv/nanoklogd

Qué significa la salida: Cada symlink es un servicio habilitado supervisado por runit.
Decisión: Si falta algo crítico (red, logging, ssh para cajas remotas), actívalo ahora en lugar de descubrirlo durante una caída.

Tarea 6: revisa el estado del servicio como un adulto (no por vibras)

cr0x@server:~$ sudo sv status sshd
run: sshd: (pid 842) 37s

Qué significa la salida: El servicio está en ejecución, con PID y tiempo activo.
Decisión: Si indica down o fail, abre el run script y los logs antes de cambiar configuraciones al azar.

Tarea 7: verifica que existan logs y se estén recopilando

cr0x@server:~$ sudo sv status socklog-unix
run: socklog-unix: (pid 520) 5m12s
cr0x@server:~$ sudo ls -lah /var/log/socklog
total 16K
drwx------  4 root root 4.0K Jan 20 09:11 .
drwxr-xr-x 11 root root 4.0K Jan 20 09:11 ..
drwx------  2 root root 4.0K Jan 20 09:11 kernel
drwx------  2 root root 4.0K Jan 20 09:11 sshd

Qué significa la salida: socklog está en ejecución y escribe logs por servicio.
Decisión: Si faltan logs, arregla el registro antes de “optimizar rendimiento.” No puedes optimizar lo que no puedes observar.

Tarea 8: verifica la configuración de repositorios y realiza una sincronización segura

cr0x@server:~$ xbps-query -L
 997 https://repo-default.voidlinux.org/current (RSA signed)
cr0x@server:~$ sudo xbps-install -S
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1824KB [avg rate: 410KB/s]

Qué significa la salida: Los repos están configurados y la actualización de metadatos es limpia.
Decisión: Si la verificación de firmas falla, detente. Arregla la sincronización de tiempo, las URLs de repositorio o el estado de las claves antes de instalar nada más.

Tarea 9: audita qué sostiene tu sistema base

cr0x@server:~$ xbps-query -m | head
base-system-0.114_1
linux6.6-6.6.15_1
linux-firmware-20240115_1
runit-2.1.2_12
xbps-0.59.2_2

Qué significa la salida: Los metapaquetes proporcionan la línea base “esto parece un sistema”.
Decisión: Mantén base-system a menos que tengas una razón bien documentada para desviarte.

Tarea 10: comprueba la resolución DNS (porque “red arriba” no es lo mismo que “usable”)

cr0x@server:~$ getent hosts repo-default.voidlinux.org
2a04:4e42:600::644  repo-default.voidlinux.org
2a04:4e42::644       repo-default.voidlinux.org

Qué significa la salida: La resolución de nombres funciona vía NSS, devolviendo IPs.
Decisión: Si esto falla pero puedes hacer ping a una IP, el problema es la configuración DNS—normalmente la propiedad de /etc/resolv.conf o el cliente DHCP.

Tarea 11: confirma la sincronización de tiempo (TLS y firmas de paquetes importan)

cr0x@server:~$ date -u
Sat Jan 20 09:18:44 UTC 2024

Qué significa la salida: Hora UTC actual.
Decisión: Si está mal por minutos/horas, arregla NTP (p. ej., chrony) antes de culpar al “SSL roto” por descargas de paquetes.

Tarea 12: valida que existan entradas de arranque (verificación UEFI)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001
Boot0001* UEFI: Built-in EFI Shell	RC
Boot0003* VoidLinux	HD(1,GPT,e2b7c5a1-6d8d-4e5c-a2b3-7f3a0d4b9b0c,0x800,0x100000)/File(\EFI\void\grubx64.efi)

Qué significa la salida: Tu firmware ve una entrada VoidLinux apuntando a un binario EFI en la ESP.
Decisión: Si no hay entrada, arrancarás por suerte. Arregla la instalación del bootloader antes de reiniciar y entrar en confusión.

Tarea 13: inspecciona la generación de initramfs (especialmente para cifrado)

cr0x@server:~$ ls -lh /boot | head
total 88M
-rw-r--r-- 1 root root  32M Jan 20 09:05 initramfs-6.6.15_1.img
-rw-r--r-- 1 root root  12M Jan 20 09:05 vmlinuz-6.6.15_1
drwxr-xr-x 3 root root 4.0K Jan 20 09:05 grub

Qué significa la salida: Kernel e initramfs existen y tienen un tamaño plausible.
Decisión: Si falta initramfs, el arranque puede fallar tras actualizaciones del kernel. Asegura que los ganchos de dracut estén instalados y configurados.

Tarea 14: confirma el estado TRIM en SSD (higiene de almacenamiento)

cr0x@server:~$ lsblk -D
NAME          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                  0      512B       2G         0
├─sda1               0      512B       2G         0
└─sda2               0      512B       2G         0

Qué significa la salida: Granularidad de discard y tamaño máximo expuestos.
Decisión: Habilita fstrim periódico (o monta con discard solo si aceptas sus tradeoffs). Si los valores son cero, el dispositivo puede no soportar TRIM.

Tarea 15: verifica conceptos básicos de presión de memoria (no envíes una caja que muera compilando)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.1Gi       5.6Gi       120Mi       1.0Gi       6.3Gi
Swap:          2.0Gi          0B       2.0Gi

Qué significa la salida: Tienes swap y memoria disponible razonable.
Decisión: Si falta swap en un portátil, añádelo. Si el swap es enorme en un SSD pequeño, reconsidera—el desgaste es real, pero la estabilidad también.

runit: gestión de servicios que no te hará dudar de la realidad

r u n i t no es una marca de estilo de vida. Es un supervisor. Ejecuta servicios, los reinicia cuando se caen
y proporciona una interfaz consistente para comprobar estado y gestionarlos.
El modelo mental es: “un servicio es un directorio con un script ejecutable run.”

Habilitar y deshabilitar servicios

Habilitar es un enlace simbólico dentro de /var/service. Deshabilitar elimina ese enlace.
Esto es tan obvio que parece sospechosamente que debería ser más complicado. No lo es.

cr0x@server:~$ sudo ln -s /etc/sv/sshd /var/service
cr0x@server:~$ sudo sv status sshd
run: sshd: (pid 1123) 4s

Qué significa la salida: Una vez que el enlace existe, runit supervisa el servicio inmediatamente.
Decisión: Si un servicio arranca inesperadamente al habilitarse, no es sorpresa; es el contrato. Planifica los cambios en consecuencia.

Dónde vive la configuración

Los scripts run de servicios viven bajo /etc/sv/<service>/run. Muchos servicios también tienen /etc/sv/<service>/conf.
Si quieres cambiar cómo arranca un servicio, lo haces allí, no esperando que un generador de unit files detecte tu estado de ánimo.

El registro es una preocupación de primera clase (si lo eliges)

Un patrón común es un directorio log separado bajo el servicio, gestionado por svlogd.
Eso te da logs locales predecibles sin suponer systemd-journal.
Si centralizas logs (y deberías, para algo importante), conserva logs locales de todos modos.
Son la caja negra cuando la red está en llamas.

Elecciones de almacenamiento: ext4, XFS, btrfs, ZFS (y lo que yo elegiría)

El almacenamiento es donde las distros minimalistas o brillan o implosionan. Void te da opciones sin imponer ninguna.
Eso es bueno. Pero también significa que puedes construir una frágil snowflake.

ext4: el predeterminado por el que no debes disculparte

ext4 es aburrido en el mejor sentido. Las herramientas de recuperación están maduras, el rendimiento es consistente y la mayoría de los modos de fallo son conocidos.
Si tu objetivo es “estación de trabajo que siempre arranca” o “servidor que no sorprenda”, ext4 es una sólida línea base.

XFS: rápido, estable, pero respeta los límites

XFS adora la E/S paralela y los sistemas de archivos grandes. También espera que seas deliberado sobre procedimientos de crecimiento y reparación.
Si estás acostumbrado a redimensionar particiones y sistemas de archivos en órdenes aleatorios, aprende la secuencia correcta primero.

btrfs: funciones con obligaciones operativas

Snapshots, subvolúmenes, send/receive—btrfs puede hacer que rollback y backups sean más limpios.
Pero btrfs no es “fiabilidad gratis.” Es “herramientas potentes.” Necesitas monitorización, calendarios de scrub y un plan sobre qué significan los snapshots para el uso del disco.

ZFS: genial si lo tratas como un sistema de almacenamiento, no solo como un sistema de archivos

ZFS es excelente en integridad de datos (checksums) y flujos de replicación (send/receive).
También es un ecosistema distinto: consideraciones de módulos kernel, expectativas de memoria y un modelo operativo que recompensa la disciplina.
Si instalas Void en un portátil, la raíz en ZFS es posible, pero lo recomendaría solo si ya sabes por qué la quieres.

Broma 2/2: cada vez que dices “usaré ZFS solo por los snapshots,” un futuro tú programa un turno extra el fin de semana.

Redes: Wi‑Fi, DHCP, DNS y las partes aburridas

La red no es difícil. La red es alérgica a las suposiciones.
Void no oculta la red tras un gestor monolítico a menos que lo instales. Puedes mantenerlo simple.

DHCP con dhcpcd

dhcpcd se usa comúnmente en Void. Habilítalo, verifica que esté en ejecución y confirma que realmente configuró rutas y DNS.

cr0x@server:~$ sudo sv status dhcpcd
run: dhcpcd: (pid 610) 8m44s
cr0x@server:~$ ip route
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.50 metric 100
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.50 metric 100

Qué significa la salida: La ruta por defecto existe y apunta a un gateway en la interfaz esperada.
Decisión: Si falta la ruta por defecto, no tienes “un problema de DNS.” Tienes “sin camino a Internet.” Arregla DHCP o la configuración estática primero.

Wi‑Fi con wpa_supplicant (práctico y explícito)

Si prefieres NetworkManager, instálalo. Si prefieres configuraciones transparentes, wpa_supplicant está bien.
El requisito principal es: guarda configuraciones con permisos correctos y asegura que el servicio arranque al inicio.

cr0x@server:~$ sudo install -d -m 0700 /etc/wpa_supplicant
cr0x@server:~$ sudo wpa_passphrase "CorpWiFi" "correct horse battery staple" | sudo tee /etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf >/dev/null
cr0x@server:~$ sudo chmod 600 /etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf
cr0x@server:~$ sudo ln -s /etc/sv/wpa_supplicant /var/service
cr0x@server:~$ sudo sv status wpa_supplicant
run: wpa_supplicant: (pid 1337) 2s

Qué significa la salida: La configuración se creó, se aseguró y el servicio está en ejecución.
Decisión: Si funciona pero no se asocia, comprueba nombres de interfaz y dominio regulatorio; no culpes inmediatamente a los “drivers.”

DNS: guerras por la propiedad de resolv.conf

Las fallas de DNS a menudo provienen de que resolv.conf es sobrescrito (o no) por componentes distintos.
Decide quién lo posee: dhcpcd, resolvconf, NetworkManager o tu propio archivo estático. Luego haz que eso sea verdad.

cr0x@server:~$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 46 Jan 20 09:12 /etc/resolv.conf
cr0x@server:~$ cat /etc/resolv.conf
nameserver 192.168.1.1
search lan

Qué significa la salida: Un archivo simple con un resolvedor local y dominio de búsqueda.
Decisión: Si esto sigue cambiando inesperadamente, identifica el escritor y configúralo correctamente o elimínalo.

Actualizaciones y pensamiento sobre rollback con xbps

Void es rolling release. Eso está bien en producción si tratas las actualizaciones como una actividad controlada en lugar de un hobby.
Quieres: ventanas de actualización predecibles, registros de qué cambió y un plan para recuperarte de un mal arranque.

Flujo de trabajo de actualización: sincroniza, simula si hace falta, y luego aplica

cr0x@server:~$ sudo xbps-install -S
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1824KB [avg rate: 390KB/s]
cr0x@server:~$ sudo xbps-install -u
[*] Updating package `openssl-3.2.0_1' ...
[*] Updating package `curl-8.5.0_1' ...
[*] Updating package `linux6.6-6.6.16_1' ...

Qué significa la salida: Repos sincronizados; paquetes actualizados, incluido el kernel.
Decisión: Las actualizaciones de kernel significan que debes verificar artefactos de arranque y reiniciar en tu horario, no cuando una aplicación lo fuerza.

Consulta qué cambió y por qué

cr0x@server:~$ xbps-query -R linux6.6 | head -n 10
pkgver: linux6.6-6.6.16_1
repository: https://repo-default.voidlinux.org/current
short_desc: Linux kernel and modules (6.6 series)
maintainer: Void Linux team
license: GPL-2.0-only
architecture: x86_64

Qué significa la salida: Metadatos del paquete y fuente de repositorio.
Decisión: Si un paquete vino de un repo inesperado, puede que hayas mezclado repositorios. Así es como construyes un sistema que se actualiza como una casa encantada.

Mantén un kernel de fallback arrancable

En cualquier sistema que te importe, conserva al menos un kernel conocido bueno instalado.
No es paranoia; es una póliza de seguro barata.
Verifica que tu bootloader realmente lo liste y que exista initramfs para él.

Manual rápido de diagnóstico

Cuando Void “se siente lento” o “no arranca” o “la red está rara”, no necesitas un seminario de filosofía.
Necesitas un orden de operaciones que encuentre el cuello de botella rápidamente y evite el thrashing.

Primero: determina el dominio de la falla

• Dominio de arranque/firmware: no alcanza login, cae a shell de emergencia o bucle en el bootloader.
• Dominio de almacenamiento: esperas I/O, sistema de archivos en solo lectura, servicios con timeout, congelamientos extraños.
• Dominio de red: puedes hacer ping al gateway pero no resolver DNS, o resuelves pero no alcanzas remoto.
• Dominio de servicio: el sistema arranca pero la app/servicio está caída, en flapping o bloqueada.

Segundo: comprueba los observables más simples con alto valor informativo

Estas comprobaciones son rápidas y no requieren que creas en nada.

Saneamiento de la cadena de arranque

cr0x@server:~$ mount | grep -E ' /boot|/boot/efi '
/dev/sda1 on /boot/efi type vfat (rw,relatime)

Decisión: Si la ESP no está montada, las actualizaciones de kernel/initramfs pueden no actualizar el medio real de arranque.

Vista de supervisión de servicios

cr0x@server:~$ sudo sv status /var/service/*
run: dhcpcd: (pid 610) 12m33s
run: nanoklogd: (pid 505) 12m34s
run: socklog-unix: (pid 520) 12m34s
run: sshd: (pid 842) 12m32s

Decisión: Si un servicio crítico está down, ese es tu alcance inmediato. No depures la app hasta que el estado del supervisor sea estable.

Cuello de botella CPU vs I/O

cr0x@server:~$ uptime
 09:34:10 up 25 min,  1 user,  load average: 3.12, 2.40, 1.80
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 5852400 112340 812400    0    0    12    35  412  780 12  4 82  2  0
 2  1      0 5849800 112340 812900    0    0  2400   120  520  900  8  3 61 28  0

Qué significa: Si wa (espera I/O) es alto, estás limitado por almacenamiento. Si us/sy domina, estás limitado por CPU.
Decisión: No “tunes sysctl” antes de saber si estás esperando al disco.

Tercero: aisla el culpable con comprobaciones dirigidas

Una vez que hayas ubicado el problema en un dominio, haces una profundización apropiada para ese dominio:
salud del disco, errores del sistema de archivos, logs de drivers, tablas de rutas, scripts run de servicios.
Evita cambios amplios. Haz un cambio, observa y luego procede.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: el sistema arranca en firmware o “no hay dispositivo bootable”

Causa raíz: ESP no creada correctamente, sin bandera, o entrada de arranque faltante; a veces instalado en modo legacy.

Solución: Arranca la ISO live en modo UEFI, monta la ESP en /boot/efi, reinstala el bootloader y confirma con efibootmgr -v.

2) Síntoma: tras actualizaciones, el sistema cae al shell initramfs (raíz cifrada no encontrada)

Causa raíz: initramfs carece de módulos crypto o la línea de comandos del kernel no especifica el dispositivo LUKS.

Solución: Asegura que dracut incluya soporte crypto, verifica UUID correcto, reconstruye initramfs y valida la cmdline del bootloader.

3) Síntoma: la red “funciona” pero xbps no puede descargar o falla TLS

Causa raíz: hora del sistema incorrecta o resolución DNS rota.

Solución: arregla NTP/chrony; verifica que getent hosts funcione; revisa propiedad de /etc/resolv.conf y comportamiento del cliente DHCP.

4) Síntoma: un servicio se reinicia cada pocos segundos

Causa raíz: el run script sale inmediatamente (config mala, binario faltante, permisos incorrectos), el supervisor hace su trabajo y lo reinicia.

Solución: inspecciona /etc/sv/<service>/run, verifica rutas ejecutables y lee logs en /var/log/socklog.

5) Síntoma: el disco se llena inesperadamente en un sistema “minimal”

Causa raíz: logs crecen sin rotación, o snapshots/subvolúmenes (btrfs/ZFS) no se podan.

Solución: implementa rotación de logs (o retención con svlogd), programa poda y monitorea df -h y crecimiento por directorio.

6) Síntoma: la suspensión/resumen del portátil es inestable

Causa raíz: peculiaridades del firmware, paquetes de microcódigo/firmware faltantes o ajustes de gestión de energía.

Solución: instala firmware/microcódigo apropiado, verifica parámetros del kernel y evita apilar múltiples herramientas de energía que se peleen entre sí.

7) Síntoma: no puedes resolver nombres tras instalar NetworkManager

Causa raíz: dos componentes gestionando resolv.conf (p. ej., dhcpcd + NetworkManager) y pisándose mutuamente.

Solución: elige un stack de red; deshabilita el otro; confirma que resolv.conf sea estable tras reinicios.

8) Síntoma: actualizaciones de paquetes se quejan de firmas o metadatos de repos

Causa raíz: hora del sistema errónea, caché corrupta o repos mezclados.

Solución: corrige la hora, limpia cachés relevantes si hace falta, verifica la lista de repos con xbps-query -L y elimina entradas inesperadas.

Tres mini-historias corporativas desde el campo

Mini-historia 1: el incidente causado por una suposición equivocada

Una compañía mediana tenía una pequeña flota de agentes de compilación. No eran “producción”, que es una frase que tiende a bajar los estándares con rapidez.
Los agentes se reimaginaban con frecuencia, y alguien propuso Void porque arranca rápido y se mantiene fuera del camino.
Buena decisión. El despliegue fue rápido, y la primera semana fue tranquila.

Luego, un lunes, las compilaciones empezaron a fallar intermitentemente. No todas. No de forma consistente.
Los fallos tenían sabor a red: timeouts, descargas de paquetes que se quedaban colgadas, errores TLS aleatorios.
El diagnóstico inicial fue el reflejo corporativo habitual: “el equipo de firewall cambió algo.”
Se abrieron tickets. Se programaron reuniones. El ingeniero on-call envejeció un año.

El problema real fue una suposición equivocada: que la hora del sistema sería “suficientemente cercana” sin un servicio de sincronización.
Algunos agentes arrancaban con deriva de reloj lo bastante grande como para causar fallos de validación TLS contra ciertos endpoints.
No era determinista porque los relojes de firmware derivaban a distintas velocidades y las imágenes se construían en momentos diferentes.

La solución fue vergonzosamente simple: instalar y habilitar un demonio de sincronización horaria y añadir una comprobación preflight en el script de arranque del agente
que se negara a iniciar el worker de compilación si la hora estaba fuera de rango. Todo se estabilizó de inmediato.
Nadie tuvo que cambiar el firewall. Las reuniones todavía ocurrieron, porque las reuniones son un subsistema aparte.

Mini-historia 2: la optimización que salió mal

Otra organización ejecutaba estaciones de trabajo internas que duplicaban como bancos de prueba. Alguien notó que el arranque era “lento”
en un modelo de hardware particular y decidió optimizarlo. El plan fue podar agresivamente servicios y eliminar “paquetes innecesarios”
de la instalación base para reducir el trabajo de inicio.

La optimización funcionó—en teoría. El arranque se hizo unos segundos más rápido. Luego comenzaron las fallas sutiles.
Los desarrolladores reportaron que después de una actualización del kernel, los sistemas a veces no arrancaban y la recuperación requería un USB.
Las fallas se concentraron en máquinas que habían sido “optimizadas” con más agresividad.

El motivo del contragolpe fue haber eliminado lo que parecía tooling opcional alrededor de la generación de initramfs y carga de firmware.
Las máquinas aún arrancaban con el kernel actual, así que el cambio parecía seguro.
Pero cuando llegó el siguiente kernel, el sistema no reconstruyó initramfs correctamente, y el kernel actualizado no pudo encontrar la raíz cifrada en algunas unidades.
Eso no es un problema de rendimiento; es un problema del ciclo de vida.

La remediación no fue “dejar de optimizar.” Fue “optimizar con restricciones.”
Restauraron el tooling de kernel e initramfs como una línea base protegida, documentaron qué paquetes eran no negociables y midieron el tiempo de arranque de nuevo.
El arranque quedó algo más lento que la versión “optimizadda” y dramáticamente más rápido que “arrancar desde USB para reparar la estación”.

Mini-historia 3: la práctica aburrida pero correcta que salvó el día

Un equipo ejecutaba algunos servicios pequeños en VMs Void en un entorno de laboratorio. Nada glamoroso: API interna, gateway de métricas, trabajos programados.
Tenían un hábito que parecía casi cómicamente conservador: antes de cualquier ventana de actualización, tomaban un snapshot en el hipervisor
y exportaban una copia en texto de un pequeño “informe de estado del sistema” (kernel, lista de paquetes, servicios habilitados, configs clave).

Una actualización introdujo una regresión de red específica para la versión de su driver de NIC virtual. Las VMs arrancaban, pero la interfaz nunca subía.
Eso podría haber escalado a un incidente mayor porque los servicios eran dependencias para pipelines de prueba de otros equipos.
En cambio, el ingeniero on-call siguió el runbook: confirma estado de dhcpcd, confirma estado del enlace, compara el informe de estado y haz rollback.

Hacer rollback no fue una admisión de derrota; fue una respuesta controlada.
Restauraron el servicio en minutos y luego reprodujeron el problema en una VM sacrificial.
Con el informe base, pudieron decir exactamente qué cambió. Eso redujo el espacio de búsqueda de “cualquier cosa en Internet” a “un puñado de paquetes.”

La solución final fue anclar un paquete por un periodo corto y programar la actualización una vez que la regresión se resolviera upstream.
La práctica aburrida—snapshots más informes de estado—fue la diferencia entre un parpadeo y un día de caos.
No fue ingenioso. Fue correcto.

Listas de verificación / plan paso a paso

Plan de instalación (laptop/estación UEFI, valores sensatos)

1. Arranca la ISO live en modo UEFI; confirma con ls /sys/firmware/efi.
2. Identifica el disco objetivo con lsblk; desconecta discos extra si puedes.
3. Crea GPT, ESP (512 MiB) y partición root con parted.
4. Formatea la ESP como FAT32; crea LUKS2 en root si cifras; formatea ext4 dentro.
5. Monta root en /mnt, ESP en /mnt/boot/efi.
6. Ejecuta el instalador; configura hostname, locale, timezone; crea un usuario.
7. En el primer arranque: verifica que fstab use UUIDs; verifica que existan entradas de arranque.
8. Habilita logging (socklog) y sincronización horaria; verifica red y DNS.
9. Ejecuta xbps-install -S y luego xbps-install -u en una ventana controlada.
10. Reinicia tras actualizaciones del kernel; confirma que exista un kernel de fallback.

Lista de verificación de línea base operativa (el paquete “yo del futuro”)

• Acceso remoto: sshd habilitado y confirmado; claves instaladas; política de auth con contraseña decidida.
• Logs: logs locales presentes y limitados; decisión sobre centralización.
• Hora: sincronización horaria habilitada; reloj correcto al arrancar.
• Actualizaciones: cadencia definida; plan de reinicio de kernel existe.
• Backups: al menos una imagen/snapshot del sistema; prueba de restauración realizada una vez.
• Higiene de almacenamiento: fstrim periódico si SSD; monitorización de crecimiento de uso de disco.
• Propiedad de red: una herramienta gestiona DHCP/DNS; no hay gestores en conflicto.

Pasos de hardening que valen la pena (y los que saltar)

Vale la pena:
configuración SSH fuerte, paquetes instalados mínimos, actualizaciones regulares, cifrado de disco en dispositivos móviles,
y reglas básicas de firewall apropiadas al rol (estación vs servidor).

Evítalo salvo que tengas razón:
suites de seguridad elaboradas, apilar tres gestores de energía y colecciones exóticas de parámetros del kernel copiadas de desconocidos.
La seguridad trata de reducir la superficie de ataque y mantener higiene de parches, no de acumular perillas.

Preguntas frecuentes (FAQ)

¿Void Linux es bueno para servidores de producción?

Sí, si tu equipo está cómodo con un rolling release y tienes un proceso de actualizaciones.
El modelo operativo (runit + xbps) es limpio. El riesgo no es la distro; son las actualizaciones sin gestionar y los cambios sin documentar.

¿Debería elegir musl para una estación de trabajo?

Generalmente no. glibc te ahorrará dolores de compatibilidad con binarios de terceros y herramientas de desarrollo.
Elige musl cuando sepas exactamente por qué la quieres (y estés preparado para depurar las consecuencias).

¿Cómo habilito un servicio en Void?

Crea un symlink desde /etc/sv/<service> hacia /var/service/<service>.
Luego comprueba el estado con sv status <service>.

¿Dónde viven los logs?

Depende de lo que instales y habilites. Una configuración común usa socklog y almacena logs bajo /var/log/socklog.
Decide temprano cómo quieres manejar logs; no lo dejes ambiguo.

¿Cuál es la configuración de escritorio más simple?

Si quieres fricción mínima, usa un gestor de ventanas ligero o un escritorio mainstream que ya conozcas.
Instala solo lo que necesitas y no conviertas “minimal” en un deporte de competición.

¿Cómo manejo las actualizaciones de kernel de forma segura?

Actualiza en una ventana, asegúrate de que initramfs exista para el nuevo kernel, conserva al menos un kernel de fallback,
y reinicia en tu horario. Verifica entradas de bootloader con efibootmgr -v.

¿Puedo cifrar todo el disco dejando la ESP sin cifrar?

Sí. Esa es la aproximación UEFI estándar: ESP sin cifrar, raíz cifrada (LUKS2).
Tu modelo de amenaza decidirá si también necesitas Secure Boot, integración con TPM o desbloqueo remoto.

¿Por qué mi DNS sigue cambiando?

Porque múltiples componentes intentan gestionar /etc/resolv.conf.
Elige uno: dhcpcd (+ resolvconf si lo usas), NetworkManager o una configuración estática. Luego deshabilita el resto.

¿Void es más difícil que Arch?

Diferente difícil. Arch tiene patrones comunitarios extensos; Void tiene menos capas y menos ceremonias.
Void puede sentirse más sencillo una vez internalices runit y xbps, porque hay menos “magia” que desaprender.

¿Cuál es el mejor sistema de archivos para Void?

ext4 si quieres predecible. btrfs si quieres snapshots y vas a gestionarlos.
ZFS si estás ejecutando intencionalmente un sistema de almacenamiento y aceptas su modelo operativo.
Si no puedes articular la compensación, elige ext4 y sigue con tu vida.

Conclusión: próximos pasos para mantenerte fuera de problemas

Void Linux es minimalista en lo que importa: menos abstracciones entre tú y el comportamiento del sistema.
Eso lo convierte en una gran plataforma para quienes prefieren entender sus máquinas, no negociar con ellas.
Pero el minimalismo no excusa la pereza operativa. Solo hace que la pereza sea más visible.

Próximos pasos que yo realmente haría, en orden:

1. Habilitar logging y sincronización horaria; verificar que sobrevivan al reinicio.
2. Bloquear SSH (o eliminarlo si no lo necesitas) y confirmar que puedes recuperar acceso.
3. Definir tu cadencia de actualizaciones y probar una actualización de kernel + reinicio cuando no estés bajo presión.
4. Elegir una postura de almacenamiento: ext4 como línea base, o snapshots con btrfs/ZFS—con monitorización y poda.
5. Escribir un runbook local de una página: diseño del disco, UUIDs de cifrado, servicios habilitados y cómo arrancar un kernel de fallback.

El objetivo no es construir el sistema más minimalista en internet. El objetivo es construir un sistema que puedas operar con calma cuando falle.
Void te da las herramientas. Úsalas como si fueras a recibir la llamada a las 3 a.m.—porque puede que la recibas.