Pedro !
Reparei que o teu sistema faz preparativos para hibernação. Isso fixa algumas páginas na memória, te deixando em uma situação mais delicada.
Eu te aconselho a mascarar o target de hibernação.
systemctl mask hibernate.target
Se quiser, pode mascarar o sleep e o suspend, também
systemctl mask sleep.target suspend.target
É provável que isso resolva o problema.
Vou rodar esses comandos no terminal e continuar testando pra ver se não dá mais kernel panic. Se funcionar eu aviso aqui 
Só uma atualização: eu vou ter que desfazer isso pro caso do suspend, porque eu estava usando o computador e, como de costume quando a bateria está em nível crítico, o gerenciador de energia tentou suspender, mas deu um erro de permissão negada e não fez nada. Eu vou precisar da suspensão nesse caso, porque se não ele simplesmente pode desligar e eu posso perder o que estiver fazendo.
Hmmm.
Ok.
O cara crítico é o hibernate
Para reabilitar o suspend é só desmascarar
systemctl unmask suspend.target
Eu tive que reabilitar o sleep também (via systemctl unmask sleep.target) , porque o sistema não tava conseguindo suspender. Mas o hibernate ainda deixei desabilitado como você disse. Já desliguei o computador algumas vezes e por enquanto nenhum kernel panic. Se acontecer de novo eu aviso aqui.
@chimpa_theist , infelizmente o kernel panic aconteceu mesmo desabilitando o hibernate…
Vou continuar testando desativar o swap antes de desligar, porque é outra coisa que também parecia estar funcionando. Mas vou precisar de um tempo pra conseguir dizer se isso resolve, porque esse erro acontece meio que só quando ele quer.
Kkkkk !
Só estamos esperando ele não querer.
Se ocorrer de novo, depois de dar boot, você bem que poderia sarvar as mensagens do journal com
journalctl -b -1 > journalsalvo.txt
Não vai ser tão grande quanto o anterior, por retratar apenas o último boot.
Aí, poderia disponibilizar pra eu dar outra olhada.
Eu estou tendo uns problemas técnicos com o pastebin.
Pastebin’s SMART filters have detected potentially offensive or questionable content in your paste.
The content you are trying to publish has been deemed potentially offensive or questionable by our filters, because of this you’re receiving this warning.
This paste can only be published with the visibility set to "Private".
Mas ele não habilita a opção Private pra mim.
EDIT:
Bom, achei um site aleatório aí: -- Logs begin at Thu 2020-12-17 21:32:12 -03, end at Tue 2021-01-19 21:37:52... - 42f14a69
Pedro.
Nessas vezes que o shutdown buga, antes de chegar nesse ponto não fica um tempo numa mensagem mais ou menos assim ?
[ * ] A stop job is running for Session c2 of user pedro
Cara, pior que isso parece familiar… Sabe aquela parte de cima, um pouco antes do kernel panic, com uma formatação toda esquisita? fica aparecendo aquilo ali durante algum tempo (é coisa de poucos segundos) antes de continuar o desligamento.
Por enquanto, sempre que usei esse comando antes de desligar não obtive o kernel panic. Mas eu reparei que as vezes ele é quase instantâneo, e as vezes ele demora um tempinho pra finalizar. Não sei se essa demora pode ter algo a ver.
É porque às vezes a swap area está limpa. Aí ele faz rapidão.
Quando a swap está relativamente cheia, ele tem que mapear todas as páginas para a memória. E ainda perde um tempo – quando não cabe tudo – matando processos. Nesses casos, demora mais um pouco.
Você poderia executar o comando ?
systemctl --version
Talvez a gente tenha que editar um arquivo.
Eu gosto de colocar a culpa no systemd! Então pra mim ele, na ânsia de fechar tudo correndo, fecha tudo errado mandando SIGKILL pra todo lado e acaba se atropelando inteiro.
O terminal retornou isso:
systemd 245 (245.4-4ubuntu3.3)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybridBom.
O que ocorreu no último journal que você mandou foi :
Meu problema agora, é a tua declaração de que a mensagem aparece apenas por poucos segundos.
Você confirma isso ?
Quando a mensagem aparece, ela mostra também dois números entre parêntesis. Dá tempo de ler esses números ?
Quando eu falei que fica por poucos segundos foi em relação a essa imagem. Até a parte do “Stop Network Time Service…” demora alguns segundos para as próximas linhas aparecerem. Aí quando chega em “Reached target Power-Off” ele tem um delayzinho também (as vezes desliga normal, ou como na imagem, dá o kernel panic).
Ahhh, sim.
Então, você não tem certeza de que a mensagem
[ * ] A stop job is running for Session c2 of user pedro (número/número)
aparece.
Você poderia confirmar se aparece ou não ?
Se ela aparecer, você poderia ver os números mostrados ?
De qualquer modo, vou ver uma solução paliativa, aqui.
Isso. Posso sim, vou ficar de olho.
Você pode também, por enquanto, tentar o seguinte paliativo
Crie o arquivo /lib/systemd/system/pedro_swapoff.service com o conteúdo
[Unit]
Description=PEDRO swapoff antes do shutdown
Before=shutdown.target
DefaultDependencies=No
[Service]
Type=oneshot
ExecStart=/usr/bin/swapoff -a
ExecStart=/usr/bin/logger "PEDRO swapoff emitido..."
TimeoutStartSec=0
TimeoutStopSec=20
[Install]
WantedBy=shutdown.target
Dá um reload
systemctl daemon-reload
e dá enable no service
systemctl enable pedro_swapoff
Agora, é ver se funciona.
De qualquer modo, você pode testar se o service ao menos rodou, dando um shutdown. Quando iniciar novamente, checar o journal com
journalctl -b -1 | grep PEDRO