grub-probe: error: misslyckades med att få kanonisk sökväg till / cow

sudo mount /dev/sda6 /mnt sudo grub-install --root-directory=/mnt /dev/sda 

grub-probe: error: failed to get canonical path of /cow. 

Följ dessa steg:

1. Starta upp i en Live Linux-session.

2. Montera / -partitionen på ditt installerade operativsystem till /mnt

   sudo mount /dev/sda6 /mnt 

3. Ställ in en chroot -miljö:

   sudo chroot /mnt 

4. Du befinner dig nu i en ”falsk” Linux-installation som behandlar /mnt som / . Det betyder att alla filer som är nödvändiga för GRUB finns i /boot där systemet förväntar sig att de ska vara och du kan installera GRUB precis som om du faktiskt körde ditt installerade system:

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

Starta om och du ska se att GRUB-menyn visas normalt.

Kommentarer

• Jag ’ jag försöker installera från USB-enheten. på något sätt försökte jag också utan montering – samma fel. kan du förklara felet?
• @elyashiv snälla redigera din fråga och förklara vad du försöker. Försöker du rädda ett trasigt system? Startar du ett live-system från USB? I så fall berätta för oss . Vilket operativsystem använder du? Vad får dig att tro att GRUB har ett root-device -alternativ och vad förväntar du dig att alternativet ska göra? Har du skapat en chroot -miljö? När du ställer en fråga måste du förklara exakt vad du försöker göra, vi kan ’ gissa.
• oops, jag menade -root -katalog
• @elyashiv där ’ s inte --root-directory heller. Läs mitt svar här som förklarar hur du installerar om grub.
• titta på det första svaret här

Om grub säger att det inte kunde lösa kanonisk väg för något betyder det att den inte finns eller realpath() misslyckades.

I det här fallet, försök:

$ realpath /cow $ ls -la /cow 

Om båda kommandona säger ”kan inte hitta fil eller katalog” måste du skapa en.

Om det andra kommandot fungerar, men det första inte, kontrollera varför realpath() fungerar inte. En av anledningarna kan vara att /proc inte är monterad. I vissa implementeringar av libc används /proc/self/fd för att få en kanonisk sökväg till en fil.

Kommentarer

• Jag har det första kommandot som fungerar, men inte det andra.
• ME: root @ ubuntu: / # realpath / cow TERMINAL: / cow ME: # ls -la / cow TERMINAL: ls: omöjligt att åtkomst ’ / ko ’: Ingen fil eller mapp av detta slag (grovt översatt).

Jag får också det här felet och jag tror inte att det händer i en chroot.

Bakgrund

Jag tror att det här är när systemd inte hittar sökvägen eftersom den är monterad i en katalog. Så skillnaden är när du ställer in en chroot du redan konfigurerar åtkomst till hårdvara, inklusive enheter.

Även du kan konfigurera den här åtkomsten inuti Systemd som inte betyder att du kan konfigurera behörigheter för dessa enheter på samma sätt.

Till exempel skapade jag den här filen:

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

Och den innehåller s dessa inställningar:

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

Detta fungerar fortfarande inte när du använder grub-install /dev/sda eller update-grub för en USB på Pi debootstrapped med Debian Stretch. Även med hjälp av grub-uboot och grub-efi-arm finns det fortfarande det felet grub-probe kan inte hitta den kanoniska vägen.

Inte bara det men även om update-grub kommer att se och veta vad operativsystem är, men intressant grub-install inte känna igen att Debian-operativsystemet är på USB.

Exempel

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# 

Intressant när jag skapar en chroot och kan köra update-grub, även om jag är på det operativsystem som jag debootstrapped till USB själv ser det inte sitt eget operativsystem!

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

Det ser bara Raspbian. Detta händer bara när du försöker installera och uppdatera GRUB inuti behållaren, men när jag lämnar chroot.

Se hur det nu fungerar eftersom jag inte avmonterade chroot-katalogerna:

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

Utanför behållaren kom ihåg, jag kör det här kommandot med grub-uboot installerat på Raspbian och ingen Grub på USB-enheten som innehåller Debootstrastrapped 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# 

Detta fungerar inte hända med en av inofficiellt tillgängliga bilder för Debian ARM , men det är uppenbarligen fortfarande en anpassning som ännu inte är tillgänglig för debootstrapping.

Felsökning

Det finns verkligen tider när det är bättre att bara skapa en sökväg. Den enda nästa möjligheten (och en sannolik) är att helt enkelt skriva GRUB. Och för det ska jag bara läsa på den här sidan.

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

En annan sak som jag vill dela med mig av den här frågan är en lösning som kan fungera, men inser att microSD-kort är mycket känsliga. Jag har byggt mina egna Linux-bilder och lärt mig detta snabbt. Det bästa du kan göra är att använda Qemu när du kan, men för att försöka rensa en gammal partitionstabell kan du försöka köra sgdisk --zap-all på enheten.

sgdisk --zap-all /dev/sdd 

Faktiskt, ibland om det ger ett fel första gången och det är inte ett skrivskyddat fel, du kan köra det igen och slutligen kommer alla partitionstabellerna att vara nya eller gamla.

Och du kan använda Qemu för att emulera hallon Pi på en vanlig AMD / Intel-baserad dator. Jag skulle rekommendera det. Jag vet att detta är mer information än det ursprungliga inlägget, men jag tror att det är troligt hur detta fel härrör. Det är containeråldern.

Baserat på vad som skrevs, ser det ut som om du försöker installera GRUB till / dev / sda. Du vill inte montera skivan.

Du letar troligen efter: grub-install /dev/sda

GRUB mansida som referens, eller så kan du man grub-install från ditt system: http://linux.die.net/man/8/grub-install

Kommentarer

• Jag skrev redan kommandot grub-install (på dev.sda1), men jag hade ett fel när jag talade om block. Och jag fick ” ko ” fel med ” grub-install –recheck –root-directory = / mnt / dev / sda1 ” kommando.