Qual é a causa deste pânico do kernel?

Question

Acabei de configurar um servidor de boot PXE no Ubuntu 14 - executando o kernel 3.13.0-30-generic - como é descrito aqui link no hardware Supermicro X9DRFF.

Eu só tenho acesso remoto ao servidor do cliente via KVM. O processo de inicialização no cliente vai bem, mas eu tenho um kernel em pânico.

É possível determinar a causa deste pânico do kernel?

    

Answer 1

Eu fiz isso. O problema acabou por ser muito simples. Eu dei ao cliente PXE um kernel 3.13.0-30. Mas eu estava executando o mkinitramfs em uma máquina com um kernel 3.13.0-24.

Eu comecei a dar a um cliente PXE o kernel 3.13.0-24 e funcionou.

    

Answer 2

Parte da saída está faltando, já que rolou para fora da tela, mas é possível ver que o kernel travou em mount_root() . Isso significa que houve um problema com a montagem do que você passou como o sistema de arquivos raiz. Verifique para ter certeza de que você passou os parâmetros corretos para o kernel para inicializar a partir de qualquer mídia que ele deveria estar inicializando.

    

Answer 3

É realmente possível. Você precisa do kernel de depuração para essa distro em particular.

Em um host separado.

• Faça o download da versão do kebug desse kernel. Ele conterá um arquivo vmlinux .

Abra o arquivo vmlinux no gdb.

$ gdb /usr/lib/debug/lib/modules/3.14.9-200.fc20.x86_64/vmlinux
GNU gdb (GDB) Fedora 7.7.1-13.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/debug/lib/modules/3.14.9-200.fc20.x86_64/vmlinux...done.
(gdb) 

A partir da saída da pilha, podemos ver antes do pânico que a função mais útil do kernel era mount_block_root .

Para determinar onde falhamos, precisamos inserir o nome da função mais um deslocamento no GDB. Isso é feito des-referenciando o endereço para a função, mais o deslocamento. O rastreamento de pilha fornece o deslocamento como o primeiro valor após a função.

I.E mount_block_root+0x225 significa (eu estava em "mount_block_root" mais 549 bytes (a tradução hexadecimal).

Finalmente, informamos ao GDB para imprimir o código-fonte dessa área. No meu sistema Linux, isso resulta no seguinte

(gdb) list *(mount_block_root+0x225)
0xffffffff81d26513 is in mount_block_root (init/do_mounts.c:422).
417                "explicit textual name for \"root=\" boot option.\n");
418 #endif
419         panic("VFS: Unable to mount root fs on %s", b);
420     }
421 
422     printk("List of all partitions:\n");
423     printk_all_partitions();
424     printk("No filesystem could mount root, tried: ");
425     for (p = fs_names; *p; p += strlen(p)+1)
426         printk(" %s", p);

A partir daqui, podemos dizer exatamente onde estávamos no momento do acidente. OBSERVAÇÃO meu kernel não é seu kernel, então os deslocamentos estão provavelmente desativados. Com base na probabilidade de que ambos os kernels sejam quase iguais, eu irei cobrir uma aposta de que o pânico real realmente ocorre na linha 419, e não na linha 422 (como foi sugerido).

Ler mais o código indica um pouco que não foi possível abrir o dispositivo de bloco especificado - mas sem um despejo de memória não é possível dizer por que a partir das informações. Então é provavelmente: -

• Você não quer montar um dispositivo de bloco (provavelmente).
• Você especificou um endereço de dispositivo de bloco inexistente (ou partição).
• Seu initrd não contém o módulo de sistema de arquivos adequado no initrd para montá-lo.
• Não há sistema de arquivos no disco.
• O superbloco do sistema de arquivos não está no início desse local.

Seguindo o link em sua referência, ele sugere que você está tentando montar com o NFS como a raiz, caso em que você nunca deve terminar esta função. Nesse caso:

• Sua linha de comando do kernel contém várias diretivas raiz.
• Você digitou incorretamente seu endereço NFS de forma que ele não seja analisado corretamente para ir para a função real desejada ( mount_nfs_root ).

Assim, em geral, com base nas informações da pergunta, suponho que você tenha omitido algo ou tenha cometido um erro de digitação.

    

Answer 4

1. O link entre aspas não possui o conjunto completo de parâmetros (linha de acréscimo) necessários para a inicialização do PXE Lubuntu 14.04.
2. O kernel panic = > a montagem não pode ser executada corretamente por causa de 1).

Você pode ver Como a Serva resolveu as linhas corretas aqui (estou relacionado ao desenvolvimento do Serva) link

O Serva usa um compartilhamento CIFS ao invés do NFS, mas você pode muito bem usar o NFS se quiser. Claro que você não precisa usar o Serva; você pode usar seus parâmetros em seu próprio servidor PXE

[PXESERVA_MENU_ENTRY]
asset    = Lubuntu 14.04 Desktop Live
platform = amd64
kernel   = NWA_PXE/$HEAD_DIR$/casper/vmlinuz
append   = showmounts toram root=/dev/cifs initrd=NWA_PXE/$HEAD_DIR$/casper/initrd.lz,NWA_PXE/$HEAD_DIR$/casper/INITRD_N11.GZ boot=casper netboot=cifs nfsroot=//$IP_BSRV$/NWA_PXE_SHARE/$HEAD_DIR$ NFSOPTS=-ouser=serva,pass=avres,ro ip=dhcp ro

Por favor, considere

1. Ubunu / Lubuntu tem um bug que se você PXE inicializá-los usando o CIFS você deve adicionar o initrd complementar INITRD_N11.GZ (disponível gratuitamente na página da Serva)
2. Se você estiver instalando a versão de 64 bits, os parâmetros anteriores exigirão que você renomeie o arquivo \ casper \ vmlinuz.efi para \ casper \ vmlinuz

Answer 5

Eu tive o mesmo problema com o Ubuntu 14.04 hoje, e foi bastante desagradável, então eu quero compartilhar a solução que encontrei com o mundo aqui ...

Eu estava usando o pxelinux.0, o NFS para o sistema de arquivos raiz e o TFTP para exibir a imagem do kernel e o initramfs. Como mencionado acima por @MatthewIfe, olhar para o backtrace da pilha e funções sendo chamadas claramente indica que este problema estava ocorrendo em uma função relacionada ao dispositivo de bloco, e o mount_nfs_root nunca foi chamado.

Então eu mudei para os registros TFTP, como indicado pelo autor de este post , e notei que meu arquivo de configuração foi nomeado como:

tftproot/pxelinux.cfg/default

Também ficou assim:

DEFAULT vmlinuz
LABEL Ubuntu 14.04 Blah Blah
KERNEL vmlinuz
APPEND initrd=initrd root=/dev/nfs nfsroot=192.168.1.123:/path/to/exportfs

Além disso, meu carregador do iPXE também procurava outros arquivos como no post:

pxelinux.cfg/40709cda-a8e0-d411-8c6c-001e68e210ae
pxelinux.cfg/01-00-1e-68-e2-10-ae
pxelinux.cfg/C0A8010E
pxelinux.cfg/C0A8010
pxelinux.cfg/C0A801
pxelinux.cfg/C0A80
pxelinux.cfg/C0A8
pxelinux.cfg/C0A
pxelinux.cfg/C0
pxelinux.cfg/C
pxelinux.cfg/default

Mas não vi nenhum registro no log do initrd sendo removido. Então, decidi testar e ver se minha linha APPEND estava funcionando. Então eu adicionei um "pânico = 10", novamente como no post vinculado. E parecia não estar funcionando. Portanto, nenhuma das minhas diretivas de linha de configuração do kernel estava sendo usada! Em um palpite eu decidi fazer duas coisas - simplificar o meu arquivo para coincidir com o post

DEFAULT linux
LABEL linux
KERNEL vmlinuz
APPEND root=/dev/nfs nfsroot=192.168.1.123:/path/to/exportfs initrd=initrd panic=10

e mude o nome para algo como

tftproot/pxelinux.cfg/01-00-1e-68-e2-10-ae

E voilà - o initrd é puxado para baixo, não há mais pânico no kernel, e o NFS é montado como o sistema de arquivos raiz corretamente usando o kernel / initramfs padrão / genérico. Tenho certeza de que posso mudar o rótulo de volta, etc. Acho que o problema real foi com a nomeação do arquivo de configuração e o que o pxelinux.0 espera.