grub2: update-grub falhou ao obter caminho canônico de 'none'

Question

$ sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of 'none'.

Esta é a situação em que estou após uma atualização interrompida de viva para astuta

[editar]

Investigando ainda mais o código-fonte do grub, o segundo comando provavelmente é o que está falhando:

$ grub-probe --target=device /
/dev/md2
$ grub-probe --target=device /boot
grub-probe: error: failed to get canonical path of 'none'.

O seguinte também apresenta o erro:

$ sudo grub-probe -t device /boot/grub
grub-probe: error: failed to get canonical path of 'none'.
$ sudo grub-probe -t fs_uuid /boot/grub
grub-probe: error: failed to get canonical path of 'none'.

[/ edit]

Eu não tenho /boot/grub/grub.cfg present (ou mais antigo /boot/grub/menu.lst)

Foi impossível instalar um gerenciador de partida durante a configuração do grub:

link

O Grub não pôde ser instalado nas opções disponíveis ( /dev/sda /dev/sdb ou /dev/md2 )

md1 não foi dado como uma opção, embora esteja atualmente montado em / boot:

$ cat /etc/fstab
proc /proc proc defaults 0 0
/dev/md/0 none swap sw 0 0
/dev/md/1 /boot ext3 defaults 0 0
/dev/md/2 / ext4 defaults 0 0

Eu tenho uma configuração de raid com / dev / sda e / dev / sdb de qualquer forma:

$ sudo fdisk -l
Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00032e61

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1          2048   8390656   8388609     4G fd Linux raid autodetect
/dev/sda2       8392704   9441280   1048577   512M fd Linux raid autodetect
/dev/sda3       9443328 937701040 928257713 442.6G fd Linux raid autodetect


Disk /dev/sdb: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00074c3d

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sdb1          2048   8390656   8388609     4G fd Linux raid autodetect
/dev/sdb2       8392704   9441280   1048577   512M fd Linux raid autodetect
/dev/sdb3       9443328 937701040 928257713 442.6G fd Linux raid autodetect


Disk /dev/md2: 442.5 GiB, 475133575168 bytes, 927995264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md0: 4 GiB, 4292804608 bytes, 8384384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 511.7 MiB, 536543232 bytes, 1047936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

O Grub parece estar instalado (detecção de outra resposta no serverfault):

$ sudo dd bs=512 count=1 if=/dev/sda 2>/dev/null | strings
ZRr=
'|f 
\|f1
GRUB 
Geom
Hard Disk
Read
 Error

Quando executo o grub-emu, recebo uma solicitação em branco:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 15.10
Release:        15.10
Codename:       wily

Isto está em um servidor com apenas acesso ssh, então eu não tenho acesso ao live CD se o grub falhar!

[edit] saída de df -h :

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             63G     0   63G   0% /dev
tmpfs            13G  714M   12G   6% /run
/dev/md2        436G  178G  236G  44% /
tmpfs            63G  8.0K   63G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            63G     0   63G   0% /sys/fs/cgroup
none            436G  178G  236G  44% /boot
tmpfs            13G     0   13G   0% /run/user/0
tmpfs            13G     0   13G   0% /run/user/1002
/dev/md2        436G  178G  236G  44% /var/cache/apt/archives
none            436G  178G  236G  44% /bin
none            436G  178G  236G  44% /etc
none            436G  178G  236G  44% /initrd
none            436G  178G  236G  44% /lib
none            436G  178G  236G  44% /lib32
none            436G  178G  236G  44% /lib64
none            436G  178G  236G  44% /sbin
none            436G  178G  236G  44% /usr
none            436G  178G  236G  44% /var

[editar mais] o comando acima parece relatar que / boot está montado em none . Acho que isso pode ser o none grub-probe está reclamando. Aqui está a saída de mount -l que mostra duas 'entradas' de montagem separadas; investigando como remover o segundo agora.

mount -l |grep boot
/dev/md1 on /boot type ext3 (rw,relatime,data=ordered)
none on /boot type aufs (rw,relatime,si=6ea5aad590be877d)

    

Answer 1

Ok, eu pareço tê-lo com o seguinte (tudo é simples em retrospecto):

$ umount /boot

Eu tentei isso, pois notei que havia dois 'mounts' para / boot:

$ mount -l |grep boot
/dev/md1 on /boot type ext3 (rw,relatime,data=ordered)
none on /boot type aufs (rw,relatime,si=6ea5aad590be877d)

E que o último estava dominando o primeiro:

$ df -h |grep boot
none            436G  178G  236G  44% /boot

Depois de desmontar, os mesmos comandos ficam assim:

$ mount -l |grep boot
/dev/md1 on /boot type ext3 (rw,relatime,data=ordered)
$ df -h |grep boot
/dev/md1        488M   75M  388M  17% /boot

(não tem ideia de como aconteceu o segundo monte)

Eu fui então capaz de reinstalar o grub da seguinte forma (eu tenho o raid1, e é por isso que existem dois comandos para sda e sdb):

$ grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
$ grub-install /dev/sdb
Installing for i386-pc platform.
Installation finished. No error reported.
$ update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.19.0-30-generic
Found initrd image: /boot/initrd.img-3.19.0-30-generic
Found linux image: /boot/vmlinuz-3.19.0-25-generic
Found initrd image: /boot/initrd.img-3.19.0-25-generic
done

Postscript

Após a reinicialização, o servidor voltou a funcionar (poderia fazer ping dele), mas descobri que não consegui fazer o ssh. Isso acabou sendo um problema separado do / dev / null (pode ter sido quebrado ao mesmo tempo ). Eu era capaz de usar um sistema de recuperação separado e aplicar esta correção: link

    

Answer 2

Você já tentou grub-install ?

Se você não pode usá-lo, então ...

Como eu vejo, você pode executar um terminal no sistema:

Faça

apt-get -f install

Como superusuário.

Se não pedir para instalar nada, nada será quebrado.

Considere:

apt-get upgrade //To finish upgrading

Último

apt-get install -y aptitude && aptitude reinstall grub

Agora tente novamente com o grub-install

Nota:

Para uso no grub-install, faça:

man grub-install

    

Answer 3

Não se preocupe em tentar corrigi-lo. Use boot-repair Conecte-se à Internet, abra um terminal com Ctrl + Alt + t, cole os seguintes comandos e execute-os pressionando Enter:

sudo add-apt-repository -y ppa:yannubuntu/boot-repair; \
sudo apt-get update; \
sudo apt-get install -y boot-repair && boot-repair

A próxima coisa (perigosa) que você pode fazer se o reparo da inicialização não funcionar é tentar reinstalá-lo, o que não permitirá. Então escolha outra coisa. Crie tudo da mesma maneira e tenha a mesma senha e nome de usuário. Isso foi dito para funcionar como um reparo.

Melhor alternativa se o reparo de inicialização não funcionar é fazer o backup de seus dados e instalar novos. Você pode fazer backup com um disco ao vivo. Lembro-me de ter feito algo trivial no Lubuntu que só atrapalhava algumas configurações. Foi sugerido para backup e instalação nova. Foi-me dito que levaria uma hora para fazer e não gastar horas tentando descobrir. Acabei seguindo este conselho depois de tentar algumas outras coisas. Ele estava certo.

Você também pode tentar este link para reparar o grub de um usb ao vivo link Eu tentei algo similar (mas não o mesmo link) quando uma falha na atualização do kernel estragou tudo. Eu pesquisei "como consertar o grub após uma falha na atualização do linux" e obtive uma variedade de páginas. Você pode tentar procurar por "grub repair usb live". Tente isto que tem respostas terminais e gráficas. link

    

Answer 4

Isso seria suficiente como root no modo de recuperação após a ativação da rede:

  

sudo apt-get install --reinstale o grub *

     

sudo grub-install / dev / partição

Para a partição você digita a partição de inicialização que você é muito seguro, como por exemplo / dev / sda

Em seguida, faça o seguinte:

Existe um erro de verificação ortográfica, mas apenas ligeiramente? Você poderia tentar isso:

  

sudo update-grub2

e NÃO

  

sudo update-grub