grub-probe: eroare: nu am reușit să obțin calea canonică a / cow

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

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

Urmați acești pași:

1. Porniți într-o sesiune Live Linux.

2. Montați / partiția sistemului de operare instalat pe /mnt

   sudo mount /dev/sda6 /mnt 

3. Configurați un mediu chroot:

   sudo chroot /mnt 

4. Acum vă aflați într-o instalare Linux „falsă” care tratează /mnt ca / . Aceasta înseamnă că toate fișierele necesare pentru GRUB se află în /boot unde sistemul se așteaptă să fie și puteți instala GRUB la fel ca și cum ați rula sistemul instalat:

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

Acum reporniți și ar trebui să vedeți că meniul GRUB apare normal.

Comentarii

• ‘ încerc să instalez de la dispozitivul USB. oricum, am încercat și fără montare – aceeași eroare. puteți explica eroarea?
• @elyashiv vă rugăm să editați întrebarea și să explicați ce încercați. Încercați să salvați un sistem defect? Pornești un sistem live de pe USB? Dacă da, spune-ne . Ce sistem de operare folosiți? Ce vă face să credeți că GRUB are o opțiune root-device și ce vă așteptați să facă această opțiune? Ați configurat un mediu chroot? Ori de câte ori puneți o întrebare, trebuie să explicați exact ce t încercați să faceți, nu putem ‘ să ghicim.
• hopa, am vrut să spun -root -directoriu
• @elyashiv nu există nici ‘ nici --root-directory. Citiți răspunsul meu aici care explică cum să reinstalați grub.
• uitați-vă la primul răspuns aici

Dacă grub spune că nu a putut rezolva calea canonică a ceva , înseamnă că nu există sau realpath() a eșuat.

În acest caz, încercați:

$ realpath /cow $ ls -la /cow 

Dacă ambele comenzi spun „nu se poate găsi fișierul sau directorul”, atunci trebuie să creați unul.

Dacă a doua comandă funcționează, dar prima nu, verificați de ce realpath() nu funcționează. Unul dintre motive poate fi că /proc nu este montat. În unele implementări ale libc, /proc/self/fd este utilizat pentru a obține calea canonică a unui fișier.

Comentarii

• Am prima comandă funcțională, dar nu a doua.
• ME: root @ ubuntu: / # realpath / cow TERMINAL: / cow ME: # ls -la / cow TERMINAL: ls: imposibil de access ‘ / cow ‘: Niciun fișier sau folder de acest tip (tradus aproximativ).

Am primit și această eroare și nu cred că se întâmplă într-un chroot.

Fundal

Cred că atunci când systemd nu poate găsi calea, deoarece este montat într-un director. Deci, diferența este că atunci când configurați un chroot, configurați deja accesul la hardware, inclusiv unitățile.

Deși puteți configura acest acces în Systemd, ceea ce nu înseamnă că puteți configura permisiunile pentru acele unități în același mod.

De exemplu, am creat acest fișier:

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

Și conține aceste setări:

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

Acest lucru nu funcționează încă atunci când se utilizează grub-install /dev/sda sau update-grub pentru un USB pe Pi debootstrapped cu Debian Stretch. Chiar și folosind grub-uboot și grub-efi-arm, există încă această eroare grub-probe nu poate găsi calea canonică.

Nu numai asta, dar deși update-grub va vedea și va ști care sunt sistemele de operare, dar interesant grub-install nu recunoașteți că sistemul de operare Debian este pe USB.

Exemplu

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# 

Interesant, când creez un chroot și pot rula update-grub, chiar dacă sunt pe sistemul de operare pe care l-am debootat pe USB în sine, acesta nu vede propriul său sistem de operare!

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

Vede doar Raspbian. Acest lucru se întâmplă numai atunci când încerc să instalez și să actualizez GRUB în interiorul containerului, dar când ies din chroot.

Urmăriți cum funcționează acum, deoarece nu am demontat directoarele chroot:

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

Din afara containerului, vă alerg această comandă cu grub-uboot instalată pe Raspbian și fără Grub pe USB care conține Debian 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# 

Acest lucru nu este se întâmplă folosind una dintre imagini disponibile neoficial pentru Debian ARM , dar evident că aceasta este încă o personalizare care nu este încă disponibilă pentru debootstrapping.

Depanare

Într-adevăr, există momente când este mai bine să creați o cale. Singura posibilitate următoare (și una probabilă) este de a scrie pur și simplu GRUB. Și pentru asta voi citi doar pe această pagină.

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

Un alt lucru pe care vreau să-l împărtășesc despre această problemă este o soluție care ar putea funcționa, dar realizăm că cardurile microSD sunt foarte sensibile. Mi-am construit propriile imagini Linux și am învățat atât de repede. Cel mai bun lucru de făcut este să folosiți Qemu ori de câte ori puteți, dar pentru a încerca să ștergeți o tabelă de partiții veche, puteți încerca să rulați sgdisk --zap-all pe unitate.

sgdisk --zap-all /dev/sdd 

De fapt, uneori, dacă dă o eroare prima dată și nu o eroare de numai citire, o puteți rula din nou și va finaliza toate tabelele de partiții noi sau vechi.

Și puteți utiliza Qemu pentru a emula Raspberry Pi pe un computer standard AMD / Intel. L-aș recomanda. Știu că acestea sunt mai multe informații decât se referă la postarea originală, dar cred că este probabil modul în care se derivă această eroare. Este vârsta containerului.

Pe baza celor scrise, se pare că încercați să instalați GRUB în / dev / sda. Nu doriți să montați discul.

Probabil căutați: grub-install /dev/sda

pagina manuală GRUB pentru referință, sau puteți man grub-install din sistemul dvs.: http://linux.die.net/man/8/grub-install

Comentarii

• Am tastat deja comanda grub-install (pe dev.sda1), dar am avut o eroare vorbind despre blocuri. Și am primit ” vaca ” cu ” grub-install –recheck –root-directory = / mnt / dev / sda1 ” comanda.

Pentru oricine se luptă cu acest lucru, care încearcă să utilizeze un USB live sau alte mijloace de chroot pentru a reinstala sau instala grub – m-am ocupat de câteva ori și am uitat să îl documentez înainte, deși intenționam să .

Problema cu care te confrunți este că grub nu are acces la calea la care te referi fie ca sursă (/ boot), fie ca destinație (sistemul și chroot-ul tău pot vedea /dev/sda de exemplu?) sau ambele. Când vă pregătiți pentru chroot, creați monturi de legare care sunt accesibile în mediul chroot sau faceți acest lucru în chroot folosind mount -t. Există atât de multe ghiduri online care o fac oricum.

Trebuie să vă asigurați că legați / dev sau doar partițiile specifice care conțin fișierele de boot din / boot (de exemplu / dev / sda1) . / boot este fie o partiție separată, fie un director în / Chroot are nevoie de acces la unitatea pe care o veți (re) instala grub pentru a face fdisk -l în chroot pentru a vă asigura că puteți vedea dispozitivul listat în ieșire. De asemenea, rețineți, dacă nu aveți o partiție de boot separată, dar aveți un director de boot în / root cu fișierele de boot (nu doar un punct de montare), atunci trebuie doar să montați partiția care conține rădăcină. Nu trebuie să montezi nimic la / root / boot.

De asemenea, trebuie să te asiguri că legi sistemul de fișiere proc și sistemul de fișiere sys, dar fiecare ghid pe care l-am văzut are acelea două. Tocmai am văzut / dev a ratat uneori. S-ar putea să apară unele cazuri când nu aveți nevoie, dar nu știu de ele.

tl; dr: asigurați-vă că legați mount / dev

Comentarii

• De ce vorbiți despre chroot când întrebarea nu este ‘ despre ” chroot„?
• OP spune ” care rulează de pe un USB care conține linux mint „. Acesta va fi un chroot.