„Nie można znaleźć urządzenia roota” w nowej instalacji ArchLinux

Zainstalowałem najnowszą wersję ArchLinux (2014.06.01) na MacBooku Pro 8,1 (15 ", jeśli ma to znaczenie sprzętowe) podwójnego uruchamiania z OSX, postępując zgodnie z instrukcjami w oficjalnej instrukcji instalacji . Jednak przy ponownym uruchomieniu do nowo zainstalowanego systemu, umieszcza mnie w powłoce odzyskiwania:

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

(Usunąłem UUID, ponieważ nie chciałem go wpisywać, ale jest taki sam jak ten podany mi przez blkid(z dysku instalacyjnego) dla partycji, na której jest zainstalowany ArchLinux)

Inne internetowych źródła sugerują, jest to spowodowane przestarzałym pacman, udev, filesystemlub linuxopakowaniu. Opisują jednak ten problem dopiero po aktualizacji jądra z działającego systemu, a nie nowej instalacji. Wymusiłem ponowną instalację tych pakietów ze arch-chrootśrodowiska podczas rozruchu na dysk instalacyjny, ale to nie zmieniło sytuacji.

Zamiast tego trochę eksperymentów z moimi grub.cfgpokazuje, że cokolwiek narzeka, to rootparametr linuxpolecenia wybierającego, którego vmlinuzpliku użyć. Rzeczywiście, zmiana root=UUID=<snip>na root=LABEL=ArchLinuxlub root=/dev/sda8(oba opisują, gdzie jest zainstalowany ArchLinux i na pewno z powodzeniem korzystałem z drugiej wersji z inną dystrybucją) daje odpowiednio Unable to find root device 'LABEL=ArchLinux'i Unable to find root device '/dev/sda8'. Co więcej, GRUB wydaje się być w stanie znaleźć partycję na podstawie UUID, tylko jądro Linuksa skarży się, że nie zostało znalezione, ponieważ początkowy ramdysk jest poprawnie załadowany (tj. Nie jest to błąd GRUB, jak opisano tutaj, ale raczej błąd linux) .

Na marginesie: powłoka odzyskiwania jest poważnie ograniczona, a standardowe wyjście nie działa poprawnie. Niemniej jednak lsdziała, a lista plików pokazuje podstawowy (tymczasowy) system plików, ale wydaje się, że brakuje wszystkich urządzeń dyskowych /dev. Nie wiem jednak, czy jest to część błędu, czy nie.

Jest to podobne, ale nie takie samo, jak Linux nie znajduje systemu plików root podczas uruchamiania , ponieważ partycja była od początku ext4 . Nie jest to dokładnie to samo, ale być może istotne jest to, że nie można uruchomić ArchLinux na Macbooku 7.1 - spada do powłoki odzyskiwania , jednak tam spada do ramfspowłoki zamiast rootfspowłoki i komunikaty o błędach różnią się.

— hlt
źródło

Odpowiedzi:

Zamiast rozruchu z normalnym obrazem użyłem wersji awaryjnej i udało mi się uruchomić system. Jak się okazuje, Linux nie mógł wykryć żadnych dysków z powodu block mkinitcpiozaczepu (odpowiedzialnego za urządzenia blokowe) brakującego w domyślnym obrazie. Wynikało to z nim jest umieszczony po autodetectw /etc/mkinitcpio.conf. Aby to naprawić, HOOKS=...wiersz w tym pliku musi zostać zmieniony, aby blockpojawił się wcześniejautodetect

Przed poprawką:

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

Po poprawce:

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

Uruchomienie, mkinitcpio -p linuxaby zregenerować, a initramfsnastępnie naprawiło problem na stałe.

— hlt
źródło

To było bardzo pomocne :)

— ajukraine,

Wydaje się to trudne do odtworzenia, miałem ten sam problem i to naprawiłem, ale ten sam dysk działał idealnie dobrze na innym komputerze. Komputer, na którym pojawił się problem, był raczej starym komputerem LGA775, a powyższe rozwiązanie nie było konieczne w przypadku korzystania z tablicy partycji mbr. Tak więc problem pojawił się tylko w przypadku używania tabeli partycji gpt na starym systemie bez UEFI. Nie wiem, czy komputery Mac zawsze używają EFI, ale zastanawiam się, z której tabeli partycji korzystałeś?

— MADforFUN iHappy

Minęło trochę czasu, a MacBooka już nie ma, ale jestem pewien, że użył GPT.

— hlt

Chociaż otrzymuję te same problemy co OP i Twoja odpowiedź wydaje się dotyczyć mnie, nie rozwiązało to mojego problemu.

— Nathan Goings,

Wystąpił podobny problem, ale z inną konfiguracją. Używam ArchLinux na maszynie wirtualnej, a moim programem ładującym jest syslinux. Użyłem twojej sztuczki, zmieniając kolejność haków jądra, ale nadal skończyłem w powłoce rootfs.

Co ustalona problem dla mnie było zmienić APPENDlinię w moim syslinux.cfgz

APPEND root=UUID=<snip>

APPEND root=PARTUUID=<snip>

Możesz łatwo dołączyć PARTUUIDdo niego syslinux.cfgza pomocą polecenia, np. blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfgZakładając, że twoja partycja root to/dev/sda1

Następnie możesz użyć swojego ulubionego edytora tekstu, aby przenieść linię na odpowiednie miejsce.

EDYCJA: Właśnie rozpoznałem, że numer kolumny w małym skrypcie awk może się różnić, więc lepiej przyjrzyj się wynikowi przed włożeniem go do syslinux.cfg

— LubięPepsi
źródło