grub-probe: error: falha ao obter o caminho canônico de / cow

Estou tentando reinstalar o grub a partir de uma unidade USB. Eu executo o seguinte:

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

Estou tendo o erro a seguir:

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

alguém pode explicar o erro e como resolvê-lo?

Editar

Estou tentando reparar um sistema de inicialização dupla quebrado, executando a partir de um USB contendo linux mint.

Siga esses passos:

1. Inicialize em uma sessão do Live Linux.

2. Monte a /partição do seu sistema operacional instalado para/mnt

   sudo mount /dev/sda6 /mnt
   

3. Configure um chrootambiente:

   sudo chroot /mnt
   

4. Agora você está em uma instalação "falsa" do Linux que trata /mntcomo /. Isso significa que todos os arquivos necessários para o GRUB estão /bootonde o sistema espera que estejam e você pode instalar o GRUB como se estivesse realmente executando o sistema instalado:

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

Agora reinicie e você verá o menu GRUB aparecer normalmente.

Se o grub disser que não foi possível resolver o caminho canônico de algo, isso significa que ele não existe ou realpath()falhou.

Nesse caso, tente:

$ realpath /cow
$ ls -la /cow

Se os dois comandos disserem "não é possível encontrar o arquivo ou diretório", você deverá criar um.

Se o segundo comando funcionar, mas o primeiro não, verifique por realpath()que não funciona. Pode ser que um dos motivos /procnão esteja montado. Em algumas implementações da libc, /proc/self/fdé usado para obter o caminho canônico de um arquivo.

Com base no que foi escrito, parece que você está tentando instalar o GRUB no / dev / sda. Você não deseja montar o disco.

Você provavelmente está procurando: grub-install /dev/sda

Página de manual do GRUB para referência, ou você pode, man grub-installno seu sistema: http://linux.die.net/man/8/grub-install

Também recebo esse erro e não acho que isso aconteça em um chroot.

fundo

Eu acho que é quando o systemd não consegue encontrar o caminho porque está montado em um diretório. Portanto, a diferença é que, quando você configura um chroot, já configura o acesso ao hardware, incluindo unidades.

Embora você possa configurar esse acesso no Systemd, isso não significa que você possa configurar as permissões para essas unidades da mesma maneira.

Por exemplo, eu criei este arquivo:

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

E contém estas configurações:

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

Isso ainda não funciona quando se usa grub-install /dev/sdaou update-grubpara um USB no Pi desinicializado com o Debian Stretch. Mesmo usando grub-uboot e grub-efi-arm, ainda existe o erro degrub-probe não pode encontrar o caminho canônico.

Não apenas isso, mas update-grubtambém verá e saberá quais são os sistemas operacionais, mas de maneira interessantegrub-install , não reconhece que o sistema operacional Debian está no USB.

Exemplo

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 eu crio um chroot e posso executar update-grub, mesmo estando no sistema operacional que iniciei a inicialização do próprio USB, ele não vê seu próprio sistema operacional!

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

Só vê Raspbian. Isso acontece apenas ao tentar instalar e atualizar o GRUB dentro do contêiner, mas quando saio do chroot.

Veja como agora funciona porque eu não desmontei os diretórios chroot:

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

De fora do contêiner, lembre-se, estou executando este comando com o grub-ubootRaspbian instalado e sem o Grub no USB que contém o Debian com desbootstrap.

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#

Isso não acontece usando uma das imagens não oficiais disponíveis para o Debian ARM , mas obviamente ainda é uma personalização ainda não disponível para desbootstrapping.

Solução de problemas

Realmente, há momentos em que é melhor apenas criar um caminho. A única possibilidade seguinte (e provável) é simplesmente escrever o GRUB. E por isso vou ler nesta página.

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

Outra coisa que quero compartilhar sobre esse problema é uma solução que pode funcionar, mas percebe que os cartões microSD são muito sensíveis. Eu tenho construído minhas próprias imagens do Linux e aprendi isso rapidamente. A melhor coisa a fazer é usar o Qemu sempre que puder, mas para tentar limpar uma tabela de partições antiga, tente executar sgdisk --zap-allna unidade.

sgdisk --zap-all /dev/sdd

Na verdade, por vezes, se ele dá um erro na primeira vez e é não leitura, você poderá executá-lo novamente e finalmente todas as tabelas de partição serão novas ou antigas.

E você pode usar o Qemu para emular o Raspberry Pi em um PC padrão baseado em AMD / Intel. Eu recomendaria. Eu sei que isso é mais informações do que pertence à postagem original, mas acho que é provável que esse erro seja derivado. É a idade do contêiner.

Para quem está lutando com isso que está tentando usar um USB ativo ou outros meios de chroot para reinstalar ou instalar o grub - eu lidei com isso algumas vezes e esqueci de documentá-lo antes, embora eu pretendesse.

O problema que você enfrenta é o grub não tem acesso ao caminho ao qual você está se referindo como fonte (/ boot) ou destino (o sistema e o chroot podem ver, /dev/sdapor exemplo?) Ou ambos. Ao se preparar para chroot, você cria montagens de ligação acessíveis no ambiente chroot ou o faz dentro do chroot usando mount -t. Existem muitos guias on-line que fazem isso de qualquer maneira.

Você precisa certificar-se de vincular o / dev ou apenas as partições específicas que contêm os arquivos de inicialização em / boot (por exemplo, / dev / sda1). / boot é uma partição separada ou um diretório em / O chroot precisa acessar a unidade na qual você estará (re) instalando o grub, assim como o fdisk -l no chroot para garantir que você possa ver o dispositivo listado na saída. Observe também que, se você não possui uma partição de inicialização separada, mas possui um diretório de inicialização em / root com os arquivos de inicialização (não apenas um ponto de montagem), basta montar a partição que contém raiz. Você não precisa montar nada no / root / boot.

Você também precisa certificar-se de vincular o sistema de arquivos proc e o sistema de arquivos sys, mas todos os guias que eu vi possuem esses dois. Acabei de ver / dev perder algumas vezes. Pode haver alguns casos em que você não precisa, mas eu não os conheço.

tl; dr: certifique-se de vincular mount / dev