"Impossibile trovare il dispositivo root" su una nuova installazione di ArchLinux

Ho installato l'ultima versione di ArchLinux (2014.06.01) su un MacBook Pro 8,1 (15 ", se è importante per quanto riguarda l'hardware) con doppio avvio con OSX seguendo le istruzioni nella guida ufficiale all'installazione . Tuttavia, quando provi e riavvia nel sistema appena installato, mi fa cadere in una shell di ripristino:

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

(Ho rimosso l'UUID perché non volevo scriverlo, ma è lo stesso di quello che mi è stato dato blkid(dal disco di installazione) per la partizione su cui ArchLinux è installato)

Altri in linea fonti suggeriscono che questo è dovuto ad un obsoleto pacman, udev, filesystemo linuxpacchetto. Tuttavia, descrivono questo problema solo dopo un aggiornamento del kernel da un sistema funzionante, non una nuova installazione. Ho reinstallato forzatamente questi pacchetti arch-chrootdall'ambiente durante l'avvio sul disco di installazione, ma ciò non ha modificato la situazione.

Invece, un po 'di sperimentazione con i miei grub.cfgmostra che tutto ciò di cui si lamenta è il rootparametro del linuxcomando che seleziona quale vmlinuzfile utilizzare. In effetti, il passaggio root=UUID=<snip>a root=LABEL=ArchLinuxo root=/dev/sda8(entrambi descrivono dove ArchLinux è installato e ho sicuramente usato la seconda versione con successo prima con un'altra distribuzione) dà Unable to find root device 'LABEL=ArchLinux'e Unable to find root device '/dev/sda8'rispettivamente. Inoltre, GRUB sembra essere in grado di trovare la partizione tramite UUID, solo il kernel di Linux si lamenta del fatto che non sia stato trovato, poiché il ramdisk iniziale è caricato correttamente (cioè questo non è un errore di GRUB come descritto qui ma piuttosto un errore di Linux) .

Come nota a margine: la shell di ripristino è fortemente limitata e l'output standard non sembra funzionare correttamente. Tuttavia, lsfunziona e l'elenco dei file mostra un file system di base (temporaneo), ma tutti i dispositivi su disco sembrano mancare /dev. Tuttavia, non so se questo sia parte dell'errore o meno.

Questo è simile, ma non uguale a quello di Linux che non trova il file system di root all'avvio , poiché la partizione era ext4 dall'inizio. Inoltre, non è esattamente lo stesso, ma forse rilevante è Impossibile avviare ArchLinux su Macbook Pro 7.1 - passa alla shell di ripristino , tuttavia, lì scende in una ramfsshell anziché in una rootfsshell e i messaggi di errore differiscono.

— hlt
fonte

Risposte:

Invece di fare il boot con l'immagine normale, ho usato la versione fallback e sono riuscito ad avviare il sistema. A quanto pare, Linux non è stato in grado di rilevare alcuna unità a causa del block mkinitcpiogancio (responsabile dei dispositivi a blocchi) mancante dall'immagine predefinita. Ciò era dovuto al fermo posto dopo autodetecta /etc/mkinitcpio.conf. Per risolvere questo problema, la HOOKS=...riga in quel file deve essere cambiata in modo che blockvenga primaautodetect

Prima della correzione:

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

Dopo la correzione:

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

In esecuzione mkinitcpio -p linuxper rigenerare initramfsil problema risolto in modo permanente.

— hlt
fonte

È stato molto utile :)

— Ajukraine,

Sembra difficile da riprodurre, ho avuto lo stesso problema e questo è stato risolto ma la stessa unità ha funzionato perfettamente su un altro PC. Il PC in cui si è verificato il problema era un PC LGA775 piuttosto vecchio e la soluzione sopra non era necessaria quando si utilizzava una tabella delle partizioni mbr. Quindi il problema si è verificato solo quando si utilizza una tabella delle partizioni gpt su un vecchio sistema senza UEFI. Non so se i Mac usano sempre EFI ma mi chiedo quale tabella delle partizioni hai usato?

— MADforFUNandHappy

È passato un po 'di tempo e il MacBook non esiste più, ma sono abbastanza sicuro che abbia usato GPT.

— hlt

Anche se sto ricevendo gli stessi problemi di OP e la tua risposta sembra applicarmi a me, non ha risolto il mio problema.

— Nathan Goings

Ho riscontrato un problema simile ma con una configurazione diversa. Sto usando ArchLinux in una macchina virtuale e il mio bootloader è syslinux. Ho usato il tuo trucco per cambiare l'ordine degli hook del kernel, ma sono ancora finito in una shell rootfs.

Che risolto il problema per me stava cambiando la APPENDriga nel mio syslinux.cfgda

APPEND root=UUID=<snip>

APPEND root=PARTUUID=<snip>

È possibile aggiungere facilmente il PARTUUIDal syslinux.cfgusando un comando come se si blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfgsupponga che sia la partizione di root/dev/sda1

Successivamente puoi usare il tuo editor di testo preferito per spostare la linea nello spazio appropriato.

EDIT: ho appena riconosciuto che il numero di colonna nel piccolo script awk può variare, quindi meglio dare un'occhiata all'output prima di reindirizzarlo in syslinux.cfg

— IlikePepsi
fonte