Sto cercando di reinstallare grub da un'unità USB. Corro il seguente:
sudo mount /dev/sda6 /mnt
sudo grub-install --root-directory=/mnt /dev/sda
Ottengo il seguente errore:
grub-probe: error: failed to get canonical path of /cow.
qualcuno può spiegare l'errore e come risolverlo?
modificare
Sto cercando di riparare un sistema a doppio avvio rotto, in esecuzione da una USB contenente Linux Mint.
Risposte:
Segui questi passi:
Avvia in una sessione Live Linux.
Montare la /partizione del sistema operativo installato su/mnt
sudo mount /dev/sda6 /mnt
Imposta un chrootambiente:
sudo chroot /mnt
Ora sei in un'installazione "falsa" di Linux che tratta /mntcome /. Ciò significa che tutti i file necessari per GRUB si trovano nel /bootpunto in cui il sistema si aspetta che si trovino e puoi installare GRUB come se stessi effettivamente eseguendo il sistema installato:
sudo update-grub
sudo grub-install /dev/sda
Ora riavvia e dovresti vedere il menu di GRUB apparire normalmente.
root-deviceun'opzione e cosa ti aspetti che faccia? Hai creato un chrootambiente? Ogni volta che fai una domanda, devi spiegare esattamente cosa stai cercando di fare, non possiamo indovinare.
Se grub dice che non può risolvere il percorso canonico di qualcosa, significa che non esiste o realpath()fallito.
In questo caso, prova:
$ realpath /cow
$ ls -la /cow
Se entrambi i comandi dicono "Impossibile trovare il file o la directory", è necessario crearne uno.
Se il secondo comando funziona, ma il primo non funziona, controllare perché realpath()non funziona. Uno dei motivi può essere che /procnon è montato. In alcune implementazioni di libc, /proc/self/fdviene utilizzato per ottenere il percorso canonico di un file.
Sulla base di ciò che è stato scritto, sembra che tu stia cercando di installare GRUB su / dev / sda. Non si desidera montare il disco.
Probabilmente stai cercando:
grub-install /dev/sda
Pagina man di GRUB per riferimento, oppure puoi man grub-installdal tuo sistema:
http://linux.die.net/man/8/grub-install
Ricevo anche questo errore e non penso che accada in un chroot.
Penso che sia quando systemd non riesce a trovare il percorso perché è montato in una directory. Quindi, la differenza è quando si configura un chroot che si configura già l'accesso all'hardware, comprese le unità.
Sebbene sia possibile configurare questo accesso all'interno di Systemd ciò non significa che è possibile configurare le autorizzazioni per tali unità allo stesso modo.
Ad esempio, ho creato questo file:
/etc/systemd/system/systemd-nspawn@.service.d/override.conf
E contiene queste impostazioni:
[Service]
DeviceAllow=char-usb_device rwm
DeviceAllow=char-usb
[Files]
Bind=/var/cache/apt/pkgcache.bin
Bind=/var/cache/apt/srcpkgcache.bin
Questo non funziona ancora quando si usa grub-install /dev/sdao update-grubper un USB su Pi debootstrapped con Debian Stretch. Anche usando grub-uboot e grub-efi-arm c'è ancora quell'errore che grub-probenon riesce a trovare il percorso canonico.
Non solo, ma update-grubvedrà e saprà quali sono i sistemi operativi, ma interessante grub-installnon riconosce il sistema operativo Debian su USB.
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 eseguirlo update-grub, anche se sono sul sistema operativo che ho debootstrapped sull'USB stesso, non vede il suo 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. Questo accade solo quando si tenta di installare e aggiornare GRUB all'interno 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
Dall'esterno del contenitore, attenzione, sto eseguendo questo comando con grub-ubootinstallato su Raspbian e senza Grub su USB contenente Debian debootstrapped.
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 accade usando una delle immagini non ufficiali disponibili per Debian ARM , ma ovviamente questa è ancora una personalizzazione non ancora disponibile per il debootstrapping.
Davvero ci sono momenti in cui è meglio solo creare un percorso. L'unica possibilità successiva (e una probabile) è semplicemente scrivere GRUB. E per questo ho intenzione di leggere in questa pagina.
https://www.dedoimedo.com/computers/grub-2.html
Un'altra cosa che voglio condividere su questo problema è una soluzione che potrebbe funzionare, ma realizzare che le schede microSD sono molto sensibili. Ho creato le mie immagini Linux e l'ho 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 correre sgdisk --zap-allsull'unità.
sgdisk --zap-all /dev/sdd
In realtà, a volte se si dà un errore la prima volta ed è non è un errore di sola lettura, è possibile eseguire di nuovo e lo farà, infine, tutte le tabelle di partizione nuova o vecchia.
E puoi usare Qemu per emulare Raspberry Pi su un PC standard basato su AMD / Intel. Lo consiglierei So che si tratta di più informazioni di quelle relative al post originale, ma penso che sia probabile come questo errore sia derivato. È l'età del contenitore.
Per chiunque abbia problemi con questo, che sta tentando di utilizzare una chiavetta USB o altri mezzi di chroot per reinstallare o installare grub, l'ho affrontato alcune volte e ho dimenticato di documentarlo prima, anche se avevo intenzione di farlo.
Il problema che affronti è che grub non ha accesso al percorso a cui ti riferisci come sorgente (/ boot) o destinazione (il tuo sistema e chroot possono vedere /dev/sdaper esempio?) O entrambi. Quando ti prepari a chroot crei mount di bind accessibili nell'ambiente chroot, oppure lo fai all'interno di chroot usando mount -t. Ci sono così tante guide online che lo fanno in entrambi i modi.
Devi assicurarti di associare / dev o solo le partizioni specifiche che contengono i file di avvio in / boot (es. / Dev / sda1). / boot è una partizione separata o una directory in / Il chroot ha bisogno di accedere all'unità che (ri) installerai grub per fare così fdisk -l nel chroot per assicurarti di poter vedere il dispositivo elencato nell'output. Inoltre, se non si dispone di una partizione di avvio separata, ma si dispone di una directory di avvio in / root con i file di avvio (non solo un punto di montaggio), è necessario montare solo la partizione contenente root. Quindi non devi montare nulla su / root / boot.
Devi anche assicurarti di associare il file system proc e il file system sys, ma ogni guida che ho visto ha quei due. Ho appena visto / dev perso a volte. Potrebbero esserci dei casi in cui non ne hai bisogno, ma io non li conosco.
tl; dr: assicurati di associare mount / dev
chrootquando la domanda non riguarda `` chroot``?
sda6? La mia risposta qui aiuta?