Instalación de openSUSE Tumbleweed: lanzamiento continuo sin desastres

Lo que aceptas (y por qué puede ser sensato)

Tumbleweed es una rolling release. Eso significa que tu sistema evoluciona continuamente: kernel, Mesa, systemd, controladores, toda la pila. No estás “actualizando de 15.5 a 15.6.” Te mueves a lo largo de un flujo de snapshots probados.

La ventaja es obvia: las correcciones de seguridad llegan rápido, el soporte de hardware mejora con rapidez y los desarrolladores no tienen que vivir en un museo. La desventaja también es obvia: el cambio es constante, y el cambio constante castiga las malas prácticas operativas.

Así que no instalas Tumbleweed como una caja de hobby que puedes reinstalar un fin de semana lluvioso. Lo instalas como un endpoint que debe seguir funcionando tras actualizaciones, sobrevivir a cortes de energía y recuperarse de las malas decisiones de tu yo futuro. La buena noticia: los valores por defecto de openSUSE están inusualmente alineados con esa mentalidad—si no los saboteas.

Un principio orientador, parafraseado de una idea frecuentemente atribuida a John Allspaw: la fiabilidad es una característica del sistema completo, incluyendo a las personas que lo operan.

Esto es lo que voy a recomendar con criterio:

• Usa Btrfs para root con snapshots a menos que tengas una razón específica y ensayada para no hacerlo.
• Mantén /home separado (ya sea un subvolumen separado con política de snapshots distinta o un sistema de archivos separado) si te importa deshacer cambios con facilidad y un uso de disco sensato.
• Prefiere UEFI. Las instalaciones Legacy BIOS funcionan, pero UEFI + GRUB2 es la ruta con menos trampas.
• No “optimices” la seguridad. Si desactivas snapshots porque “no los necesito”, descubrirás que sí los necesitabas.

Chiste #1: Las rolling releases son como starters de masa madre: si las descuidas una semana, empiezan a desarrollar opiniones.

Hechos e historia que explican la personalidad de Tumbleweed

El contexto importa porque las distros son cultura en código. Algunos hechos concretos que modelan por qué Tumbleweed se comporta como lo hace:

1. Tumbleweed se convirtió en la rolling release oficial en 2015, reemplazando la variante comunitaria anterior. Ese cambio endureció el proceso de publicación.
2. openQA es central para Tumbleweed: pruebas automatizadas de instalación y del sistema validan los snapshots. No es magia, pero explica por qué las roturas suelen ser “casos límite raros” en lugar de “todo está en llamas”.
3. zypper tiene un solucionador de dependencias robusto desde hace años, y SUSE ha tratado la gestión de paquetes como una preocupación de producción, no como un proyecto secundario.
4. La integración Snapper + Btrfs no es un pensamiento de última hora. Es parte de la historia de instalación por defecto, incluyendo la integración con el gestor de arranque para rollback.
5. YaST tiene décadas de ADN operativo. Te guste o no la interfaz, fue construida para administradores que no quieren editar todo a las 3 a.m.
6. Tumbleweed sigue “snapshots probados”, no “lo que se compiló ahora mismo”. Es una diferencia sutil respecto a algunos modelos rolling que empujan paquetes en cuanto compilan.
7. SELinux no es la historia principal de MAC aquí; es AppArmor. Eso influencia los patrones de resolución y los momentos de “¿por qué esto está bloqueado?”.
8. El linaje empresarial de SUSE aparece en lugares aburridos: valores por defecto, elecciones de sistema de archivos y herramientas de actualización. Lo aburrido es bueno cuando estás de guardia.

Ninguno de estos hechos garantiza que no encontrarás regresiones. Significan que el proyecto dedica esfuerzo real a hacer lo “rolling” compatible con “escritorio del que dependes”.

Decisiones de diseño que evitan desastres rodantes

Btrfs en root es una característica de fiabilidad, no una moda

La tradición de openSUSE “Btrfs para /, XFS para /home” no es aleatoria. El sistema raíz cambia con frecuencia y se beneficia de snapshots y rollback. Los directorios home tienen mucho movimiento de datos personales y no siempre se benefician de snapshotear cada transacción de paquetes.

Para Tumbleweed, el impacto práctico es enorme: si una actualización de kernel + controlador deja inutilizable el arranque o la interfaz gráfica, puedes reiniciar en un snapshot anterior y volver al trabajo. Eso no es teórico. Eso es el martes.

Snapper solo es eficaz si mantienes límites claros

Snapshotearlo todo suena seguro hasta que te das cuenta de que estás snapshotear caches del navegador e imágenes de VM cada vez que instalas una tipografía. Así llenas discos sin ruido. El patrón sensato es:

• Snapshotear root (SO + configs) con frecuencia y automáticamente.
• Mantener rutas volátiles o enormes fuera de snapshots (o en otro filesystem/subvolumen).
• Definir el comportamiento de /var: los logs importan, los caches no.

Rolling significa operacionalizar las actualizaciones

Una release estable puede sobrevivir al descuido. Una rolling release castigará el descuido esperando hasta que actualices después de tres meses y entonces te entregue una negociación de dependencias entre tu yo pasado y tu yo presente.

Así que: actualiza regularmente, lee la salida del solucionador y no trates los avisos de “vendor change” como una aventura escrita por un mono del caos.

Preflight: firmware, discos y elecciones de red

Configuraciones UEFI que importan

Antes de arrancar el instalador, entra en la configuración del firmware. Sí, es molesto. También es donde nacen muchos tickets de “Linux está roto”.

• Modo UEFI: actívalo. Si debes usar BIOS legacy, acepta que estás en un mundo más estrecho y extraño.
• Secure Boot: Tumbleweed puede manejarlo, pero módulos de kernel de terceros (notablemente NVIDIA) añaden complejidad. Decide ahora si quieres la propiedad de seguridad o la conveniencia.
• Modo SATA: ponlo en AHCI salvo que tengas una razón (y controladores) para RAID.

Disposición de discos: tu estrategia futura de rollback comienza aquí

El instalador puede crear una disposición por defecto decente. Pero deberías entender la forma del sistema que estás creando:

• EFI System Partition (ESP): partición FAT32 pequeña montada en /boot/efi. Consérvala; no te pongas creativo.
• / (root): Btrfs, con subvolúmenes que Snapper pueda snapshotear limpiamente.
• /home: XFS (común) o Btrfs con una política de snapshots distinta. Si usas cifrado de disco completo, la consistencia importa más que la ideología del sistema de archivos.
• Swap: para portátiles, considera swap como partición si quieres hibernación confiable; de lo contrario un swapfile suele bastar.

Red: NetworkManager vs wicked

En estaciones de trabajo y portátiles: NetworkManager. En servidores con configuración estática: wicked puede estar bien. El modo de fallo previsible aquí es: eliges wicked y luego esperas que el roaming Wi‑Fi y la UX de VPN sean como un SO de escritorio. Eso no es para lo que sirve wicked.

Listas de control / plan paso a paso (con opciones y consecuencias)

Paso 0: Decide qué tipo de máquina Tumbleweed es

• Portátil de desarrollador: root en Btrfs + snapshots, /home separado, NetworkManager, gestión de energía agresiva, actualizaciones frecuentes.
• Estación de trabajo con controladores GPU: lo mismo, pero planifica fricción con módulos de controladores y prueba snapshots antes de presentaciones importantes.
• Servidor doméstico / laboratorio: igualmente snapshots, pero sé más estricto con actualizaciones escalonadas y ventanas de reinicio.

Paso 1: Instala con los valores por defecto de sistema de archivos correctos

En el particionado del instalador:

• Conserva o crea ESP (FAT32) montada en /boot/efi.
• Configura / en Btrfs con subvolúmenes habilitados (el asistente guiado por defecto suele hacerlo).
• Pon /home en XFS o en un subvolumen Btrfs separado con snapshots deshabilitados o limitados.

Punto de decisión: Si no te importa el rollback, puedes elegir ext4 en todas partes. Si haces eso en Tumbleweed, eliges depurar con la cara en vez de con snapshots.

Paso 2: Elige el escritorio como eliges una rotación de guardia

• KDE Plasma: pulido, con muchas funciones, ideal para usuarios avanzados, ligeramente con más piezas móviles.
• GNOME: consistente, buena historia de Wayland, UX con reglas claras.
• Minimal + tu elección: bien si sabes lo que haces y disfrutas construir tus propios pequeños cortes.

Paso 3: Habilita snapshots y hazlos arrancables

En openSUSE, Snapper y la integración con GRUB suelen estar configurados. Pero “suelen” no es un SLA. Después de la instalación, verifícalo (comandos abajo).

Paso 4: Decide tu cadencia de actualizaciones

• Actualizaciones diarias/semanales: mejor experiencia, diffs más pequeños, menos problemas con el solucionador.
• Actualizaciones mensuales: espera cambios mayores y más decisiones de “vendor change”.

Elige una cadencia que realmente puedas mantener. Una rolling release no perdona el pensamiento deseoso.

Tareas prácticas: comandos, salida esperada y qué hacer después

Estas son las comprobaciones básicas que ejecuto en una instalación nueva de Tumbleweed o después de que algo huela a quemado. Cada tarea incluye: comando, qué significa la salida y la decisión a tomar.

Tarea 1: Confirma que arrancaste en modo UEFI

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Significado: “UEFI” significa que el kernel ve el entorno de runtime EFI.

Decisión: Si esperabas UEFI pero obtuviste “BIOS”, arregla el modo de arranque del firmware ahora—antes de depurar GRUB en el universo equivocado.

Tarea 2: Comprueba el kernel y la plataforma básica

cr0x@server:~$ uname -a
Linux server 6.7.9-1-default #1 SMP PREEMPT_DYNAMIC ... x86_64 GNU/Linux

Significado: Confirma la versión y la variante del kernel. En Tumbleweed las versiones de kernel cambian rápido.

Decisión: Si estás diagnosticando una regresión, anota el kernel. A menudo es el diferenciador.

Tarea 3: Valida Btrfs en root y las opciones de montaje

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /
btrfs rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@/.snapshots/1/snapshot

Significado: Root es Btrfs; la ruta del subvolumen muestra que estás en una raíz derivada de un snapshot (normal en openSUSE).

Decisión: Si root es ext4 y esperabas snapshots Btrfs, decide si reinstalar o aceptar que pierdes rollback. Retrofitar más tarde es posible pero engorroso.

Tarea 4: Lista subvolúmenes Btrfs para confirmar el layout

cr0x@server:~$ sudo btrfs subvolume list /
ID 256 gen 123 top level 5 path @
ID 257 gen 123 top level 5 path @/var
ID 258 gen 124 top level 5 path @/.snapshots
ID 259 gen 123 top level 5 path @/usr/local
ID 260 gen 123 top level 5 path @/tmp

Significado: Esto muestra subvolúmenes separados. openSUSE los usa para controlar qué se snapshotea y cómo.

Decisión: Si ves todo bajo un solo subvolumen, Snapper snapshoteará demasiado. Considera reinstalar con particionado guiado o ajustar subvolúmenes antes de acumular datos.

Tarea 5: Verifica que existen configuraciones de Snapper y están activas

cr0x@server:~$ sudo snapper list-configs
Config | Subvolume
-------+----------------
root   | /
home   | /home

Significado: Snapper está configurado al menos para root (y posiblemente para home).

Decisión: Si no hay una configuración root, arregla Snapper antes de confiar en el rollback. Sin snapshots, no hay paracaídas.

Tarea 6: Confirma snapshots automáticos alrededor de operaciones de paquetes

cr0x@server:~$ systemctl status snapper-timeline.timer --no-pager
● snapper-timeline.timer - Timeline of Snapper Snapshots
     Loaded: loaded (/usr/lib/systemd/system/snapper-timeline.timer; enabled)
     Active: active (waiting) since ...

Significado: Los snapshots de timeline están habilitados (periódicos). Los snapshots por paquetes vienen de plugins de zypper; los timers controlan la retención basada en tiempo.

Decisión: Si los timers están deshabilitados y quieres seguridad, actívalos. Si el disco es pequeño, manténlos pero ajusta la retención.

Tarea 7: Inspecciona repositorios y sus prioridades

cr0x@server:~$ zypper lr -P
#  | Alias                   | Name               | Enabled | GPG Check | Refresh | Priority
---+-------------------------+--------------------+---------+-----------+---------+---------
1  | repo-oss                | openSUSE OSS       | Yes     | (r ) Yes  | Yes     |   99
2  | repo-non-oss            | openSUSE Non-OSS   | Yes     | (r ) Yes  | Yes     |   99
3  | repo-update             | openSUSE Update    | Yes     | (r ) Yes  | Yes     |   99

Significado: Puedes ver qué repos existen, si se refrescan y cuál gana cuando hay conflicto de versiones.

Decisión: Si añadiste repos de terceros, asegúrate de entender quién “posee” paquetes. Prioridades aleatorias son cómo creas un sistema Frankenstein.

Tarea 8: Ejecuta una simulación segura de “qué haría la actualización”

cr0x@server:~$ sudo zypper dup --dry-run
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 12 packages are going to be upgraded:
  kernel-default systemd Mesa-libGL1 ...

Overall download size: 180.5 MiB.

Significado: Esto muestra el alcance. También revela cambios de vendor o eliminaciones antes de comprometerte.

Decisión: Si el solucionador propone eliminaciones que no entiendes (especialmente la pila GPU, el escritorio o la red), detente e investiga antes de ejecutar un dup real.

Tarea 9: Identifica propuestas de cambio de vendor antes de aceptarlas

cr0x@server:~$ sudo zypper dup
...
The following package is going to change vendor:
  libfoo  openSUSE -> obs://build.some.repo
Continue? [y/n/v/...? shows all options] (y):

Significado: Un repo de terceros quiere reemplazar una librería o componente central.

Decisión: Por defecto responde no a menos que intencionalmente hayas instalado ese repo por ese conjunto de paquetes. La deriva de vendor es causa común de espirales en actualizaciones.

Tarea 10: Comprueba que existen entradas de snapshot en GRUB

cr0x@server:~$ sudo grep -R "openSUSE snapshots" -n /boot/grub2/grub.cfg | head
1023:menuentry 'openSUSE snapshots' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-snapshots' {

Significado: GRUB está configurado para mostrar entradas de arranque por snapshot.

Decisión: Si falta, el rollback en el arranque se complica. Arregla la integración GRUB/Snapper antes de necesitarla, no durante un incidente.

Tarea 11: Confirma que el ESP está montado y no lleno

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE     FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

cr0x@server:~$ df -h /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  512M  120M  392M  24% /boot/efi

Significado: ESP está presente, montado y con espacio.

Decisión: Si el ESP está lleno, las instalaciones de kernel y las actualizaciones del gestor de arranque pueden fallar de maneras confusas. Limpia entradas EFI antiguas si es necesario, pero no borres a ciegas.

Tarea 12: Comprueba señales de salud del disco y pistas del scheduler de IO

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL
nvme0n1    disk  953.9G              Samsung SSD 980
├─nvme0n1p1 part    512M vfat   /boot/efi
├─nvme0n1p2 part      2G swap   [SWAP]
└─nvme0n1p3 part  951.4G btrfs  / /home

Significado: Confirma qué está dónde. Te sorprendería cuántas veces “mi root está lleno” es en realidad “mi home está en root”.

Decisión: Si pretendías sistemas de archivos separados y no los ves, arréglalo temprano antes de que crezcan los datos.

Tarea 13: Audita presión de memoria y uso de swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       9.2Gi       4.1Gi       1.1Gi        18Gi        21Gi
Swap:          2.0Gi          0B       2.0Gi

Significado: “available” es el número clave para “¿empezará el sistema a usar swap pronto?”.

Decisión: Si el swap se usa mucho durante trabajo normal, el cuello de botella probablemente sea memoria (o un proceso descontrolado), no “Linux está lento”.

Tarea 14: Comprueba el rendimiento de arranque y fallos recientes

cr0x@server:~$ systemd-analyze time
Startup finished in 3.112s (kernel) + 8.904s (userspace) = 12.016s
graphical.target reached after 8.701s in userspace.

cr0x@server:~$ systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● ModemManager.service          loaded failed failed Modem Manager

Significado: systemctl --failed muestra lo que está activamente roto. No ignores fallos; suelen ser el sistema de alerta temprana.

Decisión: Si un servicio falló y no lo necesitas, desactívalo. Si lo necesitas, arréglalo ahora—los servicios fallidos suelen convertirse luego en “¿por qué la VPN es inestable?”.

Tarea 15: Lee los logs como si importara

cr0x@server:~$ sudo journalctl -p err -b --no-pager | tail -n 20
Feb 05 09:13:02 server kernel: nouveau 0000:01:00.0: firmware: failed to load nouveau/...
Feb 05 09:13:05 server systemd[1]: Failed to start Modem Manager.

Significado: Errores del arranque actual, filtrados a “err”. Es una forma rápida de ver la causa real detrás de los síntomas.

Decisión: Si ves errores de firmware/controlador después de una actualización, considera hacer rollback antes de empezar a reinstalar paquetes al azar.

Actualizaciones como un SRE: zypper dup sin drama

Las actualizaciones de Tumbleweed no son zypper up. El modelo mental soportado es una actualización de distribución: zypper dup. Así es como te mantienes alineado con el conjunto de snapshots probados.

El flujo de trabajo que te mantiene fuera de problemas

1. Refrescar repos (y asegúrate de confiar en ellos).
2. Hacer dry-run para entender el cambio.
3. Actualizar con atención, no en piloto automático.
4. Reiniciar cuando cambien componentes críticos (kernel, systemd, Mesa, glibc). Sí, incluso en una estación de trabajo.

Comandos concretos: refrescar, inspeccionar, actualizar

cr0x@server:~$ sudo zypper refresh
Repository 'openSUSE OSS' is up to date.
Repository 'openSUSE Non-OSS' is up to date.
Repository 'openSUSE Update' is up to date.

Significado: Los metadatos están al día. Si refresh falla, podrías estar depurando red o problemas de mirror, no paquetes.

cr0x@server:~$ sudo zypper dup --details
...
Overall download size: 480.2 MiB. After the operation, additional 52.0 MiB will be used.

Significado: “Después de la operación” el delta de disco es tu aviso temprano para roots pequeños.

Decisión: Si root tiene < 5–10 GiB libres y vas a descargar actualizaciones grandes, limpia snapshots y caches primero. No esperes a “disco lleno” a mitad de la transacción.

Cuando el solucionador propone eliminaciones

Las eliminaciones no son automáticamente malas. Son automáticamente sospechosas.

• Si quiere eliminar un meta paquete de escritorio, te espera un mal día.
• Si quiere eliminar una librería obsoleta que no usas, está bien.
• Si quiere eliminar tu stack de controladores GPU, detente y averigua por qué.

Chiste #2: El solucionador de dependencias es como un abogado—si no lees la letra pequeña, te hará firmar alegremente la renuncia a tu entorno de escritorio.

Snapshots, rollback y cómo no sabotearlos

Entiende qué hace realmente el rollback

Rollback en openSUSE con Btrfs/Snapper generalmente significa: arrancar un snapshot anterior del filesystem raíz. Eso es poderoso porque devuelve binarios del sistema y configuraciones a un estado previo. No es una máquina del tiempo para todo.

Cosas que pueden no revertirse limpiamente a menos que estén diseñadas para ello:

• Datos en /home si está en un sistema de archivos separado o excluido de snapshots.
• Bases de datos o servicios con estado en /var si los snapshotearon pero no gestionas la consistencia.
• Firmware almacenado fuera del filesystem raíz, dependiendo del hardware.

Cómo usar snapshots de forma segura en operaciones

Para una estación de trabajo, este es el plan:

1. Ejecuta zypper dup.
2. Reinicia con prontitud si cambiaron kernel/gráficos/systemd.
3. Si el arranque falla o la gráfica está rota, reinicia en un snapshot previo desde GRUB.
4. Desde el snapshot funcional, evalúa: espera un nuevo snapshot, ajusta repos o fija/pinea controladores.

No acumules snapshots para siempre

Los snapshots cuestan espacio. En Btrfs, el coste es incremental—hasta que deja de serlo. Cambios grandes, imágenes de VM, contenedores y el churn de caches del navegador pueden inflar los deltas de snapshot.

cr0x@server:~$ sudo snapper list | tail
  90  | single |       |         | root | 2026-02-01 09:00:01 |      | number cleanup
  91  | pre    |  5123 | zypp(zypper) | root | 2026-02-03 18:41:22 |      | zypp pre
  92  | post   |  5123 | zypp(zypper) | root | 2026-02-03 18:45:10 |      | zypp post

Significado: Ves snapshots de timeline (“single”) y snapshots de transacciones de paquetes (“pre/post”).

Decisión: Si tienes cientos, la retención puede ser demasiado generosa para tu disco. Ajusta la limpieza de Snapper, no borres snapshots manualmente a lo loco.

cr0x@server:~$ sudo btrfs filesystem df /
Data, single: total=120.00GiB, used=92.15GiB
Metadata, DUP: total=8.00GiB, used=6.90GiB
System, DUP: total=32.00MiB, used=16.00MiB

Significado: Btrfs informa asignado vs usado. “Used” es el consumo real; “total” son chunks asignados.

Decisión: Si Metadata está casi lleno, puedes encontrarte ENOSPC con mucho “Data” libre. Esa es una sorpresa clásica de Btrfs—arréglalo liberando espacio y haciendo balance si es necesario, no reinstales por pánico.

Playbook de diagnóstico rápido: qué comprobar primero/segundo/tercero

Cuando Tumbleweed “se siente roto”, el fallo puede ser estado de paquetes, gestor de arranque, presión del filesystem, stack GPU o puro DNS. Así es como dejas de adivinar.

Primero: ¿está arrancando el entorno esperado?

• Modo de arranque: ¿UEFI o BIOS? (Tarea 1)
• Versión del kernel: ¿cambió recientemente? (Tarea 2)
• ¿Se completó la última actualización? Revisa el historial de zypper y los servicios en ejecución.

cr0x@server:~$ sudo tail -n 30 /var/log/zypp/history
2026-02-03 18:41:22|install|kernel-default|6.7.9-1.1|x86_64|repo-oss|...
2026-02-03 18:45:10|remove |kernel-default|6.7.8-1.1|x86_64|@System|...

Decisión: Si las actualizaciones están a medias o interrumpidas, no reinicies repetidamente esperando que se arregle solo. Termina o haz rollback.

Segundo: ¿el cuello de botella es CPU, memoria, disco o red?

• Saturación de CPU: carga alta con bajo IO wait sugiere bound por CPU.
• Presión de memoria: uso de swap y bajo “available” sugiere bound por memoria.
• Presión de disco: ENOSPC en Btrfs y metadata llena crean ilusiones de “todo está lento”.
• Red/DNS: fallos de refresco de repos y “la web está lenta” a menudo significan DNS.

cr0x@server:~$ uptime
 09:22:11 up 3 days,  1:02,  2 users,  load average: 0.42, 0.55, 0.60

Decisión: Promedios de carga < 1 en un sistema con muchos cores usualmente no son tu problema. Mira en otra parte.

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
 1  0      0 4200000 120000 18000000  0    0    12    28  410  900  3  1 95  1  0

Significado: wa es IO wait; si/so muestra swapping. Alto wa apunta a almacenamiento; alto so apunta a presión de memoria.

Decisión: Si wa es alto, revisa disco y filesystem. Si swap está activo, deja de culpar a la GPU.

Tercero: ¿es un servicio el que falla ruidosamente?

cr0x@server:~$ systemctl --failed
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
● display-manager.service loaded failed failed X Display Manager

Decisión: Un display manager fallido tras una actualización grita “problema con el stack gráfico”. Haz rollback o cambia a una combinación conocida de kernel/controlador antes de editar configs al azar.

Luego: confirma el stack gráfico (dolor común en estaciones de trabajo)

cr0x@server:~$ loginctl show-session "$(loginctl | awk 'NR==2{print $1}')" -p Type
Type=wayland

Significado: Wayland vs X11 afecta el comportamiento del controlador y los pasos de resolución.

Decisión: Si tienes NVIDIA y Wayland está problemático tras una actualización, prueba X11 (o un snapshot previo) para aislar si es compositor/controlador/kernel.

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

1) “Después de la actualización, arranca a pantalla negra”

Síntoma: El sistema arranca, pero el display manager nunca aparece; quizá ves un cursor parpadeante.

Causa raíz: Desajuste kernel/controlador (a menudo NVIDIA), initramfs roto o un display manager que falla debido a cambios en el stack gráfico.

Solución: Arranca un snapshot anterior desde GRUB. Confirma con systemctl --failed y journalctl -p err -b. Si es NVIDIA, alinea los paquetes del driver con el kernel en ejecución y considera retrasar actualizaciones hasta que el repo del driver se ponga al día.

2) “zypper dup quiere eliminar la mitad de mi escritorio”

Síntoma: El solucionador propone eliminar patrones de Plasma/GNOME o librerías clave.

Causa raíz: Repos de terceros con paquetes conflictivos, cambios de vendor o actualizaciones parciales por mezclar up y dup con el tiempo.

Solución: Detente. Inspecciona repos (zypper lr -P). Prefiere repos oficiales. Si debes usar repos de terceros, mantenlos mínimos y entiende los cambios de vendor. Ejecuta zypper dup --dry-run hasta que el plan tenga sentido.

3) “Mi disco está ‘lleno’ pero df muestra espacio”

Síntoma: Fallan escrituras, instalaciones de paquetes fallan, pero df -h muestra espacio libre.

Causa raíz: Agotamiento de metadata de Btrfs o problemas de asignación de chunks.

Solución: Revisa btrfs filesystem df / y btrfs filesystem usage /. Libera espacio podando snapshots y caches; considera un balance si sabes lo que haces. No ejecutes comandos “mágicos” de btrfs al azar a las 2 a.m.

4) “Rollback no arregló mis datos de la app”

Síntoma: Hiciste rollback, pero tu carpeta de proyecto/config en home sigue “rota”.

Causa raíz: /home no forma parte de los snapshots de root (por diseño), o los datos relevantes viven fuera de las rutas snapshotadas.

Solución: Decide qué quieres que cubra el rollback. Para configuraciones críticas, guárdalas en ubicaciones gestionadas por root o usa una estrategia de dotfiles con control de versiones. Para bases de datos, usa backups adecuados y snapshots conscientes del servicio.

5) “La red no vuelve tras suspensión”

Síntoma: Reconexión Wi‑Fi inestable; la VPN falla hasta reiniciar.

Causa raíz: Elección inadecuada de stack de red (wicked en un portátil), peculiaridades del power management o regresiones de controladores.

Solución: Usa NetworkManager en portátiles. Revisa logs de NetworkManager y mensajes del driver wifi en el kernel. Si es regresión, arranca un kernel o snapshot previo y espera el snapshot corregido.

6) “Secure Boot rompió mi módulo de kernel de terceros”

Síntoma: Tras activar Secure Boot, módulos NVIDIA/VirtualBox no se cargan.

Causa raíz: Requisitos de firmado de módulos. Los módulos sin firmar no cargarán bajo Secure Boot sin inscripción de MOK/firma.

Solución: Usa módulos firmados desde repos de confianza que soporten workflows de Secure Boot, inscribe una clave y firma los módulos, o acepta desactivar Secure Boot. Elige un camino; las medias tintas hacen perder tardes.

Tres mini-historias corporativas (porque reconocerás a esta gente)

Incidente #1: El outage causado por una suposición equivocada

Una organización de ingeniería mediana desplegó Tumbleweed en estaciones de trabajo de desarrolladores porque el habilitamiento de hardware importaba: portátiles nuevos, GPUs nuevas, muchas pantallas externas. El piloto funcionó bien. Luego lo escalaron rápidamente, porque el equipo piloto era ruidoso y persuasivo—siempre una combinación peligrosa.

Asumieron que rollback significaba “todo vuelve”. Así que permitieron que los equipos mantuvieran enormes árboles de proyecto bajo /home en un filesystem separado, y dijeron a todos: “Si una actualización rompe algo, simplemente hagan rollback.” Eso es cierto para el SO. No es cierto para el caos con estado que vive en los home.

El incidente: una actualización cambió un componente de toolchain y varios equipos reconstruyeron caches y artefactos intermedios locales. Cuando se descubrió una regresión, hicieron rollback del snapshot del SO. Los caches en /home quedaron “nuevos”. Algunas compilaciones usaron binarios antiguos con caches nuevos, produciendo fallos extraños e intermitentes.

El outage no fue una gran explosión. Fue peor: inconsistencia de bajo grado. Los ingenieros perdieron días persiguiendo bugs fantasma.

La solución no fue heroica. Dibujaron un límite. Las toolchains y caches críticos de build se movieron a ubicaciones controladas con limpieza explícita en rollback, y documentaron que rollback restaura el SO, no todo tu conjunto de trabajo. También añadieron un script de “higiene post-rollback” para limpiar caches que causan corrupción entre versiones. La lección: las suposiciones son la opción de configuración más cara.

Incidente #2: Una optimización que salió mal

Otra empresa estandarizó root en Btrfs con snapshots—bien. Entonces alguien notó que el uso de disco subía en portátiles de 256 GB, y decidió “optimizar almacenamiento”. Su plan: desactivar agresivamente snapshots de timeline, reducir snapshots zypp y excluir más rutas de snapshotear. En papel redujo el churn.

Durante unos meses todo fue bien. Menos snapshots. Más espacio libre. Todos se felicitaron por ser operadores disciplinados en vez de “acaparadores de snapshots”.

Luego llegó una regresión gráfica que afectó a un modelo de portátil específico. La respuesta correcta habría sido: arrancar el último snapshot conocido bueno y seguir trabajando mientras llega la corrección. Pero esos sistemas casi no tenían snapshots: sólo un par de transacciones recientes, y la ventana de retención ya había borrado el buen estado.

El resultado: reconstrucciones de emergencia, pinning manual de paquetes y muchas preguntas de “¿por qué el rollback no nos salvó?” en reuniones donde nadie quería admitir la respuesta.

La solución final fue aburrida y algo humillante: restaurar retención de snapshots sensata, mover datos grandes no-OS fuera del root snapshotado e implementar monitorización de disco para ajustar retención según uso real en vez de sensaciones. Optimizar la seguridad es sólo deuda de riesgo con mejor postura.

Incidente #3: La práctica aburrida pero correcta que salvó el día

Una organización regulada ejecutó Tumbleweed en una pequeña flota de escritorios de ingeniería—sí, de verdad. Lo hicieron porque necesitaban kernels modernos para interfaces hardware específicas y porque sus ingenieros rechazaban toolchains antiguas. El equipo de cumplimiento aceptó con una condición: las actualizaciones deben ser escalonadas y reversibles.

Así que el equipo de ops hizo algo poco fashion: crearon una cadencia simple. Una vez por semana, un pequeño grupo canario actualizaba primero. Reiniciaban. Ejecutaban un script de prueba corto que validaba VPN, autenticación por smartcard y un par de apps internas. Sólo entonces actualizaba el resto de la flota.

Una semana, los canarios detectaron una regresión en un componente de la pila de red. La VPN falló de una forma que parecía “quizá el concentrador VPN está caído”. El script de pruebas demostró que no era así. Los canarios hicieron rollback al snapshot previo en minutos y siguieron productivos.

Porque la regresión se detectó antes del despliegue amplio, la organización evitó un lunes por la mañana en que la mitad del departamento no podía autenticarse. Sin heroísmos, sin war room nocturno. Sólo una pequeña puerta y un plan de rollback que habían ensayado.

La práctica no fue emocionante. Por eso funcionó.

Preguntas frecuentes

1) ¿Debo usar Tumbleweed en un servidor de producción?

Puedes, pero necesitas disciplina: repos controlados, actualizaciones escalonadas, ventanas de mantenimiento y un plan de rollback. Si quieres “instalar y olvidar”, elige una rama estable en su lugar.

2) ¿Por qué todo el mundo dice “usar zypper dup” en vez de “zypper up”?

dup alinea tu sistema con el snapshot actual de la distribución, manejando correctamente cambios de vendor y transiciones. up está bien en algunos casos, pero en Tumbleweed no debería ser el por defecto porque puede dejarte en un estado parcial con el tiempo.

3) ¿Realmente necesito reiniciar después de las actualizaciones?

Si cambiaron el kernel, systemd, Mesa o librerías centrales: sí. Puedes seguir tirando, pero estarás ejecutando una mezcla de procesos antiguos y archivos nuevos. Así nacen bugs de “solo se rompe después de dos días”.

4) Btrfs me asusta. ¿ext4 está bien?

ext4 está bien técnicamente. Operativamente, estás renunciando a rollback de primera clase y recuperación fácil tras actualizaciones fallidas. Si usas Tumbleweed, root en Btrfs es la opción pragmática.

5) ¿/home en Btrfs o XFS?

XFS es sólido para homes grandes y evita el churn de snapshots. Btrfs para /home funciona si ajustas la política de snapshots y no snapshotéas accidentalmente terabytes de imágenes de VM cada vez que instalas un driver de impresora.

6) ¿Cómo sé qué snapshot revertir?

Elige el snapshot justo antes de la transacción que introdujo el problema (a menudo un par zypp pre/post). Usa la fecha y la descripción en snapper list, luego arráncalo desde los snapshots en GRUB.

7) ¿Vale la pena Secure Boot en Tumbleweed?

Para muchos portátiles: sí, si valoras el modelo de amenaza que cubre. Si dependes de módulos de kernel de terceros, planifica firmarlos o acepta la fricción añadida. No lo actives a la ligera y luego te sorprendas de que los módulos sin firmar no carguen.

8) ¿NetworkManager o wicked?

NetworkManager para portátiles y escritorios. wicked para servidores donde quieres configuración declarativa y estable y no te importa el UX de roaming Wi‑Fi.

9) ¿Cómo evito que mi sistema se vuelva un lío de repos?

Mantén repos de terceros mínimos e intencionales. Evita mezclar múltiples repos que provean componentes centrales superpuestos. Si necesitas un paquete especial, valora si instalar ese paquete aislado no es mejor que habilitar un repo entero que reemplaza librerías.

10) ¿Cuál es el comando de troubleshooting más útil en Tumbleweed?

journalctl -p err -b. Si solo tienes tiempo para una cosa, lee los errores del arranque actual y deja de adivinar.

Siguientes pasos que deberías hacer realmente

Instalar Tumbleweed es la parte fácil. Mantenerlo estable es una rutina—corta, repetible y ligeramente aburrida. Ese es el punto.

Pasos inmediatos (hoy)

• Verifica arranque UEFI, montaje ESP y layout de subvolúmenes Btrfs (Tareas 1, 4, 11).
• Confirma que Snapper está configurado y los timers habilitados (Tareas 5, 6).
• Ejecuta zypper dup --dry-run y familiarízate con la planificación (Tarea 8).
• Aprende a arrancar un snapshot desde GRUB antes de necesitarlo.

Pasos operativos (esta semana)

• Elige una cadencia de actualizaciones que puedas mantener (semanal es un buen valor por defecto).
• Decide tu postura sobre Secure Boot y cúmplela.
• Si usas repos de terceros, documenta por qué existe cada uno y qué paquetes controla.
• Haz un ensayo de rollback: actualiza algo pequeño, luego practica identificar y arrancar un snapshot previo. Ensayar es barato; las sorpresas son caras.

Tumbleweed no te garantiza una vida sin dramas. Pero instalado con el layout de sistema de archivos adecuado, snapshots y un flujo de actualizaciones adulto, es una de las raras rolling releases que puede ser a la vez moderna y fiable. No necesitas suerte. Necesitas protecciones—y la humildad para mantenerlas.