grub-probe: errore: impossibile ottenere il percorso canonico di / cow

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

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

Segui questi passaggi:

1. Avvia in una sessione Live Linux.

2. Montare la partizione / del sistema operativo installato su /mnt

   sudo mount /dev/sda6 /mnt 

3. Configura un chroot ambiente:

   sudo chroot /mnt 

4. Ora sei in uninstallazione Linux “falsa” che tratta /mnt come / . Ciò significa che tutti i file necessari per GRUB si trovano /boot dove il sistema si aspetta che siano e puoi installare GRUB proprio come se stessi eseguendo il sistema installato:

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

Ora riavvia e dovresti vedere il menu di GRUB apparire normalmente.

Commenti

• ‘ sto tentando di installare dal dispositivo USB. comunque, ho provato anche senza montare – stesso errore. puoi spiegare lerrore?
• @elyashiv, per favore modifica la tua domanda e spiega cosa stai tentando. Stai tentando di salvare un sistema danneggiato? Stai avviando un sistema live dallUSB? In tal caso, comunicacelo . Che sistema operativo stai usando? Cosa ti fa pensare che GRUB abbia unopzione root-device e cosa ti aspetti che questa opzione faccia? Hai configurato un ambiente chroot? Ogni volta che fai una domanda, devi spiegare esattamente cosa stai cercando di fare, non possiamo ‘ indovinare.
• oops, volevo dire -root -directory
• @elyashiv lì ‘ non è nemmeno --root-directory. Vai a leggere la mia risposta qui che spiega come reinstallare grub.
• guarda la prima risposta qui

Se grub dice che non può risolvere il percorso canonico di qualcosa , significa che non esiste o realpath() non riuscito.

In questo caso, prova:

$ realpath /cow $ ls -la /cow 

Se entrambi i comandi dicono “Impossibile trovare file o directory”, devi crearne uno.

Se il secondo comando funziona, ma il primo no, controlla perché realpath() non funziona. Uno dei motivi può essere che /proc non è montato. In alcune implementazioni di libc, /proc/self/fd viene utilizzato per ottenere il percorso canonico di un file.

Commenti

• Ho il primo comando funzionante, ma non il secondo.
• ME: root @ ubuntu: / # realpath / cow TERMINAL: / cow ME: # ls -la / cow TERMINAL: ls: impossibile access ‘ / cow ‘: nessun file o cartella di questo tipo (tradotto approssimativamente).

Anchio ricevo questo errore e non credo che accada in un chroot.

Background

Penso che questo sia quando systemd non riesce a trovare il percorso perché è montato in una directory. Quindi, la differenza è quando si imposta un chroot si configura già laccesso allhardware, inclusi i dischi.

Però puoi configurare questo accesso allinterno di Systemd, il che non significa che puoi configurare le autorizzazioni per quelle unità allo stesso modo.

Ad esempio, ho creato questo file:

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

E contiene s queste impostazioni:

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

Ciò ancora non funziona quando si utilizza grub-install /dev/sda o update-grub per un USB su Pi debootstrap con Debian Stretch. Anche usando grub-uboot e grub-efi-arm cè ancora quellerrore grub-probe non riesce a trovare il percorso canonico.

Non solo, ma anche se update-grub vedrà e saprà quali sono i sistemi operativi, ma è interessante notare che grub-install non lo fa riconoscere che il sistema operativo Debian è su USB.

Esempio

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# 

Interessante, quando creo un chroot e posso eseguire update-grub, anche se sono sul sistema operativo che ho debootstrap sulla USB stessa, non vede il proprio sistema operativo!

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 solo Raspbian. Ciò accade solo quando provo a installare e aggiornare GRUB allinterno del contenitore, ma quando esco dal chroot.

Guarda come funziona ora perché non ho smontato le directory chroot:

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

Dallesterno del contenitore, attenzione, sto correndo questo comando con grub-uboot installato su Raspbian e senza Grub sullUSB contenente Debian debootstrappato.

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# 

Questo non funziona accade usando una delle immagini non ufficialmente disponibili per Debian ARM , ma ovviamente questa è ancora una personalizzazione non ancora disponibile per il debootstrapping.

Risoluzione dei problemi

In realtà ci sono momenti in cui è meglio creare solo un percorso. Lunica prossima possibilità (e probabile) è scrivere semplicemente GRUB. E per questo leggerò solo su questa pagina.

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

Unaltra cosa che voglio condividere su questo problema è una soluzione che potrebbe funzionare, ma rendersi conto che le schede microSD sono molto sensibili. Ho creato le mie immagini Linux e lho imparato velocemente. La cosa migliore da fare è usare Qemu ogni volta che puoi, ma per tentare di cancellare una vecchia tabella delle partizioni potresti provare a eseguire sgdisk --zap-all sullunità.

sgdisk --zap-all /dev/sdd 

In effetti, a volte se restituisce un errore la prima volta ed è non un errore di sola lettura, puoi eseguirlo di nuovo e finalmente tutte le tabelle delle partizioni saranno nuove o vecchie.

E puoi usare Qemu per emulare Raspberry Pi su un PC standard AMD / Intel. Lo consiglierei. So che si tratta di più informazioni rispetto a quelle del post originale, ma penso che sia probabile che sia derivato questo errore. È letà del contenitore.

In base a ciò che è stato scritto, sembra che tu “stia cercando di installare GRUB in / dev / sda. Non vuoi montare il disco.

Probabilmente stai cercando: grub-install /dev/sda

pagina man di GRUB per riferimento oppure puoi man grub-install dal tuo sistema: http://linux.die.net/man/8/grub-install

Commenti

• Ho già digitato il comando grub-install (su dev.sda1), ma ho avuto un errore parlando di blocchi. E ho ricevuto lerrore ” cow ” con ” grub-install –recheck –root-directory = / mnt / dev / sda1 ” comando.

Per chiunque abbia problemi con questo che sta tentando di utilizzare una USB live o altri mezzi di chroot per reinstallare o installare grub – Ho affrontato questo un paio di volte e mi sono dimenticato di documentarlo prima sebbene intendessi farlo .

Il problema che devi affrontare è che grub non ha accesso al percorso a cui ti riferisci come sorgente (/ boot) o destinazione (il tuo sistema e chroot possono vedere /dev/sda per esempio?) o entrambi. Quando ti prepari a chroot, crei bind mount accessibili nellambiente chroot, o lo fai allinterno del chroot usando mount -t. Ci sono così tante guide online che lo fanno in entrambi i casi.

Devi assicurarti di associare / dev o solo le partizioni specifiche contenenti i file di avvio in / boot (ad esempio / dev / sda1) . / boot è una partizione separata o una directory in / Il chroot ha bisogno di accedere allunità su cui (re) installerai grub, quindi fai fdisk -l nel chroot per assicurarti di poter vedere il dispositivo elencato nelloutput. Nota inoltre, se non hai una partizione di avvio separata, ma hai una directory di avvio in / root con i file di avvio (non solo un punto di montaggio), allora devi solo montare la partizione contenente root. non devo montare nulla su / root / boot.

Devi anche assicurarti di collegare il file system proc e il file system sys, ma ogni guida che ho visto ha questi due. Ho appena visto / dev a volte mancava. Potrebbero esserci dei casi in cui non ne hai bisogno, ma non li conosco.

tl; dr: assicurati di collegare mount / dev

Commenti

• Perché parli di chroot quando la domanda non è ‘ su ” chroot ?
• LOP dice ” in esecuzione da una USB contenente linux mint “. Quello sarà un chroot.