Depurando a falha de configuração do dpkg com o grub

Question

Em uma de minhas máquinas, o dpkg não pode concluir a instalação / configuração do grub, apenas informando a mensagem de erro:

subprocess installed post-installation script returned error exit status 255

Saída completa:

# dpkg --configure grub-pc
Setting up grub-pc (1.99-27+deb7u3) ...
device node not found
device node not found
device node not found
device node not found
Installation finished. No error reported.
Installation finished. No error reported.
dpkg: error processing grub-pc (--configure):
 subprocess installed post-installation script returned error exit status 255
Errors were encountered while processing:
 grub-pc

Não há nada nos arquivos de log que possam lançar mais luz.

Rodar o dpkg com algumas opções de depuração revela um pouco mais:

# dpkg -D10113 --configure grub-pc
Setting up grub-pc (1.99-27+deb7u3) ...
D000002: fork/exec /var/lib/dpkg/info/grub-pc.postinst ( configure  )
device node not found
device node not found
device node not found
device node not found
Installation finished. No error reported.
Installation finished. No error reported.
dpkg: error processing grub-pc (--configure):
 subprocess installed post-installation script returned error exit status 255
D010000: trigproc_run_deferred
Errors were encountered while processing:
 grub-pc

Agora eu sei que o problema é em algum lugar em /var/lib/dpkg/info/grub-pc.postinst configure , mas esse script não parece ter nenhuma opção de verbosidade ou depuração e é grande demais para ser lido com quase 700 linhas. O script também não tem nenhuma chamada exit 255 , então eu acredito que o problema não está lá, mas em algum outro script que é chamado.

A tarefa de configuração também falha nos processos do kernel:

# dpkg --configure linux-image-3.16.0-0.bpo.4-amd64
Setting up linux-image-3.16.0-0.bpo.4-amd64 (3.16.39-1+deb8u1~bpo70+1) ...
vmlinuz(/boot/vmlinuz-3.16.0-0.bpo.4-amd64
) points to /boot/vmlinuz-3.16.0-0.bpo.4-amd64
 (/boot/vmlinuz-3.16.0-0.bpo.4-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-3.16.0-0.bpo.4-amd64.postinst line 263.
initrd.img(/boot/initrd.img-3.16.0-0.bpo.4-amd64
) points to /boot/initrd.img-3.16.0-0.bpo.4-amd64
 (/boot/initrd.img-3.16.0-0.bpo.4-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-3.16.0-0.bpo.4-amd64.postinst line 263.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-0.bpo.4-amd64
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 255
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.16.0-0.bpo.4-amd64.postinst line 634.
dpkg: error processing linux-image-3.16.0-0.bpo.4-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-3.16.0-0.bpo.4-amd64

A linha 634 em /var/lib/dpkg/info/linux-image-3.16.0-0.bpo.4-amd64.postinst resume-se a este comando:

run-parts --report --exit-on-error --arg=3.16.0-0.bpo.4-amd64 --arg=/boot/vmlinuz-3.16.0-0.bpo.4-amd64 /etc/kernel/postinst.d

A execução deste comando resulta manualmente em:

run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 255

Esse script é, até onde eu sei, apenas um wrapper que faz uma checagem e então chama update-grub , que funciona sem erro.

update-grub apenas executa grub-mkconfig , por isso executei este comando e verifiquei o valor de retorno:

# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.16.0-0.bpo.4-amd64
Found initrd image: /boot/initrd.img-3.16.0-0.bpo.4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
# echo $?
255

Este parece ser o culpado. O script funciona, encontra todos os kernels, gera uma configuração válida do grub (salva-o como /boot/grub/grub.cfg.new embora) e então sai com o código de retorno 255. E, é claro, não possui opções de depuração.

Como posso continuar a depurar o problema?

Informações adicionais que podem ou não ser úteis:

• o sistema está executando o debian wheezy
• O GRUB é a versão 1.99-27 + deb7u3
• o sistema tem um mdraid
• o sistema está em execução há anos, não é uma nova instalação. O erro apareceu apenas recentemente
• não tenho certeza, mas acredito que o erro começou a aparecer depois que um disco rígido defeituoso foi substituído
• a tarefa de configuração só falha no grub e nos pacotes do kernel. Todos os outros pacotes podem ser instalados sem erros

Mais informações de perguntas que surgiram depois

zulu668:~# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sda4[2] sdb4[1]
      1456504640 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda3[2] sdb3[1]
      7996352 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda2[2] sdb2[1]
      499392 blocks super 1.2 [2/2] [UU]

unused devices: <none>
zulu668:~# sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Oct 29 12:40:33 2014
     Raid Level : raid1
     Array Size : 499392 (487.77 MiB 511.38 MB)
  Used Dev Size : 499392 (487.77 MiB 511.38 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed Mar 15 14:51:01 2017
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : zulu668:0  (local to host zulu668)
           UUID : 22e14818:7754cf01:67287402:c31a3328
         Events : 217

    Number   Major   Minor   RaidDevice State
       2       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2

    

Answer 1

Então, no momento da redação, você reduziu seu problema de forma brilhante a grub-mkconfig e se perguntou como depurá-lo.

grub-mkconfig é um script de shell que basicamente cria seu arquivo de configuração grub.cfg executando todos os scripts em /etc/grub.d . Há um comando set -e no início de grub-mkconfig , que significa "parar no primeiro erro não gerenciado encontrado". As chances são de que seu problema é devido à falha de um dos scripts grub.d.

Primeiro, vamos identificar o culpado. Executar:

dash -vx grub-mkconfig -o /boot/grub/grub.cfg

dash , o interpretador Bourne Shell que provavelmente está vinculado a /bin/sh , exibirá todas as linhas executadas. Como o script provavelmente falha devido ao comando set -e , a última linha provavelmente será o sub-script grub.d que falha. Eu suponho que você terá algo como:

+ echo ### BEGIN /etc/grub.d/99_buggy_script ###
+ /etc/grub.d/99_buggy_script

O próprio nome do script provavelmente não fornecerá evidências suficientes sobre o que está acontecendo. Como também é um script de shell Bourne, você pode depurá-lo da mesma maneira. Altere a primeira linha do script grub.d de

#!/bin/sh

Para:

#!/bin/sh -vx

E execute grub-mkconfig -o /boot/grub/grub.cfg ( dash -vx não é mais necessário). O rastreio que você obterá é do script grub.d.

Espero que o problema seja óbvio agora. Depois de ter corrigido, não se esqueça de remover os -vx flags no início do sub-script grub.d.

    

Answer 2

Eu li que você deve instalar grub em todos os discos rígidos pertencentes a um ataque. Como você substituiu um disco rígido defeituoso, verifique isso executando:

dpkg-reconfigure grub-pc

quando chegar à seção GRUB install devices , você poderá ver quais dispositivos estão marcados por um asterisco * e quais não estão, e você pode marcá-los usando o cursor e a tecla de espaço / s. (Todos os devids principais /dev/sda , /dev/sdb , /dev/sdc etc. devem ser marcados)

Terminar este passo deve reinstalar o grub e trazer tudo de volta ao normal.