Kernel Panic ao Reiniciar/Desligar Linux Mint

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

Bom, qualquer coisa eu volto.

2 curtidas

Olha aí, chimpa.

E a saída do comando:

gustavo@IPM31 ~ $ cat /lib/systemd/system/finalrd.service
# SPDX-License-Identifier: GPL-3.0-only

[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]
RemainAfterExit=yes
Type=oneshot
ExecStart=/bin/true
ExecStop=/usr/bin/finalrd

[Install]
WantedBy=sysinit.target

Ok.

Você tem que editar esse arquivo para inserir uma linha.

Acima da linha

ExecStop=/usr/bin/finalrd

tem que colocar a linha

ExecStop=/sbin/swapoff -a

Para não haver dúvida, o arquivo tem que ficar 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]
RemainAfterExit=yes
Type=oneshot
ExecStart=/bin/true
ExecStop=/sbin/swapoff -a
ExecStop=/usr/bin/finalrd

[Install]
WantedBy=sysinit.target

Você consegue editá-lo ?

Se tiver alguma dificuldade, avisa aí.

Depois de editar, precisa recarregar as dependências do systemd

sudo systemctl daemon-reload

E pronto.
Daí em diante, só ficar observando se o erro para de aparecer.

3 curtidas

Certo, editei o arquivo e recarreguei o systemd. Agora vou ficar observando…

Muito obrigado!

1 curtida

Olá pessoal,

Estou com o mesmo problema de às vezes não completar o desligamento e precisar forçar no botão. A imagem do kernel panic está aí embaixo. Acredito que seja o mesmo dos outros colegas.

Saída do comando que pediu ao Gustavo:

cat /lib/systemd/system/finalrd.service

SPDX-License-Identifier: GPL-3.0-only

[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]
RemainAfterExit=yes
Type=oneshot
ExecStart=/bin/true
ExecStop=/usr/bin/finalrd

[Install]
WantedBy=sysinit.target

Estou com Linux Mint 20.1 Cinnamon e kernel 5.4.0-65-generic mas já testei vários outros anteriores e o problema continua. 4Gb de memória e 3.8Gb de swap

Demorei a entender que o arquivo que tinha que alterar ficava em /lib/systemd/system/finalrd.service

Não sabia abrir esse arquivo como root, então abri o nemo como root (sudo nemo) e fui de pasta em pasta até o local.

Já adicionei a linha que sugeriu e estou em fase de testes. Obrigado pela ajuda

1 curtida

Ao que parece, é um bug “oficial” do Mint.

Cara, eu tinha tentado um monte de coisas relacionadas ao kernel. Fiz vários upgrades e downgrades nele para testar. Mas vocês arrebentaram. No primeiro desligamento funcionou normal. Achei muito legal a dedicação de vocês em ajudar.

Tem mais um assunto que me incomoda aqui que é a lentidão algumas vezes enquanto estou estudando no VS-Code, quando uso o spotify e o vscode e chrome abertos ao mesmo tempo. Pode ser só falta de memória, mas como não observava isso no Windows com configuração inferior fiquei meio desconfiado. Mas isso é assunto para outro post. Vou ver se encontro algum tópico sobre este assunto. Senão eu mesmo abro.

1 curtida

Mint bugado como sempre :confused:

Oi pessoal, descobri uma coisa interessante hoje. Eu instalei o Linux mint xfce na partição sda5 há alguns dias para fins de teste e nenhuma vez ele deu esse bug de não terminar de desligar.

A situação estava assim
Sda1 uefi
Sda2 Linux mint cinnamon
Sda3 swap
Sda4 Home
Sda5 linux mint xfce

Então acho que a situação é a seguinte: O Linux mint instalado antes do swap deu o kernel panic. O instalado depois não deu o bug. Eu até reinstalei o xfce em sda2 e bugou de novo, confirmando minha teoria. Não sei se isso aconteceria em outras distros. Também não sei se os Linux atualmente ainda precisam da partição swap (Já li que um arquivo swap faria o mesmo papel) nem se é melhor manter o sistema na última partição por outros motivos além desse que citei. De qualquer forma achei interessante narrar este fato.

2 curtidas

https://forums.linuxmint.com/viewtopic.php?f=90&t=343364&p=2028392#p2028392

Estou com o mesmo problema. Hoje mais tarde tentarei usar o comando swapoff no finalrd.

Eu tenho novidades, mas pode muito bem ser apenas mais uma pista falsa. Andei tendo problemas recorrentes com o navegador Chrome, que vinha insistindo em travar a minha máquina ( 16 Gigabertos com 4 núcleos, então não é fácil travar a minha Valentine aqui ) e constatei que realmente limitar o Memlock ( limite máximo do cache de paginação ) resolve. Enviei a seguinte resposta ao Google : O Chrome tem criado paginações gigantescas que desrespeitam os limites de memória do sistema hospedeiro, e tem causado problemas de desligamento no Mint 20 e Ubuntu Focal Fossa; chega à dar a impressão que a opção perigosa --ulimit memlock=-1:-1 foi ativada, mas ninguém encontrou nada quanto à isso, mas limitar memlock via Ulimit tem resolvido, e o responsável obviamente só poderia ser o navegador : Limitar a paginação só funcionaria para navegadores ou para editores de imagem talvez ( gimp, photoshop, kolourpaint ), e não houve uso de editores de imagem na maioria das ocasiões. Algo da discussão pode ser vista em Kernel Panic ao Reiniciar/Desligar Linux Mint - #101 by chimpa_theist e a conclusão que o problema deve estar no Chrome é minha, até porque nem é a primeira vez que preciso usar o ulimit para conter os excessos do navegador. Até agora, fixar o limite rss em 10%, e empregar o magnificient suspender tem resolvido; porém as atualizações mais recentes parecem ter arranjado meios criativos de burlar os limites de administrador e abusar dos recursos da máquina.
Então proponho que todos digam se são usuários do Chrome também para podermos validar ou refutar a hipótese, e testar se o problema também ocorre com Firefox e Ópera.

Já tive esse problema.
e o que causava ele era o nouveau!
isso ainda no mint 19.
parece que isso é um problema recorrente no mint.

Não creio. Tem sido um problema recorrente na minha máquina, e ela nem tem placa de vídeo offboard, então o noveau nem é utilizado. Precisamos então testar em grupo para verificar, porque ficarmos apenas na opinião não resolve.

Sem querer jogar água fria no seu progresso, parceiro, mas uma característica recorrente desse problema é que ele não ocorre em instalações recentes, pode levar meses, mas depois que ocorre, só piora -- mas é comum que pequenas modificações na swap, como mudar o swapness ou instalar zram ou zswap produzam uma melhora temporária no problema, o que mais engana do que ajuda...

No item falhas oficiais do Linux Mint que o Chimp_theist citou, é interessante dizer que uma das falhas mais frequentes do Mint vem de pura falta de prioridade de processo. Muitos já tiveram problemas com a lentidão absurda do initramfs, toda vez que é feita uma instalação/atualização de qualquer dependência; e às vezes é preciso reinstalar várias vezes o sistema até chegar à uma instalação estável sem esse bug chato… Investigando esse bug, descobri 6 meses atrás que o problema era causado por pura falta de prioridade de processo para o initramfs. O htop me retornou SEMPRE prioridade +20 para ele, o que é absurdo, por se tratar de operação de root, potencialmente perigosa, que por simples questão de segurança devia exigir prioridade privilegiada ( PID negativo ). Vários fóruns reclamaram da lentidão, mas apontaram o problema como sendo por lentidão na descompressão e compressão do initramfs e propuzeram trocar a compressão lzop por gzip, o que até funciona, mas minha constatação é que a raiz do problema ( da descompressão/compressão do initrid e initramfs ) estava toda em prioridade de processo errada. Sendo a descompressão e recompressão processos filhos, é claro que herdar uma prioridade errada buga tudo e complica o resto que sobrar. Resolvi total o problema incluindo o comando “sudo nice -n -20 initramfs” no lançador de aplicações de arranque ( o startup applications ). Porém mais tarde notei lentidão no Nemo, coisa que muita gente mesmo reclama, inclusive com a observação que o Mint evoluiu muito, mas o Nemo não. Trava do nada frequentemente, basta ficar parado um pouco. Testei e vi que o problema era reparável mudando-se a prioridade do Nemo. Para cada vez que a gente diminui o PID pela metade, o late também cai pela metade. No fim, descobri que o problema era no comando mount : O Mint é miseravelemente lento para montar discos, partições, ou simples arquivos. Os logs mostram que ele fica montando e remontando ( mount e remount ) loucamente um monte de vezes, os discos, as partições, e até simples arquivos : Vc clica para abrir o arquivo, e o mount cai, e o sistema fica tentando remontá-lo – mas não espera a montagem, ele fica surtando e repetindo alucinado, unmount, mount, remount – o que é meio o que a galera acima notou algumas vezes, mas meio que deixou passar despercebido. Mas a maior parte da lentidão de inicialização vem justamente disso, ocorrer também no desligamento não me impressiona necas… Mas mudar a prioridade do Mount como fiz com o initramfs não funcionou… Não sei se o problema é de sintaxe, ou se a prioridade tem que ser mudada no processo pai, que não sei qual é. ( Mount é um comando; Initramfs é um processo. Não dá, lógico, para simplesmente mudar a prioridade de um comando, teria então que ser o nice do processo pai ) Mas eu queria investigar.

1 curtida

no meu caso era o nouveau
aparecia ate mensagens relacionada a ele na tela de kernel panic.

Belê, Talls-san, mas sua informação só vai ser realmente útil se voce tb informar se está usando placa de vídeo offboard e qual… E se vc estava usando o Virtualbox e o Chrome : Geralmente as placas ONBOARD não dão problema mesmo com o Noveau, aliás, nem mesmo com versões bugadas dele. Mas ainda assim, poderia ser problema de memória disponível, se o uso do driver estiver alocando muita memória. A questão é ingente, porque não podemos cada um ficar apontando uma causa diferente para o problema. Temos que buscar um denominador comum, e o mais provável até agora tem sido abuso do cache de paginação, ou abuso de consumo memória mesmo, pra simplificar. Nisso, cabe dizer que abuso do consumo de memória é um bug “clássico” do Noveau : Acontece com TODAS as versões bugadas dele. Mas também ocorre muito com bugs do Virtualbox e do Chrome. Por que ? No Virtualbox, a gente tem que reservar um certo número de núcleos para a execução… Até aí, tudo bem, mas ele compatibiliza mal o número de núcleos reservados com a memória, e aí fica paginando ( mandando para guardar no HD tudo o que não cabe na RAM ) que nem um alucinado.

1 curtida