Guía de instalación de Ubuntu 24.04 LTS: arranque dual, Secure Boot y cero pérdida de datos

¿Te fue útil?

Las instalaciones en arranque dual no suelen fallar porque Linux sea difícil. Fallan porque el disco te está mintiendo, el firmware tiene opiniones propias y un clic casual puede convertir “instalar Ubuntu” en “restaurar desde copias de seguridad que nunca verificaste”.

Esta guía es la versión adulta: inventariarás la máquina, congelarás el riesgo, instalarás Ubuntu 24.04 LTS junto a Windows manteniendo Secure Boot activado, y conservarás tus datos exactamente donde los dejaste. El objetivo es un éxito aburrido.

Reglas básicas para cero pérdida de datos

“Cero pérdida de datos” no es una sensación. Es una secuencia de estados verificables:

  • Sabes qué disco estás tocando, por identificadores estables, no por intuición.
  • Tienes al menos una copia offline de los datos que te importan.
  • Tienes una vía de recuperación de arranque para ambos sistemas operativos.
  • Cambias una cosa a la vez y luego validas.

Aquí está la actitud que quiero que adoptes: cauteloso, metódico, ligeramente molesto. Esa es la energía correcta para cualquier cosa que edite particiones.

Decide tu arquitectura objetivo antes de comenzar

La mayoría de máquinas modernas deberían ser: firmware UEFI + tabla de particiones GPT + Secure Boot activado. Si tu sistema es BIOS heredado/MBR, aún puedes hacer arranque dual, pero los modos de fallo se multiplican. La guía asume UEFI/GPT porque eso es lo que deberías usar en 2026 a menos que estés resucitando una pieza de museo.

Dos cosas que no debes hacer

  • No “borrarlo todo e instalar de nuevo” cuando el instalador te lo ofrece “amablemente”. Está haciendo su trabajo. Tu trabajo es negarte.
  • No reduzcas particiones desde Linux primero si Windows está involucrado. Reduce Windows desde dentro de Windows. Deja que cada SO maneje sus propios metadatos de sistema de archivos.

Un chiste corto #1: Particionar un disco sin una copia de seguridad verificada es como hacer cirugía porque una vez viste una serie médica: audaz, breve y sorprendentemente caro.

Datos interesantes y contexto histórico (porque este lío tiene historia)

  1. UEFI reemplazó a BIOS como el modelo de firmware dominante en la década de 2010, aportando entradas de arranque estandarizadas y un sistema de archivos real (FAT) para cargadores en la EFI System Partition (ESP).
  2. GPT se convirtió en el predeterminado porque MBR limita el espacio usable y tiene límites frágiles en la tabla de particiones; GPT almacena cabeceras redundantes y soporta muchas particiones limpiamente.
  3. Secure Boot llegó para reducir el malware tipo bootkit. Verifica firmas en la cadena de arranque, lo cual es genial hasta que necesitas controladores de terceros y olvidas qué significa “firmar”.
  4. Ubuntu adoptó shim como puente práctico: shim firmado por Microsoft puede arrancar en sistemas con Secure Boot y luego validar GRUB y kernels con las claves de Ubuntu.
  5. GRUB2 reemplazó al GRUB legado con más funciones y más formas de confundir al usuario. Es flexible, no psíquico.
  6. Windows Fast Startup (una característica de hibernación híbrida) ha sido un peligro recurrente en el arranque dual porque deja los sistemas de archivos “no del todo cerrados”, que Linux correctamente trata como inseguros.
  7. BitLocker se volvió popular en dispositivos de consumo, especialmente en portátiles “Modern Standby”, y cambia la forma en que debes abordar el redimensionado y cambios de arranque.
  8. NVMe cambió la nomenclatura: los discos aparecen como /dev/nvme0n1 con particiones como /dev/nvme0n1p3, lo que es fácil de leer mal durante una instalación tensa.
  9. Las versiones LTS de Ubuntu están diseñadas para ciclos largos de vida operacional; 24.04 LTS es una versión para “usar durante años”, por eso la corrección de la instalación importa más que la novedad.

Operativamente, el tema es simple: la cadena de arranque y el diseño del disco son infraestructura compartida. Trátalos como producción, no como un proyecto de fin de semana.

Comprobaciones previas: hardware, firmware y la verdad del disco

Antes de arrancar cualquier instalador, inventarias. No porque sea divertido, sino porque evita los dos desastres clásicos: (1) escribir en el disco equivocado y (2) instalar en el modo de arranque equivocado.

Tarea 1: Confirma que arrancaste el instalador en modo UEFI

Arranca el USB live de Ubuntu (“Try Ubuntu”). Luego:

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

Qué significa: “UEFI mode” es lo que quieres para arranque dual moderno. Si ves “Legacy BIOS mode”, detente y reinicia el USB seleccionando la entrada UEFI en el menú de arranque del firmware.

Decisión: Procede solo en modo UEFI a menos que estés intencionadamente soportando BIOS heredado.

Tarea 2: Identifica todos los discos y sus tamaños (para no borrar el incorrecto)

cr0x@server:~$ lsblk -e7 -o NAME,PATH,SIZE,TYPE,MODEL,SERIAL
NAME        PATH             SIZE TYPE MODEL                 SERIAL
nvme0n1     /dev/nvme0n1   953.9G disk Samsung SSD 990 PRO   S6Z2...
nvme0n1p1   /dev/nvme0n1p1   100M part
nvme0n1p2   /dev/nvme0n1p2    16M part
nvme0n1p3   /dev/nvme0n1p3   450G part
nvme0n1p4   /dev/nvme0n1p4   900M part
nvme0n1p5   /dev/nvme0n1p5   503G part

Qué significa: Buscas el disco interno (a menudo NVMe) y las particiones existentes. En muchas instalaciones de Windows verás una ESP (~100–300MB), una MSR (16MB), la partición de Windows (grande) y una partición de recuperación.

Decisión: Apunta la ruta del disco (ejemplo: /dev/nvme0n1). Si hay más de un disco interno, decide cuál alojará Ubuntu.

Tarea 3: Confirma el tipo de tabla de particiones (GPT vs MBR)

cr0x@server:~$ sudo parted -l
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  106MB   105MB   fat32        EFI system partition          boot, esp
 2      106MB   123MB   16.8MB               Microsoft reserved partition  msftres
 3      123MB   483GB   483GB   ntfs         Basic data partition          msftdata
 4      483GB   484GB   944MB   ntfs         Basic data partition          hidden, diag
 5      484GB   1024GB  540GB

Qué significa: “Partition Table: gpt” confirma que estás en la era correcta. Si ves “msdos”, estás en MBR/legacy y el plan cambia.

Decisión: Para arranque dual con Secure Boot, GPT es el camino más fluido. Si aparece MBR, considera convertir (avanzado) o acepta la complejidad heredada.

Tarea 4: Confirma que existe la EFI System Partition (ESP) y que es FAT32

cr0x@server:~$ sudo blkid /dev/nvme0n1p1
/dev/nvme0n1p1: UUID="3A1B-2C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="..."

Qué significa: TYPE=vfat y “EFI system partition” es tu ESP. Ubuntu la reutilizará; no deberías formatearla durante la instalación.

Decisión: Mantén la ESP. No crees una segunda ESP a menos que tengas una razón específica (segregación multi-disco o firmware de proveedor muy extraño).

Tarea 5: Comprueba si Windows está hibernado / riesgo de Fast Startup (desde Linux)

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
FAILED
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

Qué significa: La bandera -n es una ejecución en seco. Si indica estado inseguro/hibernado, no montes la partición de Windows en modo lectura-escritura desde Linux y no la redimensiones con herramientas de Linux.

Decisión: Arranca Windows, desactiva Fast Startup y realiza un apagado completo.

Tarea 6: Comprueba el estado de Secure Boot desde el entorno live

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Qué significa: Secure Boot está activado. Bien. Lo mantendremos activado y trabajaremos con ello.

Decisión: Procede con Secure Boot activado a menos que tengas una situación concreta de controladores que lo obligue a apagarse (raro, pero ocurre).

Copias de seguridad que realmente cuentan (y cómo demostrarlas)

Las copias de seguridad no son “copié unas carpetas una vez”. Las copias de seguridad son “puedo restaurar bajo presión”. Estás a punto de editar los metadatos más críticos de la máquina. Así que necesitas:

  • Copia de archivos de tus datos personales (Documentos, proyectos, claves, fotos, etc.).
  • Claves de recuperación para Windows BitLocker si está habilitado.
  • Medios de recuperación de arranque (USB de recuperación de Windows y tu USB instalador de Ubuntu).

Lista de comprobación en el lado de Windows (haz esto en Windows)

Desde una perspectiva operativa: la mejor copia de seguridad de Windows es la que ya has probado. Si no lo hiciste, haz una prueba rápida de restauración de al menos un archivo. Además, guarda la clave de recuperación de BitLocker en un lugar que no sea el mismo dispositivo.

Tarea 7: Verifica que puedes ver el disco de copia externo y su sistema de archivos (desde Ubuntu live)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME      SIZE TYPE FSTYPE MOUNTPOINT
nvme0n1 953.9G disk
nvme0n1p1 100M part vfat
nvme0n1p3 450G part ntfs
sda     931.5G disk exfat
sda1    931.5G part exfat  /media/ubuntu/BackupDrive

Qué significa: Tu disco externo está presente (sda1) y montado. Genial. Si no está montado, móntalo mediante el gestor de archivos o udisksctl mount.

Decisión: No procedas hasta que el destino de la copia esté accesible.

Tarea 8: Crea una verificación de integridad rápida de tus archivos más importantes

cr0x@server:~$ cd /media/ubuntu/BackupDrive
cr0x@server:~$ sha256sum my-keys.tar my-photos.zip > SHA256SUMS.txt
cr0x@server:~$ cat SHA256SUMS.txt
b1f2...  my-keys.tar
9a8c...  my-photos.zip

Qué significa: Has creado hashes que podrás verificar más tarde tras copiar o restaurar. Así detectas escenarios de “copia exitosa” pero “archivo corrupto”.

Decisión: Conserva el archivo de sumas con la copia de seguridad.

Tarea 9: Haz una instantánea de la tabla de particiones actual (barato, evidencia útil)

cr0x@server:~$ sudo sgdisk --backup=/media/ubuntu/BackupDrive/nvme0n1-gpt.bin /dev/nvme0n1
cr0x@server:~$ ls -lh /media/ubuntu/BackupDrive/nvme0n1-gpt.bin
-rw-r--r-- 1 root root 17K Feb  5 12:18 /media/ubuntu/BackupDrive/nvme0n1-gpt.bin

Qué significa: Ahora tienes una copia binaria de la tabla GPT. Si alguien (incluyéndote) la lía, tienes una oportunidad de restaurar la estructura.

Decisión: Almacénala fuera de la máquina. Es pequeña e invaluable.

Estrategia de particionado para arranque dual UEFI/GPT

Aquí está la regla central: Windows posee sus particiones; Ubuntu obtiene nuevas particiones talladas desde el espacio libre. Tu trabajo es crear ese espacio libre de forma segura y luego asignarlo limpiamente.

Disposición recomendada (práctica, no teórica)

  • ESP (existente): 100–512MB FAT32, montada en /boot/efi. No formatear.
  • root de Ubuntu: 40–100GB ext4 montada en /. Más grande si instalas juegos o grandes toolchains.
  • Swap: opcional como partición; Ubuntu puede usar un swapfile. Si hibernas Linux, planifica swap apropiadamente (normalmente ≥ RAM).
  • Home: partición separada opcional. Bueno para reinstalaciones limpias, pero no es magia.

Para la mayoría de portátiles: una partición root + swapfile está bien. Para estaciones de trabajo donde reinstalas a menudo: separar /home es sensato.

Sobre el cifrado: elige tu radio de impacto

Ubuntu ofrece cifrado de disco completo (LUKS). Es una buena opción por defecto si tu modelo de amenazas incluye “portátil perdido” o “persona curiosa con un destornillador”. También cambia tus procedimientos de recuperación y puede complicar algunos flujos de reparación de arranque dual si no entiendes lo que hay dentro del contenedor cifrado.

Si quieres “cero sorpresas”, elige:

  • Mantener Windows tal cual (BitLocker permanece si ya está activado).
  • Cifrar Ubuntu si toleras escribir una frase de contraseña al arrancar y estás cómodo con los pasos de recuperación.

Tarea 10: Mide el espacio libre real y el uso actual

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  3.1G  2.1M  3.1G   1% /run
/dev/sr0       iso9660 3.7G 3.7G     0 100% /cdrom
/dev/loop0     squashfs 2.4G 2.4G     0 100% /rofs

Qué significa: En el entorno live, df no muestra el uso del disco interno a menos que lo montes. Esto es un recordatorio: no adivines. Si necesitas el uso de Windows, compruébalo en Windows Disk Management.

Decisión: Reduce Windows desde Windows. Usa herramientas de Linux principalmente para identificación y validación.

¿Cuánto espacio deberías asignar?

Mi línea base con opinión: 60GB para root de Ubuntu si haces desarrollo, contenedores o mantienes algunos kernels. Si eres usuario ligero, 40GB funciona. Si haces trabajo serio con contenedores, 100–200GB no es excesivo; las imágenes de contenedores se multiplican como conejos en primavera.

Un chiste corto #2: El espacio en disco es el único recurso que se hace más pequeño en cuanto dejas de mirarlo.

Secure Boot: mantenlo activado, comprende lo que cambia

Secure Boot no es tu enemigo. Es solo estricto. La cadena de arranque por defecto de Ubuntu en Secure Boot suele ser:

  • El firmware verifica shim (firmado).
  • shim verifica GRUB (firmado).
  • GRUB carga el kernel (firmado).
  • El kernel aplica reglas de firma de módulos según la política y configuración.

Cuándo te pedirán MOK (Machine Owner Key)

Si instalas controladores de terceros (común con NVIDIA), Ubuntu puede pedir inscribir una clave vía MOK. Es normal. Establecerás una contraseña de un solo uso durante la instalación y, en el siguiente reinicio, verás una pantalla azul del gestor MOK para inscribir la clave.

Tarea 11: Comprueba herramientas de verificación de Secure Boot y estado

cr0x@server:~$ sbverify --version
sbverify version 0.9.4
cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: ...

Qué significa: Puedes inspeccionar claves inscritas y verificar binarios EFI si es necesario. Normalmente no lo necesitarás, pero cuando algo falle a las 2 a.m. agradecerás que existan las herramientas.

Decisión: Si Secure Boot está activado y Ubuntu arranca, no “arregles” nada. La estabilidad gana a la curiosidad.

Una idea para la fiabilidad que vale la pena mantener parafraseada

Idea parafraseada (atribuida a Gene Kranz): “Sé duro y competente.” En términos de operaciones: mantén la calma, verifica y no improvises en rutas críticas.

Instalación: la ruta segura a través del instalador de Ubuntu

El instalador de Ubuntu 24.04 es generalmente amable, que es exactamente por qué es peligroso: hará cosas irreversibles rápidamente. Tu trabajo es elegir las opciones que mantengan el control en tus manos.

Paso 1: Reduce Windows (haz esto antes de instalar Ubuntu)

En Windows:

  • Desactiva Fast Startup.
  • Si BitLocker está habilitado, asegúrate de tener la clave de recuperación guardada fuera de la máquina. Considera suspender BitLocker antes de redimensionar, según la política de tu entorno.
  • Usa Disk Management para reducir la partición de Windows y dejar espacio no asignado.
  • Reinicia Windows una vez y luego realiza un apagado completo (no “reiniciar”).

Sí, es molesto. Sigue siendo la forma correcta.

Paso 2: Arranca el USB live de Ubuntu en modo UEFI

Ya validaste el modo UEFI antes. Hazlo de nuevo si no estás seguro. Los humanos fallan; los menús de firmware son peores.

Tarea 12: Confirma que existe espacio no asignado (desde Ubuntu live)

cr0x@server:~$ sudo parted /dev/nvme0n1 unit GiB print free
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 953GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number  Start  End    Size   File system  Name  Flags
        0.00GiB 0.00GiB 0.00GiB Free Space
 1      0.00GiB 0.10GiB 0.10GiB fat32            boot, esp
 2      0.10GiB 0.12GiB 0.02GiB                  msftres
 3      0.12GiB 450.00GiB 449.88GiB ntfs
 4      450.00GiB 451.00GiB 1.00GiB  ntfs        hidden, diag
        451.00GiB 953.00GiB 502.00GiB Free Space

Qué significa: El bloque “Free Space” al final es donde irá Ubuntu. Si no ves espacio libre, no redujiste Windows o estás mirando el disco equivocado.

Decisión: Si falta espacio libre, detente. No intentes “arreglarlo” con redimensiones aleatorias desde Linux.

Paso 3: Elige “Particionado manual” (o equivalente) en el instalador

Si el instalador ofrece “Instalar junto a Windows”, puede funcionar. También puede adivinar mal, especialmente en sistemas con múltiples discos, particiones de recuperación del proveedor, modos RAID o BitLocker. Si quieres “cero pérdida de datos”, toma el control manual.

Particionado manual: qué crear

  • No formatees la ESP. Establécela para montarla en /boot/efi.
  • Crea una partición ext4 en el espacio libre para /.
  • Opcional: crea una partición ext4 para /home.
  • Swap: usa swapfile (por defecto) salvo que hibernes.

Tarea 13: Verifica dos veces que no estás formateando la partición equivocada (chequeo de cordura)

cr0x@server:~$ sudo lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32       3A1B-2C4D
├─nvme0n1p2
├─nvme0n1p3 ntfs               1C2D3E4F5A6B7C8D
├─nvme0n1p4 ntfs               9E8D7C6B5A4F3E2D
└─nvme0n1p5

Qué significa: Puedes ver qué particiones ya tienen sistemas de archivos. El espacio libre aún no aparecerá como partición. Si ves una partición ext4 que no esperabas, detente e investiga.

Decisión: Solo formatea las nuevas particiones que crees para Ubuntu. Nunca formatees una partición NTFS que te importe. Nunca formatees la ESP.

Destino de instalación del gestor de arranque

En sistemas UEFI, el “disco objetivo del gestor de arranque” debe ser el disco que contiene la ESP (normalmente el mismo disco que Windows). Si pones Ubuntu en un segundo disco, sé deliberado: algunos firmwares solo arrancan de forma fiable desde el primer disco.

Instala actualizaciones y controladores de terceros (con cuidado)

Si tienes gráficos NVIDIA, el instalador puede ofrecer controladores de terceros. Tomarlos está bien, pero espera enrolamiento de MOK si Secure Boot está activado.

Verificación post-instalación: rutas de arranque, controladores y actualizaciones

No has “terminado” cuando aparece el escritorio. Has terminado cuando:

  • Ubuntu arranca de forma fiable con Secure Boot activado.
  • Windows sigue arrancando.
  • Puedes explicar (brevemente) cómo está arrancando el sistema.

Tarea 14: Confirma el estado de Secure Boot en Ubuntu instalado

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Qué significa: Mantuviste Secure Boot de extremo a extremo.

Decisión: Si Secure Boot está inesperadamente desactivado, revisa la configuración del firmware. No asumas que Ubuntu “lo apagó”. Los toggles de firmware pueden resetearse tras actualizaciones o eventos de CMOS.

Tarea 15: Confirma las entradas de arranque EFI (Ubuntu y Windows)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Qué significa: El firmware conoce ambos cargadores. Ubuntu está usando shim (shimx64.efi) lo cual es esperado con Secure Boot.

Decisión: Si falta “Windows Boot Manager”, no te asustes. Puede recrearse, pero primero comprueba el contenido de la ESP.

Tarea 16: Inspecciona el contenido de la ESP (confirma que no se sobrescribió nada)

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo ls -R /mnt/esp/EFI | head -n 50
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Microsoft:
Boot

/mnt/esp/EFI/ubuntu:
grubx64.efi
mmx64.efi
shimx64.efi

Qué significa: La ESP contiene directorios de ambos proveedores. Esto es cómo debería verse “junto a Windows”.

Decisión: Si falta el directorio Microsoft, probablemente formateaste la ESP o escribiste en el disco equivocado. La recuperación es posible pero ahora estás haciendo respuesta a incidentes.

Tarea 17: Confirma que GRUB ve Windows (y arréglalo si hace falta)

cr0x@server:~$ sudo grep -R "menuentry 'Windows" -n /boot/grub/grub.cfg | head
1234:menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1C2D3E4F5A6B7C8D' {

Qué significa: Windows está presente en la configuración de GRUB. Si no está allí, os-prober puede estar deshabilitado o Windows puede estar oculto debido a hibernación.

Decisión: Si Windows no se detecta, primero asegúrate de que Windows esté completamente apagado y no hibernado; luego ejecuta update-grub.

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

Qué significa: GRUB puede encadenar el arranque a Windows. Esa es la disposición más simple de arranque dual.

Decisión: Si Windows aún no aparece, usa el menú de arranque del firmware para arrancar Windows directamente y arregla la hibernación/Fast Startup.

Tarea 18: Comprueba el estado del kernel y los controladores (especialmente en portátiles)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ ubuntu-drivers devices | sed -n '1,120p'
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd000025A2sv00001028sd00000B42bc03sc00i00
vendor   : NVIDIA Corporation
model    : AD104M [GeForce RTX ...]
driver   : nvidia-driver-550 - distro non-free recommended
driver   : xserver-xorg-video-nouveau - distro free builtin

Qué significa: Puedes ver controladores recomendados. En sistemas con Secure Boot, la instalación de controladores propietarios puede desencadenar el enrolamiento de MOK.

Decisión: Si necesitas NVIDIA para tu carga de trabajo, instala el controlador recomendado y prepárate para inscribir MOK al reiniciar. Si solo necesitas un escritorio estable, puedes posponerlo.

Tarea 19: Comprueba si hay RAID/RST que pueda romper la visibilidad de discos en Linux

cr0x@server:~$ sudo lspci -nn | grep -i -E "sata|raid|nvme"
00:17.0 SATA controller [0106]: Intel Corporation Device [8086:7ae2]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

Qué significa: Esto no te dice definitivamente el modo de firmware, pero te ayuda a detectar sistemas donde Intel RST/RAID podría estar involucrado. Si Linux no puede ver el disco de Windows, el modo de almacenamiento del firmware es un sospechoso principal.

Decisión: Si el disco interno desaparece bajo Linux, revisa el firmware para RST/RAID vs AHCI y maneja con cuidado (especialmente con Windows instalado).

Tarea 20: Valida montajes de sistemas de archivos y fstab (evita sorpresas de arranque)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS / /boot/efi
/dev/nvme0n1p6 / ext4 rw,relatime,errors=remount-ro
/dev/nvme0n1p1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
cr0x@server:~$ sudo cat /etc/fstab
UUID=... / ext4 errors=remount-ro 0 1
UUID=3A1B-2C4D /boot/efi vfat umask=0077 0 1

Qué significa: Ubuntu monta la ESP por UUID. Eso es bueno. Los nombres de dispositivo pueden cambiar; los UUID son estables.

Decisión: Si /boot/efi no está montada, las actualizaciones de GRUB pueden escribirse en ningún sitio y futuras actualizaciones de kernel pueden producir una sorpresa divertida. Arréglalo ahora.

Tres micro-historias del mundo corporativo (para que no las repitas)

Micro-historia 1: Un incidente causado por una suposición equivocada

Una empresa mediana desplegó portátiles con arranque dual Ubuntu para desarrolladores: Windows para apps corporativas y Ubuntu para herramientas de compilación. El equipo de imagen asumió que “el disco siempre es /dev/nvme0n1” porque eso era cierto en las primeras docenas de modelos. Luego compras hicieron lo que hace compras y enviaron una remesa con dos discos internos: un NVMe pequeño para el SO y un SATA más grande para datos.

El script de automatización particionó el primer disco que vio, instaló Ubuntu y actualizó las entradas de arranque EFI. En los modelos con dos discos, “primer disco” no fue consistente. Algunas máquinas terminaron con GRUB en un disco, la ESP en otro y la entrada del gestor de arranque de Windows apuntando al vacío.

Los síntomas fueron caóticos: un subconjunto de portátiles arrancaba directo al firmware, algunas arrancaban Ubuntu pero no Windows, otras arrancaban Windows solo si pulsabas F12 en el momento adecuado. Parecía “rarito de Secure Boot” porque eso es lo que la gente dice cuando no sabe dónde vive el cargador.

La solución fue aburrida y ligeramente humillante: dejar de confiar en enumeraciones, identificar discos por modelo/serial y apuntar explícitamente al disco que contenía la ESP. También añadieron un paso previo: volcar lsblk y efibootmgr a registros antes de cualquier cambio. El siguiente despliegue tuvo una tasa de fallos cercana a cero, que es el único número aceptable para “tocamos el arranque”.

Lección: Los nombres de disco no son identidades. Trátalos como nombres de interfaz transitorios y usa identificadores estables.

Micro-historia 2: Una optimización que salió mal

Una organización distinta intentó “optimizar” el tiempo de instalación desactivando Secure Boot en el firmware durante la provisión. La idea era evitar las pantallas MOK, acelerar la instalación de controladores y luego reactivar Secure Boot al final. En laboratorio funcionó. En producción produjo un desastre silencioso.

En algunas versiones de firmware, alternar Secure Boot reestableció partes del orden de arranque o activó un comportamiento de arranque “fallback”. Algunos dispositivos reactivaban Secure Boot pero se negaban a arrancar componentes previamente instalados y sin firma o con firmas distintas sin una inscripción limpia. Otros reordenaban las entradas de arranque para favorecer a Windows, y el helpdesk recibía tickets como “Ubuntu desapareció”.

Peor aún, la automatización del equipo asumía que reactivar Secure Boot era un toggle reversible. No lo era. Era una transición de estado con efectos secundarios. El sistema instalado no estaba roto; las suposiciones sí.

Revirtieron la “optimización”, proveyeron con Secure Boot activado desde el primer arranque y aceptaron los minutos extra. Es asombroso lo rápido que avanzan las cosas cuando dejas de crear tus propios problemas.

Lección: No optimices la ruta crítica cambiando modos de seguridad a mitad de camino. Si quieres Secure Boot activado, mantenlo activado desde el inicio.

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

Una firma financiera tenía una política: antes de cualquier despliegue de SO, los técnicos debían capturar (1) una copia GPT, (2) una foto del menú de arranque del firmware mostrando el modo de arranque, y (3) una copia de los listados del directorio EFI desde la ESP después de instalar. Todos se quejaban de que era burocrático. Todos estaban equivocados.

Un día un portátil volvió de una reparación de proveedor con la placa madre reemplazada. El disco estaba intacto, pero las entradas NVRAM de arranque se habían ido—no había “ubuntu”, ni “Windows Boot Manager”. La máquina arrancaba al firmware y miraba al usuario como si nunca hubiera conocido sistemas operativos.

El técnico sacó el listado de la ESP almacenado en el ticket, confirmó que \EFI\Microsoft\Boot\bootmgfw.efi y \EFI\ubuntu\shimx64.efi deberían existir, luego montó la ESP desde un USB live y verificó que los directorios seguían allí. Bien. Los datos no habían desaparecido; los punteros sí.

Recrearon las entradas de arranque con efibootmgr y usaron la opción de arranque por archivo UEFI del firmware como reserva. Sin reparticionar. Sin reinstalar. Sin pérdida de datos. El ticket se cerró rápido, que es el mejor cumplido en operaciones.

Lección: Captura el estado antes y después de los cambios. Cuando el firmware olvida, no necesitas heroísmos: necesitas evidencia.

Guion de diagnóstico rápido

Cuando el arranque dual falla, la gente se agita: reinstala GRUB, alterna ajustes del BIOS, maldice a la luna. No lo hagas. Haz esto en orden para encontrar el cuello de botella rápido.

1) ¿Es un problema de modo de arranque (UEFI vs legacy)?

  • Desde un USB live: comprueba /sys/firmware/efi.
  • Si el SO instalado fue instalado en UEFI pero arrancas el USB de recuperación en modo legacy, perseguirás fantasmas.
cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Decisión: Haz coincidir el modo de arranque de tus herramientas con el sistema instalado.

2) ¿El firmware apunta al binario EFI correcto?

  • Usa efibootmgr -v en Ubuntu.
  • Si Ubuntu no arranca, usa el menú de arranque del firmware para elegir Windows Boot Manager o una ruta de archivo UEFI.
cr0x@server:~$ sudo efibootmgr -v | sed -n '1,20p'
BootCurrent: 0003
BootOrder: 0003,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Decisión: Si faltan entradas, recréalas. Si las entradas existen pero no funcionan, inspecciona la ESP y las firmas.

3) ¿La ESP está intacta y montada?

Si la ESP fue formateada, verás directorios faltantes. Si simplemente no está montada, las actualizaciones no llegan a donde deben.

cr0x@server:~$ sudo mount | grep -E "/boot/efi|/mnt/esp" || echo "ESP not mounted"
ESP not mounted

Decisión: Móntala, valida los directorios y luego repara las entradas de arranque.

4) ¿Windows está “sucio” (hibernado) y bloqueando la detección?

Fast Startup de Windows puede hacer que Linux se niegue a montar NTFS y también puede interferir con la detección de os-prober. Si Windows está “sucio”, arregla eso primero.

5) ¿Secure Boot está bloqueando un controlador/módulo?

Cuando los gráficos o Wi‑Fi fallan tras la instalación, Secure Boot puede estar aplicando reglas de firma de módulos. Eso no es razón para desactivar Secure Boot; es razón para instalar controladores firmados o inscribir MOK correctamente.

cr0x@server:~$ dmesg | grep -i -E "secure boot|lockdown|module verification" | tail -n 20
[    0.000000] secureboot: Secure boot enabled
[   12.345678] Lockdown: Loading of unsigned module is restricted; see man kernel_lockdown.7

Decisión: Si necesitas ese módulo, instálalo vía paquetes de Ubuntu que soporten el flujo de Secure Boot y enrola MOK cuando se te pida.

6) Solo entonces: reparación de GRUB

GRUB suele ser culpado, y a veces lo es. Pero arregla primero el modo de arranque/ESP/NVRAM subyacente. De lo contrario solo reinstalarás GRUB en el mismo contexto roto.

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

1) Síntoma: La partición de Windows se monta en solo lectura o no se monta

Causa raíz: Windows estaba hibernado o Fast Startup dejó NTFS “sucio”.

Solución: Arranca Windows, desactiva Fast Startup, realiza un apagado completo. Luego reintenta la detección.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

2) Síntoma: El instalador no muestra la opción “Instalar junto a Windows”

Causa raíz: Windows está en BitLocker y/o Fast Startup está habilitado, o el diseño del disco es inusual (discos dinámicos, modo RAID).

Solución: Usa particionado manual; asegúrate de que exista espacio libre; confirma modo UEFI; evita configuraciones de disco dinámico.

3) Síntoma: Tras la instalación, la máquina arranca directamente en Windows

Causa raíz: El orden de arranque del firmware aún prefiere Windows Boot Manager, o no se creó la entrada ubuntu.

Solución: Ajusta el orden de arranque en el firmware, o desde Ubuntu:

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0000
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu
cr0x@server:~$ sudo efibootmgr -o 0003,0000

Decisión: Si el firmware sigue revirtiendo, revisa políticas de proveedor “Windows-first” o actualizaciones de firmware que reseteen NVRAM.

4) Síntoma: Tras la instalación, la máquina arranca al firmware con “No bootable device”

Causa raíz: Entradas de arranque faltantes (NVRAM reseteada), ESP no encontrada o ESP corrupta.

Solución: Desde un USB live, monta la ESP y verifica que existan los binarios EFI. Recrea las entradas con efibootmgr. Si faltan binarios, puede que necesites reinstalar GRUB/shim en la ESP.

5) Síntoma: Ubuntu arranca, pero no hay Wi‑Fi

Causa raíz: Falta el paquete de firmware, o Secure Boot bloqueó un módulo externo, o el dispositivo no está soportado.

Solución: Identifica el dispositivo, instala el firmware correcto, consulta dmesg.

cr0x@server:~$ lspci -nn | grep -i network
02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) [8086:2725]
cr0x@server:~$ dmesg | grep -i firmware | tail -n 20
[    8.123456] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-*.ucode failed with error -2

Decisión: Instala el paquete de firmware faltante vía apt (requiere red; usa Ethernet o tethering por USB si es necesario).

6) Síntoma: Pantalla negra tras instalar el controlador NVIDIA con Secure Boot activado

Causa raíz: No se completó el enrolamiento de MOK, o el módulo no pasó la validación de firma.

Solución: Reinicia e inscríbelo en MOK cuando se te solicite. Si lo omitiste, reinstala el paquete del controlador y repite el flujo MOK, o arranca temporalmente con el controlador de código abierto para recuperarte.

7) Síntoma: El menú GRUB no muestra Windows

Causa raíz: os-prober no se ejecuta, Windows en hibernación, o archivos de arranque de Windows no están en la ESP esperada.

Solución: Asegura que Windows esté completamente apagado y sin hibernación, luego ejecuta update-grub. Verifica que la ESP contenga el directorio del cargador de Microsoft.

8) Síntoma: Solicitud de clave de recuperación de BitLocker después de instalar Ubuntu

Causa raíz: La configuración de arranque cambió (esperado) y BitLocker solicita verificación mediante la clave de recuperación.

Solución: Introduce la clave de recuperación y luego, en Windows, considera “suspender y reanudar BitLocker” para que vuelva a sellarse al nuevo estado de arranque. No desactives BitLocker permanentemente a menos que la política lo permita y entiendas el riesgo.

Listas de verificación / plan paso a paso

Plan A: Windows de un solo disco + Ubuntu en arranque dual (recomendado)

  1. En Windows: Haz copia de seguridad de archivos críticos en un disco externo. Guarda la clave de recuperación de BitLocker fuera del dispositivo.
  2. En Windows: Desactiva Fast Startup. Apagado completo.
  3. En Windows: Reduce la partición de Windows dejando espacio no asignado.
  4. Arranca USB de Ubuntu (UEFI): Valida el modo UEFI (/sys/firmware/efi existe).
  5. Desde Ubuntu live: Registra la salida de lsblk y parted -l (capturas o texto guardado).
  6. Desde Ubuntu live: Haz copia de seguridad de GPT (sgdisk --backup) al disco externo.
  7. Instalador: Usa particionado manual. Selecciona la ESP, móntala en /boot/efi, no la formatees.
  8. Instalador: Crea ext4 para / en el espacio libre. Opcional /home.
  9. Instalador: Mantén Secure Boot activado. Si te lo piden, establece contraseña MOK (apúntala temporalmente).
  10. Primer reinicio: Completa el enrolamiento MOK si se solicita.
  11. En Ubuntu: Ejecuta efibootmgr -v, confirma entradas para Windows y ubuntu.
  12. En Ubuntu: Ejecuta update-grub y confirma detección de Windows.
  13. Prueba de arranque: Arranca Windows desde GRUB y desde el menú de arranque del firmware. Confirma que BitLocker se comporta como esperas.

Plan B: Ubuntu en segundo disco, Windows en primer disco (funciona, pero sé deliberado)

  1. Confirma qué disco contiene la ESP. Normalmente el disco de Windows.
  2. Decide si colocar los archivos EFI de Ubuntu en la ESP existente o crear una segunda ESP en el disco de Ubuntu. Prefiere una sola ESP salvo que tengas una razón.
  3. Instala Ubuntu usando particionado manual, seleccionando explícitamente el disco/ESP correcto.
  4. Verifica el orden de arranque del firmware y asegúrate de que ambas entradas permanezcan tras reinicios y actualizaciones.

Plan C: Si algo sale mal, no “intentes cosas” a ciegas

  1. Arranca un USB live de Ubuntu en modo UEFI.
  2. Identifica discos (lsblk), encuentra la ESP (blkid), móntala, lista /EFI.
  3. Comprueba entradas NVRAM (efibootmgr -v).
  4. Solo entonces intenta reparar: recrea entradas o reinstala GRUB en la ESP.

Tarea 21: Recrear una entrada Windows Boot Manager faltante (si el archivo existe)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0003
BootOrder: 0004,0003,0000
Boot0004* Windows Boot Manager

Qué significa: Creaste una nueva entrada NVRAM apuntando al binario Microsoft EFI en la partición 1 (la ESP).

Decisión: Si falla, verifica el número de partición ESP y la ruta; las barras invertidas importan en rutas EFI.

Tarea 22: Recrear una entrada Ubuntu faltante (ruta shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi'
Boot0005* ubuntu

Qué significa: Rehiciste la entrada de Ubuntu para Secure Boot.

Decisión: Ponla primera en el orden de arranque si lo deseas.

Tarea 23: Establecer el orden de arranque explícitamente (porque la “amabilidad” del firmware es una amenaza)

cr0x@server:~$ sudo efibootmgr -o 0005,0004
BootOrder: 0005,0004

Qué significa: El firmware intentará Ubuntu primero y luego Windows.

Decisión: Si el orden no se mantiene, revisa configuraciones de firmware del proveedor que bloqueen el orden de arranque o actualizaciones de BIOS que reseteen NVRAM.

Preguntas frecuentes

1) ¿Debo desactivar Secure Boot para Ubuntu 24.04?

No, no por defecto. Ubuntu soporta bien Secure Boot. Desactívalo solo si tienes un bloqueo específico que entiendes (normalmente un módulo de kernel muy nicho).

2) ¿Ubuntu sobrescribirá Windows?

Sólo si se lo indicas. La opción peligrosa es “Borrar disco e instalar Ubuntu”. Usa particionado manual y nunca formatees particiones de Windows ni la ESP.

3) ¿Necesito una partición /home separada?

No es obligatoria. Es útil si reinstalas Ubuntu con frecuencia y quieres aislar los datos de usuario. Si no eres disciplinado con las copias de seguridad, una partición separada /home no te salvará de ti mismo.

4) ¿Se requiere una partición swap?

No. Ubuntu puede usar un swapfile. Si planeas hibernar Linux, deberías planificar la capacidad de swap intencionalmente y probar la hibernación. De lo contrario, swapfile es más simple y generalmente suficiente.

5) ¿Por qué BitLocker pide la clave de recuperación después de instalar Ubuntu?

Porque la configuración de arranque cambió y BitLocker hace su trabajo: detectó un nuevo entorno de arranque. Introduce la clave de recuperación y luego deja que Windows vuelva a sellar (a menudo suspendiendo/resumiendo BitLocker una vez). No pierdas esa clave.

6) Mi instalador no puede ver mi disco interno. ¿Qué hago?

Causa común en algunos portátiles: el modo de almacenamiento del firmware está en Intel RST/RAID. Linux puede no ver el disco como se espera. Cambiar a AHCI puede ayudar pero debe hacerse con cuidado para no romper el arranque de Windows. Si no conoces el procedimiento, detente y planifica el cambio.

7) GRUB no muestra Windows, pero Windows arranca desde el menú del firmware. ¿Es grave?

No es catastrófico. Significa que GRUB no detectó Windows o no está configurado para mostrarlo. Arregla la hibernación/Fast Startup de Windows y luego ejecuta update-grub. También puedes convivir con la selección desde el firmware, pero es más tosco.

8) ¿Puedo compartir una partición de datos entre Windows y Ubuntu?

Sí, normalmente mediante NTFS o exFAT. NTFS está bien para una partición de datos compartida si aseguras que Windows esté completamente apagado (sin Fast Startup/hibernación). Para mayor fiabilidad, evita guardar datos sensibles a permisos de Linux en NTFS.

9) ¿Debo elegir “instalar junto a Windows” o particionado manual?

Si quieres la máxima tasa de éxito frente a diseños OEM extraños, elige particionado manual. La opción “junto a” puede funcionar, pero es un atajo de automatización; tú eres quien carga con el riesgo.

10) Si estropeo el gestor de arranque, ¿mis datos se pierden?

Normalmente no. Los problemas de arranque suelen ser entradas NVRAM o contenido de la ESP. Tus archivos suelen estar intactos. El peligro es reparticionar impulsivamente por pánico. Para: monta la ESP, inspecciona y repara las entradas de arranque.

Conclusión: siguientes pasos después de arrancar correctamente

Si puedes arrancar Ubuntu y Windows de forma fiable con Secure Boot activado, ya has hecho la parte difícil: hiciste que la cadena de arranque vuelva a ser aburrida. Mantenla así.

Próximos pasos prácticos:

  • Actualiza Ubuntu y reinicia una vez para confirmar que las actualizaciones de kernel no rompen el flujo de Secure Boot.
  • Confirma las copias de seguridad: verifica una suma desde tu disco de respaldo y restaura un archivo como prueba.
  • Documenta tu diseño: guarda la salida de lsblk, parted -l y efibootmgr -v en un lugar seguro.
  • Decide tu SO predeterminado: ajusta el orden de arranque del firmware en consecuencia y mantiene el otro SO accesible vía GRUB o menú de firmware.
  • Mantén Fast Startup de Windows desactivado si accedes habitualmente a particiones de Windows desde Linux.

Eso es todo. Sin misticismo. Solo cambios disciplinados, estados verificados y la silenciosa satisfacción de un sistema que arranca igual dos veces.

← Anterior
QoS de red que realmente funciona (sin adivinar prioridades)
Siguiente →
Tu SSD está lento sin razón: el error del controlador de almacenamiento detrás

Deja un comentario