grub-probe: error: no se pudo obtener la ruta canónica de / cow

Estoy tratando de reinstalar grub desde una unidad USB. Ejecuto lo siguiente:

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

Obtuve el siguiente error:

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

¿Alguien puede explicar el error y cómo resolverlo?

Editar

Estoy tratando de reparar un sistema de arranque dual roto, que se ejecuta desde un USB que contiene Linux mint.

Sigue estos pasos:

1. Arrancar en una sesión de Live Linux.

2. Monte la /partición de su sistema operativo instalado en/mnt

   sudo mount /dev/sda6 /mnt
   

3. Configurar un chrootentorno:

   sudo chroot /mnt
   

4. Ahora está en una instalación de Linux "falsa" que se trata /mntcomo /. Esto significa que todos los archivos necesarios para GRUB se encuentran /bootdonde el sistema espera que estén y puede instalar GRUB como si realmente estuviera ejecutando su sistema instalado:

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

Ahora reinicie y debería ver que el menú GRUB aparece normalmente.

Si grub dice que no pudo resolver la ruta canónica de algo, significa que no existe o realpath()falló.

En este caso, intente:

$ realpath /cow
$ ls -la /cow

Si ambos comandos dicen "no se puede encontrar el archivo o directorio", debe crear uno.

Si el segundo comando funciona, pero el primero no, verifique por qué realpath()no funciona. Una de las razones puede ser que /procno está montado. En algunas implementaciones de libc, /proc/self/fdse usa para obtener la ruta canónica de un archivo.

Según lo escrito, parece que está intentando instalar GRUB en / dev / sda. No desea montar el disco.

Probablemente estés buscando: grub-install /dev/sda

Página de manual de GRUB para referencia, o puede man grub-installdesde su sistema: http://linux.die.net/man/8/grub-install

También recibo este error, y no creo que ocurra en un chroot.

Antecedentes

Creo que esto es cuando systemd no puede encontrar la ruta porque está montada en un directorio. Entonces, la diferencia es que cuando configura un chroot, ya configura el acceso al hardware, incluidas las unidades.

Aunque puede configurar este acceso dentro de Systemd, eso no significa que pueda configurar los permisos para esas unidades de la misma manera.

Por ejemplo, creé este archivo:

/etc/systemd/system/systemd-nspawn@.service.d/override.conf

Y contiene esta configuración:

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

Esto todavía no funciona cuando se usa grub-install /dev/sdao update-grubpara un USB en Pi debootstrapped con Debian Stretch. Incluso usando grub-uboot y grub-efi-arm todavía existe ese error que grub-probeno puede encontrar la ruta canónica.

No solo eso, sino update-grubque verá y sabrá cuáles son los sistemas operativos, pero curiosamente grub-installno reconoce que el sistema operativo Debian está en USB.

Ejemplo

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#

Interesante, cuando creo un chroot y puedo ejecutar update-grub, a pesar de que estoy en el sistema operativo que no tengo en el USB, ¡no ve su propio 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:/#

Solo ve a Raspbian. Esto sucede solo cuando intento instalar y actualizar GRUB dentro del contenedor, pero cuando salgo del chroot.

Mira cómo funciona ahora porque no desmonté los directorios chroot:

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

Desde fuera del contenedor, tenga en cuenta que estoy ejecutando este comando con grub-ubootinstalado en Raspbian y sin Grub en el USB que contiene Debian atrapado.

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#

Esto no sucede usando una de las imágenes disponibles no oficialmente para Debian ARM , pero obviamente todavía es una personalización que aún no está disponible para debootstrapping.

Solución de problemas

Realmente hay momentos en que es mejor crear un camino. La única posibilidad siguiente (y probable) es simplemente escribir GRUB. Y para eso solo voy a leer en esta página.

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

Otra cosa que quiero compartir sobre este problema es una solución que podría funcionar, pero que las tarjetas microSD son muy sensibles. He estado construyendo mis propias imágenes de Linux y aprendí esto rápido. Lo mejor que puede hacer es usar Qemu siempre que pueda, pero para intentar borrar una tabla de partición antigua, puede intentar ejecutarla sgdisk --zap-allen la unidad.

sgdisk --zap-all /dev/sdd

De hecho, a veces, si se da un error la primera vez y es no un error de sólo lectura, puede ejecutar de nuevo y finalmente todas las tablas de partición nuevo o viejo.

Y puede usar Qemu para emular Raspberry Pi en una PC estándar basada en AMD / Intel. Yo lo recomendaría. Sé que esta es más información que la publicación original, pero creo que es probable que este error se derive. Es la edad del contenedor.

Para cualquiera que esté luchando con esto y esté intentando usar un USB en vivo u otro medio de chroot para reinstalar o instalar grub, lo he tratado varias veces y olvidé documentarlo antes, aunque tenía la intención.

El problema que enfrenta es que grub no tiene acceso a la ruta a la que se refiere, ya sea como el origen (/ inicio) o el destino (¿pueden ver su sistema y chroot, /dev/sdapor ejemplo?) O ambos. Cuando se prepara para chroot, crea montajes de enlace que son accesibles en el entorno chroot, o lo hace dentro del chroot usando mount -t. Hay tantas guías en línea que lo hacen de cualquier manera.

Debe asegurarse de vincular / dev o solo las particiones específicas que contienen los archivos de inicio en / boot (por ejemplo, / dev / sda1). / boot es una partición separada o un directorio en / El chroot necesita acceso a la unidad en la que (re) instalará grub para que lo haga fdisk -l en el chroot para asegurarse de que pueda ver el dispositivo en la salida. También tenga en cuenta que si no tiene una partición de arranque separada, pero sí tiene un directorio de arranque en / root con los archivos de arranque (no solo un punto de montaje), entonces solo tiene que montar la partición que contiene la raíz. Entonces no tiene que montar nada en / root / boot.

También debe asegurarse de vincular el sistema de archivos proc y el sistema de archivos sys, pero cada guía que he visto tiene esos dos. Acabo de ver / dev perdido a veces. Puede haber algunos casos en los que no lo necesite, pero no los conozco.

tl; dr: asegúrate de vincular mount / dev