quiero usar mi raspberry pi como un ordenador domestico normal, ya lo he hecho y se que la potencia de esta maquina es mucha para lo que quiero hacer. pero siempre creo que es mejor tener un sistema mas que optimizado, sobretodo para algo de este estilo, asi que intento instalar void para tener algo lo mas minimalista posible. y por ende consuma poca ram, y procesador, con el tema de la grafica creo que no puedo hacer mucho mas que hacer overclock. intento instalar el tarball y para esto le he pedido que me lo explicara chatgpt. le pedi que tuviera como referencia estas 2 paginas:
no lo iba a leer directamente ya que ingles no hablo, pero al menos asi me seguro que chatgpt tenga en algo que basarse.
el resultado de esta especificación fue la siguiente:
Perfecto — voy a hacer tres cosas en este mensaje:
Traducir al español el bloque que pegaste (manteniendo el sentido técnico).
Explicarlo / aclarar puntos importantes (ej.: ^has_journal, por qué copiar qemu-aarch64-static, diferencias entre usar xbps -r vs chroot, etc.).
Darte un paso-a-paso adaptado a tu caso (Trisquel host → SSD M.2 → método ROOTFS) con los comandos exactos, y qué tipos seleccionar en cfdisk para cada partición (incluyendo tu partición swap de 2 GB).
1) Traducción (resumida y fiel) — Installing voidlinux on a RaspberryPi
Instalando Void Linux en una Raspberry Pi
Para instalar Void Linux en una Pi vamos a usar una instalación por chroot. (La documentación oficial de Void sobre instalaciones por chroot está en la web de Void).
Necesitamos el chroot porque las imágenes live están preparadas para tarjetas SD de 2 GB.
“Estas imágenes están preparadas para SD de 2 GB. Alternativamente, use los tarballs ROOTFS si quiere personalizar particiones y sistemas de archivos.”
El proceso se divide en 4 pasos generales:
Particionar el disco (la SD/SSD donde instalar).
Crear los sistemas de archivos en las particiones.
Copiar el rootfs (el tarball) al disco.
Configurar el rootfs a tu gusto (usuarios, servicios, etc.).
Requisitos previos
Dado que vamos a crear un sistema aarch64 (= ARM64) en un host x86, necesitaremos herramientas para ejecutar binarios aarch64 en la máquina x86. Para eso normalmente se usan binfmt-support y qemu-user-static.
Nota: instala qemu-user-static después de binfmt-support. Si se hace al revés a veces faltan los registros/archivos en /var/lib/binfmts/.
Ejemplo en Void (instalación desde Void):
sudo xbps-install binfmt-support qemu-user-static
Y hay que habilitar el servicio binfmt-support (en Void con runit se haría enlazando el servicio).
Particionar el disco
En el ejemplo se usan 2 particiones:
/dev/sda1 = boot → 64 MiB, marcada bootable, tipo vfat (código 0b en fdisk).
/dev/sda2 = root → resto del disco, tipo linux (83 en fdisk).
Con fdisk (sudo fdisk /dev/sda) se borran particiones con d, se crean con n, se marca la 1 como arranque con a y se cambia el tipo con t (0b para vfat, 83 para linux). Guardar con w.
Crear sistemas de archivos
mkfs.fat /dev/sda1 # boot vfat
mkfs.ext4 -O '^has_journal' /dev/sda2 # root ext4 (nota sobre journaling más abajo)
(En el texto original hay inconsistencia: -O '^has_journal' quita el journal; si quieres journaling, no uses la ^.)
Montar y extraer rootfs
MOUNT_PATH=/mnt/sdcard
sudo mount /dev/sda2 $MOUNT_PATH
sudo mkdir -p $MOUNT_PATH/boot
sudo mount /dev/sda1 $MOUNT_PATH/boot
sudo tar xfJ /ruta/a/void-rpi3-PLATFORMFS-YYYYMMDD.tar.xz -C $MOUNT_PATH
El rootfs de Void ya contiene /boot, por eso al extraer el tarball su contenido va a $MOUNT_PATH/boot.
Configurar el rootfs
El rootfs arranca, pero no incluye base-system (paquetes importantes) — conviene instalarlos.
El problema: los binarios dentro de rootfs son aarch64. Para ejecutarlos desde tu PC x86 necesitas emulación (qemu). Para ello se copia el binario qemu-aarch64-static dentro del rootfs (por ejemplo en /usr/bin o /bin del rootfs).
cp /bin/qemu-aarch64-static <tu-chroot>/bin
Después, puedes usar xbps-install -r <chroot> ... desde un host Void o entrar en chroot y ejecutar xbps-install desde dentro (ahí ya estarás ejecutando binarios aarch64 gracias a qemu).
Recomendaciones para un sistema usable
Instalar base-system (trae dhcpcd, wpa_supplicant, etc.):
env XBPS_ARCH=aarch64 xbps-install -r $MOUNT_PATH base-system
Habilitar sshd enlazando la unidad runit en /etc/runit/runsvdir/default/:
ln -s /etc/sv/sshd $MOUNT_PATH/etc/runit/runsvdir/default/
(Nota: es correcto enlazar a /etc/runit/runsvdir/default/ dentro del rootfs porque /var/service se monta o se crea en tiempo de ejecución).
Desactivar autenticación por contraseña en SSH editando sshd_config (recomendado).
Instalar openntpd para fijar la hora al arrancar (la Pi no tiene reloj hardware) y habilitarlo.
Activar dhcpcd.
Crear un usuario no root (añadir a wheel) y permitir sudo. Opcionalmente eliminar contraseña de root.
Añadir tu clave pública SSH a /home/usuario/.ssh/authorized_keys.
Limpieza
Quitar base-voidstrap si existe: xbps-remove -y base-voidstrap y reconfigurar: xbps-reconfigure -fa.
Borrar el binario /bin/qemu-aarch64-static que copiaste al rootfs.
Desmontar y retirar la tarjeta/SSD.
2) Aclaraciones y correcciones importantes (puntos clave)
mkfs.ext4 -O '^has_journal': la opción -O ^has_journal desactiva el journal de ext4. Por defecto mkfs.ext4 crea un sistema de archivos con journal. Si quieres un ext4 con journaling usa:
sudo mkfs.ext4 /dev/sdX2
Si quieres sin journaling (menos escrituras en SSD, pero menos tolerancia a cortes), entonces usa -O ^has_journal. Decide según prefieras.
¿Por qué copiar qemu-aarch64-static?
Cuando entras en chroot el kernel intenta ejecutar aarch64 binarios. binfmt-support + qemu-user-static en el host registra a qemu-aarch64-static como emulador para binarios aarch64 y permite que, al ejecutar un binario ARM desde el chroot, el host invoque qemu automáticamente. Copiar el binario dentro del rootfs asegura que la emulación funcione correctamente aun si el binfmt aún no está configurado o si ejecutas chroot directo.
En la práctica: en tu host (Trisquel) instala qemu-user-static y binfmt-support, luego copia /usr/bin/qemu-aarch64-static dentro del rootfs (por ejemplo a $MOUNT_PATH/usr/bin/).
xbps-install -r $MOUNT_PATH vs chroot
xbps-install -r $MOUNT_PATH permite instalar paquetes en un rootfs sin chroot si xbps está disponible en tu host (es decir, si runs xbps-install desde el host). En Trisquel no tendrás xbps por defecto; lo más sencillo es chrootear (emulando ARM con qemu) y ejecutar xbps-install dentro del chroot.
Alternativa avanzada: instalar xbps en el host (complicado en Debian). Por eso usar chroot es la ruta general y portable.
3) Guía paso-a-paso adaptada a tu caso (Trisquel host → SSD M.2 → ROOTFS) — comandos listos
Antes de empezar: reemplaza /dev/sdX por el dispositivo real de tu SSD. Confirma con lsblk antes y después de conectar el SSD.
A. Preparar host (Trisquel)
sudo apt update
# instala herramientas necesarias para emular ARM en el host
sudo apt install qemu-user-static binfmt-support rsync tar curl fdisk cfdisk gdisk parted
# habilita binfmt-support (en systemd suele activarse automáticamente)
sudo systemctl enable --now binfmt-support
B. Particionado con cfdisk (usando GPT) — incluyendo swap 2 GB
Yo recomiendo usar GPT (tu Pi 4 tiene EEPROM actualizada). En cfdisk harás 3 particiones:
/dev/sdX1 — boot — 64 MiB — tipo: EFI System (FAT32).
/dev/sdX2 — root — (resto del disco - 2 GiB) — tipo: Linux filesystem.
/dev/sdX3 — swap — 2 GiB — tipo: Linux swap.
Comandos/flujo con cfdisk:
Lanza cfdisk:
sudo cfdisk /dev/sdX
Si te pregunta el tipo de tabla de particiones elige gpt (o "dos/gpt" según versión).
En la interfaz:
New → Primary → tamaño 64MiB (o +64M) → luego Type → selecciona EFI System (o "EFI").
New → Primary → tamaño Remaining - 2GiB (si cfdisk no permite introducir expresiones, deja el tamaño por defecto y ajusta luego) → Type → Linux filesystem.
New → Primary → tamaño 2GiB (+2G) → Type → Linux swap.
Revisa que el orden sea: partition1 (boot, esp), partition2 (root), partition3 (swap).
Write → confirma → Quit.
Si cfdisk muestra nombres de tipos diferentes, busca: EFI System (para la FAT32), Linux filesystem (root), Linux swap (swap). En MBR las equivalencias serían: W95 FAT32 (LBA) para boot, Linux para root y Linux swap para swap.
C. Formatear particiones
(Verifica de nuevo los dispositivos: /dev/sdX1, /dev/sdX2, /dev/sdX3)
# /boot en FAT32
sudo mkfs.vfat -F 32 /dev/sdX1
# root ext4 (con journaling por defecto)
sudo mkfs.ext4 /dev/sdX2
# swap 2GB
sudo mkswap /dev/sdX3
# no actives swap en el host; lo activaremos en chroot/target si quieres:
# sudo swapon /dev/sdX3 # (opcional, no necesario ahora)
Nota sobre journaling: Si quieres reducir escrituras en el SSD puedes crear ext4 sin journal:
sudo mkfs.ext4 -O ^has_journal /dev/sdX2
Pero recuerda que sin journal la recuperación tras corte de corriente es menos robusta.
D. Montar y extraer el ROOTFS
MOUNT_PATH=/mnt/voidroot
sudo mkdir -p $MOUNT_PATH
sudo mount /dev/sdX2 $MOUNT_PATH
sudo mkdir -p $MOUNT_PATH/boot
sudo mount /dev/sdX1 $MOUNT_PATH/boot
# Extrae el tarball ROOTFS (ajusta ruta al archivo descargado)
sudo tar xfJ /ruta/a/void-rpi-aarch64-PLATFORMFS-YYYYMMDD.tar.xz -C $MOUNT_PATH
El tarball de Void ya contiene /boot, por eso su contenido terminará en $MOUNT_PATH/boot.
E. Preparar chroot (copiar qemu, bind mounts)
# Copiar el emulador qemu dentro del chroot (para que funcione la emulación)
sudo cp /usr/bin/qemu-aarch64-static $MOUNT_PATH/usr/bin/
# Montar pseudo-fs para que el chroot pueda funcionar bien
sudo mount --bind /dev $MOUNT_PATH/dev
sudo mount --bind /dev/pts $MOUNT_PATH/dev/pts
sudo mount --bind /proc $MOUNT_PATH/proc
sudo mount --bind /sys $MOUNT_PATH/sys
F. Entrar en chroot y configurar (ejecutando comandos ARM dentro)
Ahora entraremos al chroot. Gracias a binfmt-support + qemu-aarch64-static el host ejecutará los binarios ARM usando qemu.
sudo chroot $MOUNT_PATH /bin/bash
# ahora estás "dentro" del rootfs (emulado como arm64)
Dentro del chroot, lo primero es actualizar y usar xbps para instalar base-system:
# dentro del chroot
export XBPS_ARCH=aarch64
xbps-install -Su # actualizar índices y paquetes base
xbps-install -y base-system # instala dhcpcd, wpa_supplicant, openssh, etc.
Si xbps-install falla por falta de red, desde el host puedes preparar /etc/resolv.conf en el chroot (o antes de chroot):
# desde host (fuera del chroot)
sudo cp /etc/resolv.conf $MOUNT_PATH/etc/resolv.conf
G. Activar servicios runit (sshd, openntpd, dhcpcd)
Aún dentro del chroot (o creando enlaces desde fuera), activa servicios creando symlinks en la cadena de runit:
# dentro del chroot (ruta relativa al chroot)
ln -s /etc/sv/sshd /etc/runit/runsvdir/default/
ln -s /etc/sv/openntpd /etc/runit/runsvdir/default/
ln -s /etc/sv/dhcpcd /etc/runit/runsvdir/default/
Por qué este enlace: en Void, durante runtime /var/service normalmente contendrá los enlaces a /etc/sv/.... Al crear el link en /etc/runit/runsvdir/default/ nos adelantamos a ello (funciona bien para instalaciones por chroot).
H. Configurar SSH (seguridad)
Dentro del chroot, recomendamos desactivar autenticación por contraseña:
sed -ie 's/#PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
sed -ie 's/#KbdInteractiveAuthentication yes/KbdInteractiveAuthentication no/g' /etc/ssh/sshd_config
Si vas a usar claves SSH, copia tu clave pública desde tu laptop al chroot:
# fuera del chroot
USERNAME='tuusuario'
sudo mkdir -p $MOUNT_PATH/home/$USERNAME/.ssh
sudo sh -c "cat ~/.ssh/id_rsa.pub > $MOUNT_PATH/home/$USERNAME/.ssh/authorized_keys"
sudo chown -R 1000:1000 $MOUNT_PATH/home/$USERNAME/.ssh
(Ajusta UID/GID según el usuario que crearás).
I. Configurar NTP (openntpd) — importante para certificados
Dentro del chroot:
xbps-install -y openntpd
ln -s /etc/sv/openntpd /etc/runit/runsvdir/default/
J. Crear un usuario no-root (mejor hacerlo dentro del chroot)
Dentro del chroot:
# reemplaza 'me' por tu usuario
groupadd -g 1000 me
useradd -m -g me -G wheel -s /bin/bash me
passwd me
# permitir sudo para wheel (edita /etc/sudoers)
sed -ie 's/# %wheel ALL=(ALL) ALL/%wheel ALL=(ALL) ALL/g' /etc/sudoers
# eliminar contraseña de root (opcional)
passwd --delete root
K. Habilitar swap (si quieres activarlo automáticamente)
Dentro del chroot, puedes añadir /etc/fstab entrada para swap. Primero consigue UUIDs:
# fuera, en el host
sudo blkid /dev/sdX2 /dev/sdX1 /dev/sdX3
# copiar UUIDs
En $MOUNT_PATH/etc/fstab añade línea (usa el UUID real):
UUID=<UUID-de-root> / ext4 defaults 0 1
UUID=<UUID-de-boot> /boot vfat defaults 0 2
UUID=<UUID-de-swap> none swap sw 0 0
Si quieres activar la swap ahora en el host (no necesario), sudo swapon /dev/sdX3.
L. Limpiar y salir
Dentro del chroot:
xbps-remove -y base-voidstrap || true
xbps-reconfigure -fa
# salir del chroot
exit
Fuera del chroot:
# eliminar emulador si quieres
sudo rm $MOUNT_PATH/usr/bin/qemu-aarch64-static
# desmontar pseudo-fs
sudo umount $MOUNT_PATH/dev/pts
sudo umount $MOUNT_PATH/dev
sudo umount $MOUNT_PATH/proc
sudo umount $MOUNT_PATH/sys
# desmontar particiones
sudo umount $MOUNT_PATH/boot
sudo umount $MOUNT_PATH
Ahora el SSD está listo. Conéctalo a la Raspberry Pi 4 y arranca (asegúrate de que la EEPROM de la Pi permita boot por USB; dijiste que está actualizada). Deberías poder acceder por SSH (si tu Pi se conecta al Wi-Fi correctamente) o conectar un monitor/teclado para la primera vez.
Resumen sobre los tipos en cfdisk que me pediste (respuestas directas)
Partición /dev/sdX1 (boot, 64MiB): en GPT → EFI System (o EFI System Partition). Si usas MBR → W95 FAT32 (LBA).
Partición /dev/sdX2 (root, ext4): Linux filesystem (o Linux en MBR).
Partición /dev/sdX3 (swap, 2GiB): Linux swap.
(En cfdisk navega a Type/Type code y escoge los nombres anteriores.)
Advertencias / cosas a tener en cuenta
Confirma dispositivo con lsblk antes de escribir o formatear. Un error aquí borra datos.
MKFS ext4: decide si quieres journal o no. Por seguridad usa journaling por defecto. Si quieres menos escrituras en SSD puedes desactivar (-O ^has_journal) pero asume riesgos.
Firmware USB boot: tu Pi 4 debe tener EEPROM actualizada para arrancar desde USB; dijiste que sí está actualizada. Si alguna vez falla, prueba arrancar desde SD con /boot en la SD y raíz en SSD para diagnóstico.
Red en chroot: si xbps-install no puede acceder a red dentro del chroot, copia /etc/resolv.conf del host al chroot antes de chrootear.
Permisos de .ssh: asegúrate de fijar los propietarios y permisos correctos (700 para .ssh, 600 para authorized_keys).
Swap en SSD: usar swap en SSD provoca escrituras frecuentes; 2 GB está bien pero si quieres reducir desgaste considera swapfile en zram o evitar swap físico intenso.
Backups: siempre ten copia si hay datos importantes.
Si quieres, ahora te genero un script (series de comandos) para ejecutar en Trisquel que haga la mayor parte del trabajo interactivo (particionado no automático; formatea, monta, extrae el tar y deja listo para chroot) — lo dejo en modo semi-interactivo (por seguridad requiere confirmación en algunos puntos). ¿Lo quieres?
intente seguir el metodo explicado, pero me quede atrapado en el paso F. y de ahi no he podido seguir, lo que me impide continuar es lo siguiente:
xbps-install -Su
[*] Updating repository https://repo-default.voidlinux.org/current/aarch64/aarch64-repodata' ... ERROR: [reposync] failed to fetch file https://repo-default.voidlinux.org/current/aarch64/aarch64-repodata’: Transient resolver failure
no puedo sincronizarme con el repositorio de arm. y no he podido continuar despues de eso. ¿alguien ha tenido experiencia intentando instalar una distro por tarball? ¿sabe en que me estoy equivocando? ¿me falta algo en la publicación?
