grub-probe: error: kunne ikke få kanonisk bane til / 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ølg disse trinnene:

1. Start opp i en Live Linux-økt.

2. Monter / partisjonen til ditt installerte operativsystem til /mnt

   sudo mount /dev/sda6 /mnt 

3. Sett opp et chroot miljø:

   sudo chroot /mnt 

4. Du er nå i en «falsk» Linux-installasjon som behandler /mnt som / . Dette betyr at alle filene som er nødvendige for GRUB er i /boot der systemet forventer at de skal være, og du kan installere GRUB akkurat som om du faktisk kjørte det installerte systemet:

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

Start på nytt, og du ser GRUB-menyen vises normalt.

Kommentarer

• Jeg ‘ prøver å installere fra USB-enheten. på noen måte prøvde jeg også uten montering – samme feil. kan du forklare feilen?
• @elyashiv vennligst rediger spørsmålet ditt og forklar hva det er du prøver på. Prøver du å redde et ødelagt system? Starter du et live system fra USB? I så fall fortell oss . Hvilket operativsystem bruker du? Hva får deg til å tro at GRUB har et root-device -alternativ, og hva forventer du at alternativet skal gjøre? Har du satt opp et chroot miljø? Når du stiller et spørsmål, må du forklare nøyaktig hva du prøver å gjøre, vi kan ‘ ikke gjette.
• ups, jeg mente -root -katalog
• @elyashiv der ‘ s ikke --root-directory heller. Les svaret mitt her som forklarer hvordan du installerer grub på nytt.
• se på det første svaret her

Hvis grub sier at det ikke kan løse den kanoniske banen til noe , betyr det at den ikke eksisterer eller realpath() mislyktes.

I dette tilfellet kan du prøve:

$ realpath /cow $ ls -la /cow 

Hvis begge kommandoene sier «finner ikke fil eller katalog», må du opprette en.

Hvis den andre kommandoen fungerer, men den første ikke, må du sjekke hvorfor realpath() fungerer ikke. En av årsakene kan være at /proc ikke er montert. I noen implementeringer av libc brukes /proc/self/fd for å få en kanonisk bane til en fil.

Kommentarer

• Jeg har den første kommandoen som fungerer, men ikke den andre.
• ME: root @ ubuntu: / # realpath / cow TERMINAL: / cow ME: # ls -la / cow TERMINAL: ls: umulig å tilgang ‘ / cow ‘: Ingen fil eller mappe av denne typen (grovt oversatt).

Jeg får også denne feilen, og jeg tror ikke det skjer i en chroot.

Bakgrunn

Jeg tror dette er når systemd ikke finner stien fordi den er montert i en katalog. Så forskjellen er når du konfigurerer en chroot du allerede konfigurerer tilgang til maskinvare, inkludert stasjoner.

Skjønt du kan konfigurere denne tilgangen i Systemd som ikke betyr at du kan konfigurere tillatelser for disse stasjonene på samme måte.

For eksempel opprettet jeg denne filen:

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

Og den inneholder er disse innstillingene:

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

Dette fungerer fortsatt ikke når du bruker grub-install /dev/sda eller update-grub for en USB på Pi debootstrapped med Debian Stretch. Selv ved bruk av grub-uboot og grub-efi-arm er det fortsatt den feilen grub-probe finner ikke den kanoniske banen.

Ikke bare det, men skjønt update-grub vil se og vite hva operativsystemene er, men det er interessant at grub-install ikke gjenkjenne at Debian-operativsystemet er på USB.

Eksempel

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 når jeg oppretter en chroot og kan kjøre update-grub, selv om jeg er på operativsystemet som jeg debootstrapped til selve USB-en, ser den ikke 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:/# 

Den ser bare Raspbian. Dette skjer bare når du prøver å installere og oppdatere GRUB inne i beholderen, men når jeg avslutter chroot.

Se hvordan det nå fungerer fordi jeg ikke demonterte chroot-katalogene:

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

Utenom beholderen, husk at jeg løper denne kommandoen med grub-uboot installert på Raspbian og ingen Grub på USB-en som inneholder 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# 

Dette betyr ikke skje ved å bruke et av uoffisielt tilgjengelige bilder for Debian ARM , men dette er selvsagt fortsatt en tilpasning som ennå ikke er tilgjengelig for debootstrapping.

Feilsøking

Det er virkelig tider når det er bedre å lage en bane. Den eneste neste muligheten (og en sannsynlig) er å bare skrive GRUB. Og for det skal jeg bare lese på denne siden.

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

En annen ting jeg vil dele om dette problemet er en løsning som kan fungere, men innser at microSD-kort er veldig følsomme. Jeg har bygget mine egne Linux-bilder og lært dette raskt. Det beste du kan gjøre er å bruke Qemu når du kan, men for å prøve å rydde en gammel partisjonstabell kan du prøve å kjøre sgdisk --zap-all på stasjonen.

sgdisk --zap-all /dev/sdd 

Faktisk, noen ganger hvis det gir en feil første gang og det er ikke en skrivebeskyttet feil, du kan kjøre den igjen, og til slutt vil alle partisjonstabellene være nye eller gamle.

Og du kan bruke Qemu til å etterligne bringebær Pi på en standard AMD / Intel-basert PC. Jeg vil anbefale det. Jeg vet at dette er mer informasjon enn det opprinnelige innlegget, men jeg tror det er sannsynlig hvordan denne feilen er avledet. Det er containeralderen.

Basert på det som ble skrevet, ser det ut til at du prøver å installere GRUB til / dev / sda. Du vil ikke montere disken.

Du leter sannsynligvis etter: grub-install /dev/sda

GRUB man-side som referanse, eller du kan man grub-install fra systemet ditt: http://linux.die.net/man/8/grub-install

Kommentarer

• Jeg skrev allerede kommandoen grub-install (på dev.sda1), men jeg hadde en feil med å snakke om blokker. Og jeg fikk » ku » feil med » grub-install –recheck –root-directory = / mnt / dev / sda1 » kommando.