Cómo solucionar E: Unable to locate package en Debian/Ubuntu (guía definitiva 2026)

Estás siguiendo un tutorial, copiás el comando exacto, y en vez del paquete instalándose obtenés esto:

$ sudo apt install nmap
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package nmap

El mensaje suena como si el paquete no existiera. Casi nunca es así. Lo importante para entender este error de una vez por todas es esto: "Unable to locate package" no es un error de red; es un error de metadatos. Apt te está diciendo que no tiene registro de lo que estás pidiendo, no que el paquete no exista en internet.

Vamos a entender por qué pasa y a resolver cada causa real, incluyendo el caso específico de Docker, que es donde este error aparece con más frecuencia hoy en día.

Qué está pasando realmente cuando corrés apt install

Escribir sudo apt install es, en el fondo, una consulta a una base de datos local, no una búsqueda en internet en tiempo real. Apt resuelve paquetes buscando en archivos de índice almacenados localmente en tu sistema —catálogos que listan cada paquete disponible desde los repositorios configurados en /etc/apt/sources.list y /etc/apt/sources.list.d/. Cuando corrés apt install, apt revisa estos catálogos locales para encontrar el paquete solicitado; el error significa que apt buscó en todos sus archivos de índice locales y no encontró ningún paquete que coincida con el nombre que diste.

Esto explica por qué el error puede aparecer incluso cuando el paquete existe perfectamente en los repositorios oficiales: tu copia local del catálogo está desactualizada, incompleta, o simplemente no incluye ese repositorio.

Hay tres puntos de falla comunes: tus componentes de repositorio (Universe, Multiverse) podrían estar deshabilitados; tu keyring GPG podría estar corrupto o vencido, haciendo que apt descarte silenciosamente repositorios no confiables; o tu configuración de arquitectura podría no incluir el formato binario que necesitás (i386 en amd64, por ejemplo). Cada una requiere un diagnóstico distinto, así que vamos en orden de frecuencia real.

Causa 1 (la más común, con enorme diferencia): nunca corriste apt update

El índice local de paquetes está desactualizado o vacío: nunca corriste apt-get update, o lo corriste hace tanto que el índice cacheado ya no refleja lo que ofrecen los repositorios. Es especialmente frecuente en instalaciones recién hechas y, sobre todo, dentro de contenedores Docker.

sudo apt update
sudo apt install nmap

El comando update no instala ni actualiza ningún paquete: solo refresca el catálogo. Pensalo como descargar el menú actualizado de un restaurante antes de hacer tu pedido. Sin un catálogo actualizado, apt no tiene forma de saber qué puede ofrecerte, aunque el paquete exista y esté perfectamente disponible en el repositorio remoto.

Buena práctica para no volver a toparte con esto: combiná ambos comandos siempre que instales algo en un entorno nuevo o poco usado:

sudo apt update && sudo apt install -y nmap

Causa 2: typo o nombre de paquete incorrecto

Antes de asumir un problema de configuración, descartá lo más simple. Muchos paquetes tienen nombres que no coinciden con el nombre de la herramienta o aplicación que buscás. Hay casos donde el nombre del paquete no coincide con el nombre de la app o dependencia a la que pertenece: el paquete de Docker se llama docker.io en vez de simplemente docker, y el paquete de VSCode se llama code en vez de VSCode.

Para verificar si el paquete existe y con qué nombre exacto, sin instalar nada:

apt-cache search nombre_aproximado
apt-cache policy nombre_exacto

El segundo comando es clave para diagnóstico: apt-cache policy [paquete] te dice exactamente qué repositorio provee el paquete y si está instalado; si la salida muestra "Unable to locate", el paquete no está en tu índice actual, y si muestra una tabla de versiones, el paquete está disponible y el problema está en otro lado.

Causa 3: el paquete vive en un repositorio deshabilitado (Universe, Multiverse)

Muchísimos paquetes populares no están en el repositorio main que viene habilitado por defecto. Muchos paquetes viven en universe o multiverse, que pueden estar deshabilitados por defecto.

Vía interfaz gráfica: abrí "Software y actualizaciones" (Software & Updates), andá a la pestaña "Ubuntu Software", marcá las casillas de main, universe, restricted y multiverse, cerrá y volvé a actualizar el caché con apt update.

Vía terminal (recomendado para servidores sin entorno gráfico):

sudo add-apt-repository universe
sudo add-apt-repository multiverse
sudo add-apt-repository restricted
sudo apt update

O editando directamente /etc/apt/sources.list, verificando que las líneas incluyan los cuatro componentes:

deb http://archive.ubuntu.com/ubuntu/ noble main universe restricted multiverse
deb http://archive.ubuntu.com/ubuntu/ noble-updates main universe restricted multiverse

Reemplazá el nombre de código de la versión (por ejemplo, noble para Ubuntu 24.04) según corresponda a tu sistema.

Importante para Debian puro (no Ubuntu): desde 2026, la mayoría de las instalaciones adoptó el nuevo formato DEB822, donde en vez de líneas crípticas en un único archivo, los repositorios ahora se almacenan como bloques estructurados en /etc/apt/sources.list.d/*.sources. Si tu sistema usa este formato, buscá el archivo correspondiente ahí en vez de editar sources.list directamente.

Causa 4: tu repositorio quedó comentado o vacío

Un caso simple pero frecuente en instalaciones mínimas: los repositorios existen en el archivo de configuración pero están comentados con #.

cat /etc/apt/sources.list

Si ves algo como:

# deb http://deb.debian.org/debian bullseye main
# deb-src http://deb.debian.org/debian bullseye main

Ambas líneas están comentadas, así que apt no tiene ningún repositorio fuente desde donde localizar paquetes. La solución es descomentarlas (quitar el # inicial) y actualizar:

sudo sed -i 's/^# deb/deb/' /etc/apt/sources.list
sudo apt update

Causa 5: arquitectura faltante (paquetes de 32 bits en sistemas de 64 bits)

Esta causa confunde mucho porque el paquete "existe" y el nombre es correcto, pero sigue fallando. En 2026, la mayoría de las instalaciones de Linux son de 64 bits (amd64); sin embargo, muchos juegos, aplicaciones heredadas y toolchains de compilación cruzada requieren librerías de 32 bits (i386). Si pedís una librería de 32 bits en un sistema puramente de 64 bits, apt la reporta como "Unable to locate" porque ni siquiera está buscando binarios i386.

Verificá y habilitá la arquitectura secundaria explícitamente:

dpkg --print-architecture           # confirma tu arquitectura principal
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install nombre_paquete:i386

Causa 6: tu versión de Debian/Ubuntu llegó a fin de vida (EOL)

Las versiones de fin de vida tienen sus repositorios movidos a un servidor de archivo, haciendo que las URLs por defecto devuelvan errores. Si tu sistema es una versión antigua que ya no recibe soporte, apt update puede fallar silenciosamente para ciertos repositorios sin que lo notes de inmediato, y los paquetes más recientes simplemente no van a aparecer en tu índice.

Verificá tu versión y su estado de soporte:

lsb_release -a

Si tu versión está fuera de soporte, la solución de fondo no es un parche de configuración: es actualizar a una versión con soporte activo (sudo do-release-upgrade en Ubuntu), ya que seguir en una versión EOL también implica que no estás recibiendo parches de seguridad.

Causa 7 (la más frecuente en 2026): estás dentro de un contenedor Docker sin caché

Si tu error aparece dentro de un Dockerfile o de un contenedor recién creado, la causa es casi siempre la misma. Las imágenes oficiales de Docker vienen con cachés potencialmente desactualizadas, o sin caché en absoluto, para mantener el tamaño de la imagen reducido. Este patrón falla siempre:

# ❌ Falla casi siempre: la caché de paquetes está vacía
FROM ubuntu:24.04
RUN apt-get install -y curl
# E: Unable to locate package curl

La solución es encadenar update e install en la misma instrucción RUN, y limpiar el índice después para no inflar la imagen:

FROM debian:bookworm-slim
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        curl \
        wget \
        git \
    && rm -rf /var/lib/apt/lists/*

El flag --no-install-recommends evita instalar paquetes sugeridos innecesarios, manteniendo la imagen más liviana. Un error común es separar update e install en instrucciones RUN distintas: Docker cachea cada capa por separado, así que si el apt-get update queda en una capa cacheada de una build anterior, tu instalación puede fallar semanas después con el mismo error, aunque nada haya cambiado en tu Dockerfile.

Tabla de diagnóstico rápido

Situación	Causa probable	Primer comando
Instalación recién hecha o VM nueva	Índice nunca actualizado	sudo apt update
El paquete "debería existir" pero nada calza	Nombre de paquete incorrecto	apt-cache search / apt-cache policy
Paquete conocido, error persiste tras update	Repositorio universe/multiverse deshabilitado	Revisar sources.list o "Software & Updates"
sources.list tiene líneas con # al inicio	Repositorio comentado	sed para descomentar + apt update
Paquete de 32 bits en sistema de 64 bits	Arquitectura secundaria no habilitada	dpkg --add-architecture i386
Sistema muy antiguo, varios repos fallan al actualizar	Versión EOL	lsb_release -a + actualizar versión
Ocurre dentro de un Dockerfile o contenedor	Caché de apt vacía en la imagen base	apt-get update && apt-get install en el mismo RUN

El contraargumento: ¿agregar repositorios o PPAs de terceros a la ligera?

Cuando ninguna de las causas anteriores resuelve el problema, la tentación es agregar cualquier PPA o repositorio de terceros que prometa tener el paquete. Vale la pena hacerlo con cautela: se recomienda usar PPAs con moderación y solo de fuentes confiables, porque un repositorio de terceros mal mantenido puede introducir conflictos de versiones durante futuras actualizaciones del sistema, o directamente comprometer la seguridad si el mantenedor del PPA no es confiable. Antes de agregar una fuente externa, confirmá primero que el paquete realmente no está disponible en los repositorios oficiales para tu versión específica, consultando packages.debian.org o packages.ubuntu.com.

Resumen práctico según tu perfil

• Si sos vibe coder o estás prototipando en una VM o contenedor nuevo: el 90% de tus casos se resuelven con sudo apt update antes de instalar. Hacelo tu primer reflejo, no tu último recurso.
• Si mantenés Dockerfiles o imágenes base para producción: encadená siempre update e install en la misma instrucción RUN, y limpiá /var/lib/apt/lists/* al final para no inflar la imagen ni depender de una caché cacheada por Docker en una capa vieja.
• Si administrás servidores Debian/Ubuntu de larga duración: revisá periódicamente si tu versión sigue teniendo soporte activo, y confirmá que los componentes universe/multiverse estén habilitados si tu stack depende de paquetes que no son parte de main.

En conclusión, "Unable to locate package" no significa que el paquete no exista: significa que tu catálogo local de apt no lo conoce, sea porque nunca actualizaste, porque el repositorio correcto está deshabilitado o comentado, porque falta la arquitectura, o porque estás en un contenedor con caché vacía. Diagnosticá con apt-cache policy antes de tirar soluciones al azar, y vas a resolver este error en menos de un minuto casi siempre.

¿Te apareció con una variante distinta? Contame en los comentarios el mensaje exacto y el contexto (VM, Docker, servidor físico) y lo sumamos a la guía.