"No se puede encontrar el dispositivo raíz" en una nueva instalación de ArchLinux

He instalado la última versión de ArchLinux (2014.06.01) en un MacBook Pro 8,1 (15 ", si eso es importante con respecto al hardware) de arranque dual con OSX siguiendo las instrucciones de la guía de instalación oficial . Sin embargo, cuando intente y reinicie en el sistema recién instalado, me deja caer en un shell de recuperación:

ERROR: device 'UUID=<snip>' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=<snip>'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty: job control turned off
[rootfs /]#

(Eliminé el UUID porque no quería escribirlo, pero es el mismo que me dio blkid(del disco de instalación) para la partición en la que está instalado ArchLinux)

Otros en línea fuentes sugieren que esto se debe a una obsoleta pacman, udev, filesystemo linuxpaquete. Sin embargo, describen este problema solo después de una actualización del núcleo desde un sistema en funcionamiento, no una instalación nueva. Reinstalé forzadamente estos paquetes desde el arch-chrootentorno mientras arrancaba en el disco de instalación, pero eso no cambió la situación.

En cambio, un poco de experimentación con mis grub.cfgprogramas muestra que lo que sea que se queje es el rootparámetro del linuxcomando que selecciona qué vmlinuzarchivo usar. De hecho, cambiar root=UUID=<snip>a root=LABEL=ArchLinuxo root=/dev/sda8(ambos describen dónde está instalado ArchLinux y ciertamente he usado la segunda versión con éxito antes con otra distribución) da Unable to find root device 'LABEL=ArchLinux'y Unable to find root device '/dev/sda8'respectivamente. Además, GRUB parece ser capaz de encontrar la partición por UUID, solo el kernel de Linux se queja de que no se encuentra, ya que el ramdisk inicial está cargado correctamente (es decir, este no es un error de GRUB como se describe aquí, sino más bien un error de Linux) .

Como nota al margen: el shell de recuperación está muy limitado, y la salida estándar no parece funcionar correctamente. Sin embargo, lsfunciona y la lista de archivos muestra un sistema de archivos básico (temporal), pero parece que faltan todos los dispositivos de disco /dev. Sin embargo, no sé si esto es parte del error o no.

Esto es similar, pero no es lo mismo, ya que Linux no encuentra el sistema de archivos raíz al arrancar , ya que la partición era ext4 desde el principio. Además, no es exactamente lo mismo, pero tal vez sea relevante. No se puede iniciar ArchLinux en Macbook Pro 7.1: cae en el shell de recuperación , sin embargo, allí cae en un ramfsshell en lugar de un rootfsshell y los mensajes de error difieren.

— hlt
fuente

Respuestas:

En lugar de arrancar con la imagen normal, utilicé la versión alternativa y logré arrancar en el sistema. Como resultado, Linux no pudo detectar ninguna unidad debido al block mkinitcpioenganche (responsable de los dispositivos de bloque) que falta en la imagen predeterminada. Esto fue debido a que es colocado después autodetecten /etc/mkinitcpio.conf. Para solucionar esto, la HOOKS=...línea en ese archivo debe cambiarse para que blockaparezca antesautodetect

Antes de la solución:

HOOKS="base udev autodetect block modconf filesystems keyboard fsck"

Después de la solución:

HOOKS="base udev block autodetect modconf filesystems keyboard fsck"

Ejecutar mkinitcpio -p linuxpara regenerar y initramfsluego solucionó el problema permanentemente.

— hlt
fuente

Fue muy útil :)

— ajukraine

Esto parece difícil de reproducir, tuve el mismo problema y lo solucioné, pero la misma unidad funcionó perfectamente bien en otra PC. La PC donde ocurrió el problema era una PC LGA775 bastante antigua y la solución anterior no era necesaria cuando se usaba una tabla de partición mbr. Entonces, el problema solo ocurrió cuando se usaba una tabla de particiones gpt en un sistema antiguo sin UEFI. No sé si las Mac siempre usan EFI, pero me pregunto qué tabla de particiones usó.

— MADforFUNandHappy

Ha pasado un tiempo, y el MacBook ya no existe, pero estoy bastante seguro de que usó GPT.

— hlt

Aunque recibo los mismos problemas que OP y su respuesta parece aplicarse a mí, no resolvió mi problema.

— Nathan Goings

Me encontré con un problema similar pero con una configuración diferente. Estoy usando ArchLinux en una máquina virtual y mi gestor de arranque es syslinux. Usé tu truco para cambiar el orden de los ganchos del núcleo, pero aún así terminé en un shell de rootfs.

Lo que fija el problema para mí estaba cambiando la APPENDlínea en mi syslinux.cfgdesde

APPEND root=UUID=<snip>

APPEND root=PARTUUID=<snip>

Puede agregar fácilmente el PARTUUIDal syslinux.cfgmediante un comando como blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfgasumir que su partición raíz es/dev/sda1

Luego puede usar su editor de texto favorito para mover la línea al espacio apropiado.

EDITAR: acabo de reconocer que el número de columna en el script awk pequeño puede variar, así que mejor eche un vistazo a la salida antes de conectarlo syslinux.cfg

— IlikePepsi
fuente