Kernel Panic ao Reiniciar/Desligar Linux Mint

Ele criou uns links, lá.

Só não criou todos.

A pulga que tenho na orelha é que nós fomos bem claros.

  • Execute o serviço “pre” ANTES de executar o serviço de criação da initram.

Ou eu sempre entendi errado o funcionamento dessas diretivas, ou o systemd tá tirando sarro da nossa cara.

Qualquer coisa, vou colocar essa diretiva lá no serviço, também.

Essa impressão de redundância me incomoda um bocado.

Mas se tiver que fazer, vou fazer.

Fica de olho aí, @Pedroh99

Qualquer coisa, avisa a gente.

Valeu pelo toque, @Deleterium

1 Curtida

Hmmmm !

Acho que entendi a confusão que estou fazendo.

O finalrd.service só cria a initram quando recebe um stop.

Então, vamos deletar o serviço “pre” e executar o script pelo próprio finalrd.service

Então, dei uma pesquisada aqui sobre o mkinitcpio e vi que ele tem uma opção, o dracut.

Resolvi fazer a experiência e instalei o dracut na máquina virtual. Ele conflita com o initramfs-tools-core e e a instalação dele remove a opção padrão. Também vi que ele cria a initramfs completinha, enquanto o mkinitcpio criava apenas com o microcode. Não inspecionei no shutdown pra ver se ele criava o initrd completo. O dracut também tem um serviço que é chamado no shutdown e (eu acho que) extrai o conteúdo do initramfs já criado pro /run no shutdown. Eu acho isso porque o initramfs criado por ele inclui o shutdown. Talvez essa seja uma solução ao ser testada, eu pessoalmente acho o dracut melhor e mais fácil de mexer.

Aqui o a saída do lsinitrd do meu mint “dracutizado” Ubuntu Pastebin

1 Curtida

Pedro !

Vamos desfazer algumas coisas.

  • Volta o shutdown.target pro original, deletando as linhas

      Requires=pedro_pre_tmpfs.service
      After=pedro_pre_tmpfs.service
    
  • desabilita o serviço “pre”

systemctl disable pedro_pre_tmpfs.service

  • Checa o “pos” e tira todas as referências que ele tiver pro “pre”

  • volta o finalrd.service original

Agora vem o pulo do gato.

Edita o finalrd.service e inclui uma linha chamando o script do “pre”.

Acho que fica assim.

[Unit]
Description=Create final runtime dir for shutdown pivot root
Documentation=man:finalrd(1)
After=local-fs.target boot.mount boot.automount
Wants=local-fs.target
Conflicts=shutdown.target umount.target
DefaultDependencies=No

[Service]
RemaiAfterExit=yes
Type=oneshot
ExecStart=/bin/true
ExecStop=/home/pedro/shut/pre_tmpfs.sh
ExecStop=/usr/bin/finalrd

[Install]
WantedBy=sysinit.target

Claro, o primeiro ExecStop tem que refletir o caminho que você usou pro script.

OBS : Esse é meu finalrd.service original. Só tem a mais a linha

ExecStop=/home/pedro/shut/pre_tmpfs.sh

Se o teu estiver diferente, só adiciona a linha sem alterar mais nada.

Feito tudo, vamos dar o reload

systemctl daemon-reload

Se eu não estiver enganado, isso deve garantir as condições que queremos.

ALTERNATIVA

EDITADO porque esta foi escolhida como solução e pode não estar muito claro para novos visitantes a forma de resolver

O problema consiste no fato de que a criação da initramfs (que ocorre no final do shutdown) pode ser corrompida quando executa em paralelo com a desativação da área de swap, fazendo com que alguns links não sejam devidamente inseridos na imagem.

Uma maneira de forçar que as operações ocorram em sequência, é editando o arquivo /lib/systemd/system/finalrd.service e garantindo que a área de swap esteja desativada antes da criação da initram. Isso pode ser alcançado inserindo-se a linha

ExecStop=/sbin/swapoff -a

logo antes da linha

ExecStop=/usr/bin/finalrd

3 Curtidas

O programa que o sistema usa orignalmente é o /usr/bin/finalrd

O que está acontecendo é que uma coisa está atropelando a outra.

Quando o shutdown inicia, o normal seria o swap desativar e esse serviço criar a initram. Ou então, esse serviço criar a initram e o swap parar.

Só que, pelas condições do shutdown do Pedro, os dois serviços estão fazendo tudo ao mesmo tempo. A swap está desativando enquanto ele está criando a initram.

Isso não deveria ser problema. Mas o fato é que, de alguma forma, a criação está sendo corrompida.

Acho que a situação pode ser a mesma com o dracut. Mas vou testar aqui.

O que estamos tentando é impedir que as coisas aconteçam ao mesmo tempo.

Seria tranquilo se a criação da initram estivesse em uma diretiva ExecStart, mas está em uma ExecStop e eu não tenho muita experiência com essa diretiva.

Vou ver o dracut aqui na esperança que o “trabalho” esteja sendo feito por uma diretiva ExecStart

2 Curtidas

Parece que não. Porém a vantagem é que ele não cria a initram, ele só descompacta a mesma da inicialização.

$ cat /lib/systemd/system/sysinit.target.wants/dracut-shutdown.service
#  This file is part of dracut.
#
# See dracut.bootup(7) for details

[Unit]
Description=Restore /run/initramfs on shutdown
Documentation=man:dracut-shutdown.service(8)
After=local-fs.target boot.mount boot.automount
Wants=local-fs.target
Conflicts=shutdown.target umount.target
DefaultDependencies=no
ConditionPathExists=!/run/initramfs/bin/sh

[Service]
RemainAfterExit=yes
Type=oneshot
ExecStart=/bin/true
ExecStop=/usr/lib/dracut/dracut-initramfs-restore
1 Curtida

É. Acabei de ver aqui também.

Vou ver com o Pedro se enfileirar dois ExecStop funciona do mesmo jeito que enfileirar dois ExecStart.

Um dos problemas é que a máquina do Pedro chega nesse estágio com apenas 129 M livre. Tá apertado.

Aí o bicho pega porque a initram da inicialização com varios módulos do kernel fica de um tamanho considerável.

1 Curtida

Eu acho que, no frigir dos ovos, é isso que tá impedindo a criação da initram. Mas pelo menos já sabemos onde o problema está. Agora estamos no esforço de evitá-lo.

Pedrão !

Caso você tenha se perdido, as novas recomendações estão no post #125.

1 Curtida

Ok, acabei de fazer essas alterações aqui. Vou ficar de olho se acontecer algo.

1 Curtida

Eu acho que não é 129 M não. As colunas ficaram meio deslocadas naquele log. Repara que tem uma que parece que fica sobrando se vc olhar do jeito que está escrito. Acredito que deveria estar assim:

      total usada livre compart. buff/cache disponível
Mem.: 3,7Gi 129Mi 2,5Gi 7,0Mi 1,0Gi 3,3Gi
Swap: 0B 0B 0B
1 Curtida

Ahhhh !

Você tem toda razão.
Menos mal, então.

E aí, Dom Pedro !

Pelo menos diminuiu a frequência dos panics ?

1 Curtida

Oi, hoje eu já desliguei o computador umas 4 vezes, e até agora não aconteceu nenhum kernel panic. Eu to achando que dessa vez resolveu! Vou desligar mais algumas vezes durante o dia de hoje, e se não acontecer mais eu acho que dá pra dizer que funcionou! A noite eu volto confirmando.

2 Curtidas

Bom, @chimpa_theist , eu fiz um uso bastante intenso do computador hoje, e fui fazendo alguns desligamentos ao longo do dia pra verificar se ocorriam kernel panics. Como não aconteceu nenhum, eu acredito que finalmente o problema foi resolvido! Muito obrigado pela ajuda! E obrigado a todos que ajudaram também!

2 Curtidas

Estou com o mesmo problema… Qual foi a solução? Fiquei meio perdido depois de tantos testes…

Valeu, Pedro !

Ainda estou apreensivo, mas estou torcendo para que tenha resolvido.

1 Curtida

Oi Gustavo.

É o mesmo problema ?
Tem uma tela de shutdown com bug aí, pra mostrar ?

Você pode também fornecer a saída do seguinte comando ?

cat /lib/systemd/system/finalrd.service