“Não foi possível encontrar o dispositivo raiz” em uma nova instalação do ArchLinux

Instalei a versão mais recente do ArchLinux (2014.06.01) em um MacBook Pro 8,1 (15 ", se isso for importante em relação ao hardware) com inicialização dupla com o OSX seguindo as instruções no guia de instalação oficial . No entanto, ao tentar reinicializar no sistema recém-instalado, ele me coloca em um shell de recuperação:

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 /]#

(Eu removi o UUID porque não queria digitá-lo, mas é o mesmo que me foi fornecido blkid(a partir do disco de instalação) para a partição em que o ArchLinux está instalado)

Outros on-line fontes sugerem que este é devido a um desatualizado pacman, udev, filesystemou linuxpacote. No entanto, eles descrevem esse problema somente após uma atualização do kernel de um sistema em funcionamento, não uma nova instalação. Eu forcei a reinstalação desses pacotes do arch-chrootambiente enquanto inicializado no disco de instalação, mas isso não mudou a situação.

Em vez disso, um pouco de experimentação com meus grub.cfgprogramas mostra que tudo o que é reclamado é o rootparâmetro para o linuxcomando selecionar o vmlinuzarquivo a ser usado. De fato, mudar root=UUID=<snip>para root=LABEL=ArchLinuxou root=/dev/sda8(ambos descrevem onde o ArchLinux está instalado e eu certamente usei a segunda versão com êxito antes com outra distribuição) dá Unable to find root device 'LABEL=ArchLinux'e Unable to find root device '/dev/sda8'respectivamente. Além disso, o GRUB parece ser capaz de encontrar a partição pelo UUID, apenas o kernel do linux reclama por não ter sido encontrado, pois o ramdisk inicial é carregado corretamente (ou seja, este não é um erro do GRUB conforme descrito aqui, mas sim um erro do linux) .

Como uma observação lateral: o shell de recuperação é severamente limitado e a saída padrão não parece funcionar corretamente. No entanto, os lstrabalhos e a listagem de arquivos mostram um sistema de arquivos básico (temporário), mas todos os dispositivos de disco parecem estar ausentes /dev. No entanto, não sei se isso faz parte do erro ou não.

Isso é semelhante, mas não é o mesmo que o Linux não encontra o sistema de arquivos raiz durante a inicialização , pois a partição foi ext4 desde o início. Também não é exatamente o mesmo, mas talvez relevante seja Não é possível inicializar o ArchLinux no Macbook Pro 7.1 - cai para o shell de recuperação ; no entanto, ele cai em um ramfsshell em vez de em um rootfsshell e as mensagens de erro são diferentes.

— hlt
fonte

Respostas:

Em vez de inicializar com a imagem normal, usei a versão fallback e consegui inicializar no sistema. Como se vê, o Linux não conseguiu detectar nenhuma unidade devido ao block mkinitcpiogancho (responsável por dispositivos de bloco) ausente na imagem padrão. Isto foi devido ao fato de ter sido colocado depois de autodetectdentro /etc/mkinitcpio.conf. Para corrigir isso, a HOOKS=...linha desse arquivo precisa ser alterada para que blockvenha antesautodetect

Antes da correção:

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

Após a correção:

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

A execução mkinitcpio -p linuxpara regenerar initramfso problema foi corrigido permanentemente.

— hlt
fonte

Foi muito útil :)

— ajukraine 25/10

Isso parece difícil de reproduzir, eu tive o mesmo problema e isso foi corrigido, mas a mesma unidade funcionou perfeitamente em outro PC. O PC onde ocorreu o problema era um PC LGA775 bastante antigo e a solução acima não era necessária ao usar uma tabela de partição mbr. Portanto, o problema ocorreu apenas ao usar uma tabela de partição gpt em um sistema antigo sem UEFI. Não sei se os Macs sempre usam EFI, mas gostaria de saber qual tabela de partição você usou?

— MADforFUNandHappy

Já faz um tempo, e o MacBook não existe mais, mas tenho certeza que ele usa GPT.

— hlt

Embora eu esteja tendo os mesmos problemas do OP e sua resposta pareça se aplicar a mim, isso não resolveu o meu problema.

— Nathan Goings

Corri para um problema semelhante, mas com uma configuração diferente. Estou usando o ArchLinux em uma máquina virtual e meu carregador de inicialização é o syslinux. Eu usei seu truque para mudar a ordem dos ganchos do kernel, mas ainda assim acabei em um shell rootfs.

O que corrigiu o problema para mim foi alterando a APPENDlinha no meu syslinux.cfgde

APPEND root=UUID=<snip>

para

APPEND root=PARTUUID=<snip>

Você pode facilmente anexá-lo PARTUUIDao syslinux.cfgusando um comando como blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfgsupondo que sua partição raiz seja/dev/sda1

Depois, você pode usar seu editor de texto favorito para mover a linha para o espaço apropriado.

Edição: Acabei de reconhecer que o número da coluna no pequeno script awk pode variar, então é melhor dar uma olhada na saída antes de canalizá-la syslinux.cfg

— IlikePepsi
fonte