grub-probe: Fehler: Fehler beim Abrufen des kanonischen Pfads von / cow

Führen Sie die folgenden Schritte aus:

1. Starten Sie eine Live Linux-Sitzung.

2. Hängen Sie die / -Partition Ihres installierten Betriebssystems in /mnt

   sudo mount /dev/sda6 /mnt 

3. Richten Sie eine chroot -Umgebung ein:

   sudo chroot /mnt 

4. Sie befinden sich jetzt in einer „gefälschten“ Linux-Installation, die /mnt als / behandelt . Dies bedeutet, dass sich alle für GRUB erforderlichen Dateien in /boot befinden, wo das System sie erwartet, und Sie können GRUB so installieren, als ob Sie Ihr installiertes System tatsächlich ausführen würden:

   sudo update-grub sudo grub-install /dev/sda 

Starten Sie jetzt neu und Sie sollten sehen, dass das GRUB-Menü normal angezeigt wird.

Kommentare

• Ich ‚ versuche, vom USB-Gerät zu installieren. Jedenfalls habe ich es auch ohne Montage versucht – gleicher Fehler. Können Sie den Fehler erklären?
• @elyashiv Bitte bearbeiten Sie Ihre Frage und erklären Sie, was Sie versuchen. Versuchen Sie, ein kaputtes System zu retten? Booten Sie ein Live-System vom USB? Wenn ja, sagen Sie es uns . Welches Betriebssystem verwenden Sie? Was lässt Sie denken, dass GRUB eine root-device -Option hat und was erwarten Sie von dieser Option? Haben Sie eine chroot -Umgebung eingerichtet? Wann immer Sie eine Frage stellen, müssen Sie genau erklären, was Sie versuchen, wir können ‚ nicht raten.
• oops, ich meinte -root -Verzeichnis
• @elyashiv dort ‚ ist auch nicht --root-directory. Lesen Sie hier meine Antwort , in der erklärt wird, wie grub neu installiert wird.
• Sehen Sie sich die erste Antwort an hier

Wenn grub sagt, dass der kanonische Pfad von etwas nicht aufgelöst werden konnte Dies bedeutet, dass es nicht vorhanden ist oder realpath() fehlgeschlagen ist.

Versuchen Sie in diesem Fall:

$ realpath /cow $ ls -la /cow 

Wenn beide Befehle „Datei oder Verzeichnis können nicht gefunden werden“ angeben, müssen Sie eine erstellen.

Wenn der zweite Befehl funktioniert, der erste jedoch nicht, überprüfen Sie, warum realpath() funktioniert nicht. Einer der Gründe kann sein, dass /proc nicht gemountet ist. In einigen Implementierungen von libc wird /proc/self/fd verwendet, um den kanonischen Pfad einer Datei abzurufen.

Kommentare

• Ich habe den ersten Befehl ausgeführt, aber nicht den zweiten.
• ME: root @ ubuntu: / # realpath / cow TERMINAL: / cow ME: # ls -la / cow TERMINAL: ls: unmöglich zu Zugriff ‚ / cow ‚: Keine Datei oder Ordner dieser Art (grob übersetzt).

Ich erhalte auch diesen Fehler und glaube nicht, dass er in einer Chroot passiert.

Hintergrund

Ich denke, dies ist der Fall, wenn systemd den Pfad nicht finden kann, weil er in einem Verzeichnis bereitgestellt ist. Der Unterschied besteht also darin, dass Sie beim Einrichten einer Chroot den Zugriff auf Hardware, einschließlich Laufwerke, bereits konfigurieren.

Allerdings Sie können diesen Zugriff in Systemd konfigurieren, was nicht bedeutet, dass Sie Berechtigungen für diese Laufwerke auf dieselbe Weise konfigurieren können.

Ich habe beispielsweise diese Datei erstellt:

/etc/systemd/system/[email protected]/override.conf 

Und es enthält s diese Einstellungen:

[Service] DeviceAllow=char-usb_device rwm DeviceAllow=char-usb [Files] Bind=/var/cache/apt/pkgcache.bin Bind=/var/cache/apt/srcpkgcache.bin 

Dies funktioniert immer noch nicht, wenn grub-install /dev/sda oder für einen USB on Pi, der mit Debian Stretch debootstrapped wurde. Selbst bei Verwendung von grub-uboot und grub-efi-arm gibt es immer noch diesen Fehler, dass die grub-probe den kanonischen Pfad nicht finden kann.

Nicht nur das, sondern auch, wenn update-grub die Betriebssysteme sieht und kennt, aber interessanterweise grub-install nicht erkennen, dass das Debian-Betriebssystem auf USB ist.

Beispiel

root@raspixmc:/home/pi# grub-install /dev/sda Installing for arm-uboot platform. grub-install: warning: no hints available for your platform. Expect reduced performance. grub-install: warning: WARNING: no platform-specific install was performed. Installation finished. No error reported. root@raspixmc:/home/pi# 

Interessant, wenn ich eine Chroot erstelle und update-grub ausführen kann. Obwohl ich mich auf dem Betriebssystem befinde, das ich auf den USB-Stick selbst debootstrappt habe, wird kein eigenes Betriebssystem angezeigt!

root@raspixmc:/home/pi# mount /dev/sda1 /mnt root@raspixmc:/home/pi# cd /mnt root@raspixmc:/mnt# mount --bind /dev dev/ root@raspixmc:/mnt# mount --bind /sys sys/ root@raspixmc:/mnt# mount --bind /proc proc/ root@raspixmc:/mnt# mount --bind /dev/pts dev/pts root@raspixmc:/mnt# chroot . bin/bash root@raspixmc:/# update-grub Generating grub configuration file ... Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2 done root@raspixmc:/# 

Es wird nur Raspbian angezeigt. Dies geschieht nur, wenn versucht wird, GRUB im Container zu installieren und zu aktualisieren, aber wenn ich die Chroot verlasse.

Beobachten Sie, wie es jetzt funktioniert, weil ich die Chroot-Verzeichnisse nicht ausgehängt habe:

/dev dev/ /sys sys/ /proc proc/ /dev/pts dev/pts 

Von außerhalb des Containers, wohlgemerkt, laufe ich Dieser Befehl mit grub-uboot ist auf Raspbian installiert und kein Grub auf dem USB enthält debootstrapped Debian.

root@raspixmc:/mnt# update-grub Generating grub configuration file ... Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2 Found Debian GNU/Linux 9 (stretch) on /dev/sda1 done root@raspixmc:/mnt# 

Dies ist nicht der Fall Dies geschieht mit einem der inoffiziell verfügbaren Bilder von für Debian ARM , aber offensichtlich ist dies noch eine Anpassung, die für das Debootstrapping noch nicht verfügbar ist.

Fehlerbehebung

Es gibt wirklich Zeiten, in denen es besser ist, nur einen Pfad zu erstellen. Die einzige nächste Möglichkeit (und eine wahrscheinliche) besteht darin, einfach GRUB zu schreiben. Und dafür werde ich nur auf dieser Seite lesen.

https://www.dedoimedo.com/computers/grub-2.html

Eine andere Sache, die ich zu diesem Problem mitteilen möchte, ist eine Lösung, die möglicherweise funktioniert, aber erkennt, dass microSD-Karten sehr empfindlich sind. Ich habe meine eigenen Linux-Images erstellt und dies schnell gelernt. Verwenden Sie am besten Qemu, wann immer Sie können. Um jedoch zu versuchen, eine alte Partitionstabelle zu löschen, können Sie versuchen, sgdisk --zap-all auf dem Laufwerk auszuführen.

sgdisk --zap-all /dev/sdd 

In der Tat, manchmal, wenn es beim ersten Mal einen Fehler gibt und nicht Als schreibgeschützter Fehler können Sie ihn erneut ausführen und schließlich werden alle Partitionstabellen neu oder alt.

Und Sie können Qemu verwenden, um Raspberry zu emulieren Pi auf einem Standard-AMD / Intel-basierten PC. Ich würde es empfehlen. Ich weiß, dass dies mehr Informationen sind als der ursprüngliche Beitrag, aber ich denke, dass dieser Fehler wahrscheinlich so abgeleitet wird. Es ist das Containeralter.

Basierend auf dem, was geschrieben wurde, sieht es so aus, als würden Sie versuchen, GRUB auf zu installieren / dev / sda. Sie möchten die Festplatte nicht mounten.

Sie suchen wahrscheinlich nach: grub-install /dev/sda

GRUB-Manpage Als Referenz können Sie man grub-install von Ihrem System aus verwenden: http://linux.die.net/man/8/grub-install

Kommentare

• Ich habe bereits den Befehl grub-install (auf dev.sda1) eingegeben, aber es ist ein Fehler aufgetreten, der über Blöcke spricht. Und ich habe den Fehler “ cow “ mit dem “ grub-install –recheck erhalten Befehl –root-directory = / mnt / dev / sda1 „.

Für alle, die damit zu kämpfen haben und versuchen, einen Live-USB oder andere Chroot-Methoden zum Neuinstallieren oder Installieren von Grub zu verwenden – ich habe mich einige Male damit befasst und vergessen, es vorher zu dokumentieren, obwohl ich dies beabsichtigte

Das Problem, mit dem Sie konfrontiert sind, ist, dass grub keinen Zugriff auf den Pfad hat, den Sie entweder als Quelle (/ boot) oder als Ziel bezeichnen (können Ihr System und chroot zum Beispiel?) oder beides. Wenn Sie sich auf das Chroot vorbereiten, erstellen Sie Bindungs-Mounts, auf die in der Chroot-Umgebung zugegriffen werden kann, oder Sie tun dies innerhalb der Chroot mit mount -t. Es gibt so viele Online-Anleitungen, die dies so oder so tun.

Sie müssen sicherstellen, dass Sie / dev oder nur die spezifischen Partitionen binden, die die Startdateien in / boot enthalten (z. B. / dev / sda1). . / boot ist entweder eine separate Partition oder ein Verzeichnis in / Die Chroot benötigt Zugriff auf das Laufwerk, auf dem Sie grub (neu) installieren. Führen Sie daher fdisk -l in der Chroot aus, um sicherzustellen, dass das in der Ausgabe aufgeführte Gerät angezeigt wird. Beachten Sie auch, dass Sie, wenn Sie keine separate Boot-Partition haben, aber ein Boot-Verzeichnis in / root mit den Boot-Dateien haben (nicht nur einen Mount-Punkt), nur die Partition mounten müssen, die root enthält. Sie müssen nichts an / root / boot mounten.

Sie müssen auch sicherstellen, dass Sie das proc-Dateisystem und das sys-Dateisystem binden, aber jede Anleitung, die ich gesehen habe, hat diese beiden. Ich habe sie gerade gesehen / dev hat es manchmal verpasst. Es kann Fälle geben, in denen Sie es nicht benötigen, aber ich kenne sie nicht.

tl; dr: Stellen Sie sicher, dass Sie mount / dev

Kommentare

• Warum sprechen Sie von chroot, wenn die Frage nicht ‚ t about„ ist chroot„?
• Das OP sagt „, das von einem USB mit Linux Mint “ ausgeführt wird. Das wird eine Chroot sein.