"Root-Gerät kann nicht gefunden werden" bei einer neuen ArchLinux-Installation

Ich habe die neueste Version von ArchLinux (2014.06.01) auf einem MacBook Pro 8,1 (15 ", falls dies in Bezug auf die Hardware von Belang ist) installiert . Doppelstart mit OSX gemäß den Anweisungen in der offiziellen Installationsanleitung . Versuchen Sie jedoch, den Computer neu zu starten In das neu installierte System wird ich in eine Wiederherstellungsshell versetzt:

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

(Ich habe die UUID entfernt, weil ich sie nicht ausschreiben wollte, aber sie ist dieselbe, die mir blkid(von der Installationsdiskette) für die Partition gegeben wurde, auf der ArchLinux installiert ist.)

Weitere Online - Quellen deuten darauf hin , dies ist aufgrund eines veralteten pacman, udev, filesystemoder linuxPaket. Sie beschreiben dieses Problem jedoch erst nach einem Kernel-Update von einem funktionierenden System, nicht nach einer Neuinstallation. Ich habe diese Pakete aus der arch-chrootUmgebung zwangsweise neu installiert, während sie auf der Installationsdiskette gebootet wurden, aber das hat die Situation nicht geändert.

Stattdessen zeigt ein wenig Experimentieren mit my grub.cfg, dass der rootParameter des linuxBefehls, der die vmlinuzzu verwendende Datei auswählt, das ist, worüber sich jemand beschwert . Tatsächlich Wechsel root=UUID=<snip>zu root=LABEL=ArchLinuxoder root=/dev/sda8(beide beschreiben , wo ArchLinux installiert ist , und ich habe sicherlich die zweite Version erfolgreich , bevor sie mit einer anderen Verteilung verwendet) ergibt Unable to find root device 'LABEL=ArchLinux'und Unable to find root device '/dev/sda8'jeweils. Außerdem scheint GRUB in der Lage zu sein, die Partition über die UUID zu finden, nur der Linux-Kernel beschwert sich darüber, dass sie nicht gefunden wurde, da die ursprüngliche Ramdisk ordnungsgemäß geladen wurde (dh dies ist kein GRUB-Fehler, wie hier beschrieben , sondern ein Linux-Fehler). .

Nebenbei bemerkt: Die Wiederherstellungsshell ist stark eingeschränkt, und die Standardausgabe scheint nicht ordnungsgemäß zu funktionieren. Trotzdem lsfunktioniert und das Auflisten von Dateien zeigt ein grundlegendes (temporäres) Dateisystem, aber alle Plattengeräte scheinen zu fehlen /dev. Ich weiß jedoch nicht, ob dies Teil des Fehlers ist oder nicht.

Dies ist ähnlich, aber nicht dasselbe, da Linux beim Booten kein Root-Dateisystem findet , da die Partition von Anfang an ext4 war . Ebenfalls nicht genau gleich, aber möglicherweise relevant ist " ArchLinux kann unter Macbook Pro 7.1 nicht gestartet werden" - wird in die Wiederherstellungsshell verschoben. Dort wird jedoch in eine ramfsShell anstelle einer rootfsShell verschoben, und die Fehlermeldungen unterscheiden sich.

— hlt
quelle

Antworten:

Anstatt mit dem normalen Image zu booten, habe ich die Fallback-Version verwendet und es geschafft, das System zu booten. Es stellte sich heraus, dass Linux keine Laufwerke erkennen konnte, da der block mkinitcpioHook (der für das Blockieren von Geräten verantwortlich ist) im Standard-Image fehlt. Dies war darauf zurückzuführen, dass es nach autodetectin platziert wurde /etc/mkinitcpio.conf. Um dies zu beheben, muss die HOOKS=...Zeile in dieser Datei so geändert werden, dass sie blockvorher kommtautodetect

Vor dem Update:

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

Nach dem Update:

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

Laufen mkinitcpio -p linux, um das initramfsdann zu regenerieren, hat das Problem dauerhaft behoben.

— hlt
quelle

Es war sehr hilfreich :)

— Ajukraine

Dies scheint schwer zu reproduzieren zu sein, ich hatte das gleiche Problem und dieses Problem wurde behoben, aber dasselbe Laufwerk funktionierte auf einem anderen PC einwandfrei. Der PC, auf dem das Problem auftrat, war ein veralteter LGA775-PC, und die obige Lösung war bei Verwendung einer mbr-Partitionstabelle nicht erforderlich. Das Problem trat also nur auf, wenn eine gpt-Partitionstabelle auf einem alten System ohne UEFI verwendet wurde. Ich weiß nicht, ob Macs immer EFI verwenden, aber ich frage mich, welche Partitionstabelle Sie verwendet haben?

— MADforFUNandHappy

Es ist schon eine Weile her und das MacBook ist nicht mehr da, aber ich bin mir ziemlich sicher, dass es GPT verwendet.

— hlt

Obwohl ich die gleichen Probleme wie bei OP habe und Ihre Antwort auf mich zuzutreffen scheint, hat sie mein Problem nicht gelöst.

— Nathan Goings

Ich bin auf ein ähnliches Problem gestoßen, aber mit einem anderen Setup. Ich verwende ArchLinux in einer virtuellen Maschine und mein Bootloader ist Syslinux. Ich habe deinen Trick benutzt, um die Reihenfolge der Kernel-Hooks zu ändern, bin aber trotzdem in einer rootfs-Shell gelandet.

Was das Problem für mich behoben hat, war die Änderung der APPENDZeile in meinem syslinux.cfgvon

APPEND root=UUID=<snip>

APPEND root=PARTUUID=<snip>

Sie können das einfach anhängen PARTUUID, syslinux.cfgindem Sie einen Befehl verwenden, der der blkid | grep sda1 | awk '{ print $7 }' >> /boot/syslinux/syslinux.cfgAnnahme entspricht, dass Ihre Root-Partition vorhanden ist/dev/sda1

Anschließend können Sie Ihren bevorzugten Texteditor verwenden, um die Linie an die entsprechende Stelle zu verschieben.

BEARBEITEN: Ich habe gerade erkannt, dass die Spaltennummer im kleinen awk-Skript variieren kann. Schauen Sie sich also die Ausgabe genauer an, bevor Sie sie weiterleiten syslinux.cfg

— IlikePepsi
quelle