o grub não instala

11

Estou tentando reinstalar o grub de uma unidade USB. Eu corro o seguinte:

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

Eu recebo o seguinte erro:

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

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

Editar

Eu estou tentando reparar um sistema de inicialização dupla quebrado, rodando a partir de um USB contendo o Linux mint.

    
por elyashiv 21.10.2013 / 15:44

4 respostas

8

Siga estas etapas:

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

  2. Monte a partição / do seu SO instalado em /mnt

    sudo mount /dev/sda6 /mnt
    
  3. Configure um ambiente chroot :

    sudo chroot /mnt
    
  4. Agora você está em uma instalação Linux "falsa" que trata /mnt as / . Isso significa que todos os arquivos necessários para o GRUB estão em /boot , onde o sistema espera que eles 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.

    
por 21.10.2013 / 16:06
0

Com base no que foi escrito, parece que você está tentando instalar o GRUB em / dev / sda. Você não quer 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-install do seu sistema: link

    
por 21.10.2013 / 16:17
0

Se o grub disser que não foi possível resolver o caminho canônico de algo, 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 que realpath() não funciona. Um dos motivos pode ser que /proc não esteja montado. Em algumas implementações da libc, /proc/self/fd é usado para obter o caminho canônico de um arquivo.

    
por 10.03.2018 / 16:29
0

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

Antecedentes

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

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

Por exemplo, eu criei este arquivo:

/etc/systemd/system/[email protected]/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 ao usar grub-install /dev/sda ou update-grub para um USB no Pi debootstrapped com o Debian Stretch. Mesmo usando o grub-uboot e o grub-efi-arm ainda existe esse erro, o grub-probe não pode encontrar o caminho canônico.

Não apenas isso, mas também update-grub verá e saberá quais são os sistemas operacionais, mas curiosamente grub-install não reconhece que o sistema operacional Debian está em 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 rodar update-grub , mesmo que eu esteja no sistema operacional que eu desboquei no 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:/#

Ele só vê Raspbian. Isso acontece apenas ao tentar instalar e atualizar o GRUB dentro do contêiner, mas quando eu sair do chroot.

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

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

De fora do contêiner, você está executando este comando com grub-uboot instalado no Raspbian e nenhum Grub no USB contendo o 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#

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

Resoluçã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 para isso eu vou ler nesta página.

link

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

sgdisk --zap-all /dev/sdd

Na verdade, às vezes, se ocorrer um erro na primeira vez e não for não um erro somente 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 padrão PC baseado em AMD / Intel. Eu recomendaria. Eu sei que isso é mais informação do que o post original, mas acho que é provável como esse erro é derivado. É a idade do recipiente.

    
por 24.07.2018 / 17:33

Tags