DEV Community

Erick Eduardo Ramos
Erick Eduardo Ramos

Posted on

Cómo solucionar `docker run` con `Exited (1)` en Raspberry Pi

#devops #docker #linux #tutorial

Cómo solucionar docker run con Exited (1) en Raspberry Pi

¿Por qué ocurre este error?

El código de salida 1 indica que el proceso principal del contenedor terminó con un error genérico. En Raspberry Pi, los casos más comunes son:

  • Arquitectura incompatible: La imagen se construyó para amd64 (x86_64), pero Raspberry Pi usa arm32v7 o arm64v8.
  • Falta de binarios compatibles: El ENTRYPOINT o CMD del contenedor ejecuta un binario compilado para otra arquitectura.
  • Problemas de permisos o recursos limitados (menos común, pero posible en dispositivos con poca RAM).

El hecho de que funcione en una VM pero no en hardware físico confirma que el problema es de arquitectura, ya que la VM probablemente emula x86_64.

Pasos para solucionarlo

1. Verifica la arquitectura del host 

uname -m
# En Raspberry Pi 4 (64-bit OS): aarch64
# En Raspberry Pi 3/Zero (32-bit OS): armv7l
Enter fullscreen mode Exit fullscreen mode

2. Verifica la arquitectura de tu imagen 

docker inspect myimage --format='{{.Architecture}}'
# Si muestra "amd64", NO es compatible con Raspberry Pi
Enter fullscreen mode Exit fullscreen mode

3. Construye la imagen para la arquitectura correcta

Opción A: Usa docker buildx (recomendado) 

# Crea un builder multi-plataforma
docker buildx create --name mybuilder --use

# Construye e impulsa la imagen para ARM
docker buildx build \
  --platform linux/arm/v7,linux/arm64 \
  -t myimage:latest \
  --push \
  .
Enter fullscreen mode Exit fullscreen mode

Nota: Si usas una imagen base como python:3.9-slim, asegúrate de que tenga soporte para ARM (la mayoría de las oficiales sí lo tienen).

Opción B: Usa qemu para emulación (si no puedes reconstruir) 

# Instala qemu y binfmt (solo una vez)
sudo apt update && sudo apt install -y qemu-user-static binfmt-support

# Registra el binfmt handler
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

# Ahora puedes ejecutar imágenes x86_64 (lento, pero funcional)
docker run --net=host -d -t myimage
Enter fullscreen mode Exit fullscreen mode

⚠️ Advertencia: La emulación es muy lenta y consume mucha CPU en Raspberry Pi. Solo úsala para depuración.

4. Verifica el log del contenedor 

docker run --net=host -t myimage  # Ejecuta sin -d para ver logs en tiempo real
# O si ya se creó el contenedor:
docker logs <container_id>
Enter fullscreen mode Exit fullscreen mode

Bloque de código corregido (ejemplo práctico) 

# 1. Verifica arquitectura
uname -m

# 2. Usa buildx para construir multi-arquitectura
docker buildx create --name pi-builder --use
docker buildx build \
  --platform linux/arm/v7 \
  -t myimage:latest \
  --load \
  .

# 3. Ejecuta sin -d para depurar
docker run --net=host -t myimage

# 4. Si todo funciona, ejecuta en modo daemon
docker run --net=host -d -t myimage
Enter fullscreen mode Exit fullscreen mode

Pro-tip: Evita este problema desde el inicio

  • Usa imágenes oficiales con soporte multi-arquitectura (python:3.11-slim, node:20-alpine, etc.).
  • En tu Dockerfile, especifica explícitamente la imagen base para ARM: 
  FROM arm32v7/python:3.9-slim  # Para Raspberry Pi 3/4 32-bit
  # O
  FROM arm64v8/python:3.9-slim  # Para Raspberry Pi 4/5 64-bit
Enter fullscreen mode Exit fullscreen mode
  • Usa docker manifest inspect para verificar disponibilidad de arquitecturas: 
  docker manifest inspect python:3.9-slim | grep -A1 '"platform"'
Enter fullscreen mode Exit fullscreen mode

✅ Verificación final: Si el contenedor sigue fallando, ejecuta strace dentro del contenedor (si tienes herramientas de depuración) o usa docker run --rm -it --entrypoint=/bin/sh myimage para inspeccionar manualmente el entorno.

Top comments (0)