“Impossible de trouver le périphérique racine” sur une nouvelle installation ArchLinux


36

J'ai installé la dernière version d'ArchLinux (2014.06.01) sur un MacBook Pro 8,1 (15 ", si cela concerne le matériel). Double amorçage avec OSX en suivant les instructions du guide d'installation officiel . Cependant, lorsque vous essayez de redémarrer dans le système nouvellement installé, il me renvoie à un shell de récupération:

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

(J'ai supprimé l'UUID car je ne voulais pas le taper, mais c'est le même que celui qui m'a été donné par blkid(depuis le disque d'installation) pour la partition sur laquelle ArchLinux est installé)

D' autres en ligne sources suggèrent que cela est dû à un jour pacman, udev, filesystemou linuxpackage. Cependant, ils ne décrivent ce problème qu'après une mise à jour du noyau depuis un système en fonctionnement, pas une nouvelle installation. J'ai réinstallé de force ces paquets depuis l' arch-chrootenvironnement lors du démarrage sur le disque d'installation, mais cela n'a pas changé la situation.

Au lieu de cela, un peu d’expérimentation avec mes grub.cfgpreuves montre que tout ce qui se plaint est le rootparamètre de la linuxcommande qui sélectionne le vmlinuzfichier à utiliser. En effet, le passage root=UUID=<snip>à root=LABEL=ArchLinuxou root=/dev/sda8(les deux décrivent l’emplacement où ArchLinux est installé et j’ai certainement utilisé la deuxième version avec succès auparavant avec une autre distribution) donne Unable to find root device 'LABEL=ArchLinux'et Unable to find root device '/dev/sda8'respectivement. En outre, GRUB semble être capable de trouver la partition par UUID, seul le noyau Linux se plaint de ne pas l’avoir trouvée, car le disque virtuel initial est correctement chargé (c’est-à-dire qu’il ne s’agit pas d’une erreur GRUB telle que décrite ici, mais d’une erreur Linux). .

Remarque: le shell de récupération est extrêmement limité et la sortie standard ne semble pas fonctionner correctement. Néanmoins, les lstravaux et la liste des fichiers montrent un système de fichiers de base (temporaire), mais tous les disques semblent manquer /dev. Cependant, je ne sais pas si cela fait partie de l'erreur ou non.

Ceci est similaire, mais pas identique car Linux ne trouve pas le système de fichiers racine lors du démarrage , car la partition était ext4 depuis le début. Également différent, mais il est peut-être pertinent de ne pas pouvoir démarrer ArchLinux sur Macbook Pro 7.1 - il est transféré au shell de récupération . Toutefois, il tombe dans un ramfsshell plutôt que dans un rootfsshell et les messages d'erreur diffèrent.

Réponses:


34

Au lieu de démarrer avec l'image normale, j'ai utilisé la version de secours et j'ai réussi à démarrer dans le système. En fin de compte, Linux n’a détecté aucun lecteur car le block mkinitcpioraccord (responsable des périphériques en mode bloc) était absent de l’image par défaut. Cela était dû au fait qu'il soit placé après autodetectdans /etc/mkinitcpio.conf. Pour résoudre ce problème, la HOOKS=...ligne de ce fichier doit être modifiée afin qu'elle blockvienne avantautodetect

Avant le correctif:

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

Après le correctif:

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

En cours mkinitcpio -p linuxd' exécution pour régénérer le initramfspuis résolu le problème en permanence.


C'était très utile :)
ajukraine

Cela semble difficile à reproduire, j'avais le même problème et cela a été corrigé, mais le même lecteur a parfaitement fonctionné sur un autre ordinateur. Le PC sur lequel le problème est survenu est un PC LGA775 plutôt ancien et la solution ci-dessus n’est pas nécessaire lors de l’utilisation d’une table de partition mbr. Le problème ne survient donc que lors de l'utilisation d'une table de partition gpt sur un ancien système sans UEFI. Je ne sais pas si les Mac utilisent toujours EFI, mais je me demande quelle table de partition avez-vous utilisée?
MADforFUNandHappy

Cela fait longtemps, et le MacBook n’est plus, mais je suis à peu près sûr qu’il utilisait la technologie GPT.
Hlt

Bien que j'obtienne les mêmes problèmes que OP et que votre réponse semble s'appliquer à moi, cela n'a pas résolu mon problème.
Nathan Goings

1

J'ai rencontré un problème similaire mais avec une configuration différente. J'utilise ArchLinux sur une machine virtuelle et mon chargeur de démarrage est syslinux. J'ai utilisé votre astuce pour changer l'ordre des crochets dans le noyau, mais je me suis quand même retrouvé dans un rootfs-shell.

Ce qui a réglé le problème pour moi, c’était de changer la APPENDligne de syslinux.cfgdépart.

APPEND root=UUID=<snip>

à

APPEND root=PARTUUID=<snip>

Vous pouvez facilement ajouter le PARTUUIDà la syslinux.cfgen utilisant une commande comme en blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfgsupposant que votre partition racine est/dev/sda1

Ensuite, vous pouvez utiliser votre éditeur de texte favori pour déplacer la ligne dans l'espace approprié.

EDIT: Je viens de reconnaître que le numéro de colonne dans le petit script awk peut varier, il est donc préférable d’examiner le résultat avant de le rediriger vers syslinux.cfg

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.