Kernel Panic ao Reiniciar/Desligar Linux Mint

Comigo eu usei o 19.2 e 19.3, ambos com XFCE, pra mim foi uma das melhores experiências que tive com o Linux. Troquei pelo Xubuntu só pra experimentar, e fiquei por uns 6 meses, mas tinha uns bugs envolvendo a aceleração gráfica, que zuava as cores de alguns apps (dava pra resolver usando um comando na hora de lançar o app). Acabei voltando pro Mint, na versão 20, esperando que ia ter a mesma experiência que tive com os anteriores. Pra começar, eles desligaram o suporte de snaps, uma bela mancada (tive que habilitar manualmente), depois o bug da tela preta quando retorna de uma suspensão (dá pra digitar a senha e entrar na interface de volta mesmo com a tela preta, mas não deixa de ser irritante). E agora esse kernel panic. Pior que não escolhi o Mint atoa, é uma distro bem vista e considerada estável. Achei super estranho isso estar acontecendo.

1 curtida

Eu cheguei a usar todas essas distros que eu havia citado, mas o Linux Mint tem mesmo um diferencial. Espero que esses erro seja corrigido nas versões à frente. Gosto muito do Mint mas como tá, fica quase impossível de usar ele para trabalhar aqui.

1 curtida

Esse swapoff que deu erro aí, foi o emitido pelo próprio serviço de swap. Ele referencia especificamente o arquivo /swapfile que o nosso serviço sequer sabe que existe.

Você pode conferir dando duas vezes seguidas o comando

swapoff /swapfile

Na primeira, vai funcionar.
Na segunda, vai dar esse erro, porque o arquivo não está mais listado em

/proc/swaps

O problema nos dois logs que você mandou é que o sistema começa a fechar a session-c2.scope e 10 segundos depois, ele decide que não dá mais para esperar. Não vi onde configurar esse tempo, mas ainda estou me virando por aqui.

As mensagens no último log mostram bem essa situação. Às 19:05:15, ele sinaliza o fim da sessão. E às 19:05:25 ele sinaliza o time out.

jan 20 19:05:15 pedro-Aspire-E1-431 systemd-logind[892]: System is powering down.
jan 20 19:05:15 pedro-Aspire-E1-431 systemd[1]: Stopping Session c2 of user pedro.
: 
: 
jan 20 19:05:25 pedro-Aspire-E1-431 systemd[1]: session-c2.scope: Stopping timed out. Killing.
jan 20 19:05:25 pedro-Aspire-E1-431 systemd[1]: session-c2.scope: Killing process 1919 (rambox) with signal SIGKILL.
: 
Mais um monte de kill

No primeiro, a situação é bem semelhante. Muda só a hora e a ordem na qual os serviços vão terminando. Mas 10 segundos depois, começa o massacre.

O fato é. Não é exatamente a área de swap. Esta é devidamente desabilitada pelo sistema. E mesmo que não fosse, o serviço que criamos força que seja, ainda durante a vigência da sessão.

Mas alguma situação acontece quando você desabilita o swap antes de iniciar o shutdown. E isso resulta em um shutdown normal. Quer dizer, não sei se é normal. Talvez fosse interessante você disponibilizar um log com o shutdown que não dá problema, também.

Estou desconfiado do serviço bamfdaemon. Durante o shutdown, ele fica reiniciando repetidas vezes (talvez porque o bus que ele queria ativo tenha dançado, ou coisa parecida).

Para testar essa hipótese, você precisaria editar o arquivo

/usr/lib/systemd/user/bamfdaemon.service

e comentar a última linha, colocando um “jogo-da-velha” no começo. Ela ficaria assim.

#Restart=on-failure

EM RESUMO

  • Parece existir um tempo de 10 segundos (que pode ser fixo ou ter algum modo de alterar) para a sessão do usuário terminar.

  • Decorrido esse tempo, ocorre a matança indiscriminada dos processos relacionados à sessão.

  • De algum modo que não está claro, isso resulta em um kernel panic

E é isso que está acontecendo com o teu sistema.

O que você poderia fazer

  • disponibilizar um log de um shutdown normal
  • testar o RTA (digo, a gambiarra) sugerido para o serviço bamfdaemon

Como eu disse lááááá no início, só investigando. E isso toma tempo, mesmo.

1 curtida

Entendi. Vou desligar agora e disponibilizar um log de um shutdown normal.

EDIT:

Aqui está o log para um shutdown normal: -- Logs begin at Thu 2020-12-17 21:32:12 -03, end at Thu 2021-01-21 07:23:54... - 6cc09583

Acabei de fazer o RTA ( :joy: :joy:), qualquer novidade eu aviso.

Por incrível que pareça, o shutdown que termina normal não difere em nada do que termina bugado.

O time out ocorre da mesma maneira e a sequência de “Killing process …” também é executada.

O porquê de um resultar em kernel panic e outro não, é um mistério (por enquanto).

2 curtidas

Bom, mais uma vez deu kernel panic.

Log: The easiest way to host your text

Antes de eu criar o tópico aqui, eu andei lendo tópicos de pessoas que tiveram um problema parecido com o meu. Eu topei com um tópico que apresentou um kernel panic muito parecido com o meu: Linux Mint não desliga - #15 by Deleterium .

Aparentemente ele resolveu o problema desinstalando o prelink, preload e o virtualbox. Só não testei a solução dele no dia que vi, porque fiquei com a impressão de que ele havia instalado esses programas por conta própria. Mas hoje fui checar no apt e vi que esses mesmos programas estão instalados no meu sistema. Imagino que no meu caso o virtualbox não tenha culpa, pois instalei ele depois dos kernel panics começarem. Mas vou testar a solução que ele encontrou, de repente resolve.

EDIT:

Poxa vida, acho que me enganei… Eles não estão instalados não. Rodei o apt purge e não encontrou. Só o virtualbox, claro, mas esse eu tinha instalado.

Pesquisando aqui eu achei esse tópico no VOL, pelo que parece funcionou com o autor do tópico, não sei se ai vai resolver também:
Linux Mint xfce não desliga o notebook [RESOLVIDO] [Linux Mint] (vivaolinux.com.br)
[SOLVED] Kernel panic - not syncing (Linux Mint 15) - Linux Mint Forums

1 curtida

Antes de mais nada, pode voltar o bamfdaemon.service para sua definição original, retirando aquele #

Eu também reparei que a lista de processos que são “assassinados” é praticamente a mesma, nos vários logs que você disponibilizou.

Em um shutdown normal, o que acontece é que o systemd manda o sinal SIGTERM para os processos que ainda estão rodando. Cada um precisa receber esse sinal e terminar normalmente.

Depois de um tempo, o systemd perde a paciência e manda um SIGKILL para os processos que não terminaram da forma natural.

Talvez o problema seja um desses caras. A verdadade mesmo é que a gente sequer identificou a causa do problema.

Mas existem alguns testes que você pode fazer.

  1. testar shutdown sem ninguém logado

não dar o shutdown dentro da sessão. Ao contrário, fazer logoff e dar o shutdown na tela de login. A justificativa é que, provavelmente os processos ativos serão obrigados a terminar. Mesmo assim, pode ser que algum fique pendurado.

  1. definir mais detalhes no log

A gente pode descer um pouco o nível colocando a opção

systemd.log_level=debug

Lá nos parâmetros de boot. O journal vai ficar consideravelmente maior, uma vez que a gente vai ver o que o systemd está fazendo com mais detalhes.

  1. salvar lista de serviços ativos no shutdown

A gente pode criar o seguinte script no usuário pedro.

#!/bin/sh
systemd-cgls > /home/pedro/listadecgroups.txt

E salvá-lo como, por exemplo, pedro_cgls.sh

Tem que dar permissão para execução

chmod 755 pedro_cgls.sh

Láááá naquele serviço que a gente criou, mudar a linha

ExecStart=/usr/sbin/swapoff -a

para

ExecStart=/home/pedro/pedro_cgls.sh

No próximo boot, dar uma verificada no conteúdo do listadecgroups.txt.
Quem sabe assim a gente possa ter uma ideia de quais serviços ainda estão ativos antes do systemd usar sua bomba de nêutrons na galera.

1 curtida

Recomendo fazer um teste desses de cada vez.

1 curtida

Eu tô um tempo pra te perguntar.

Você instalou dos repositórios ou direto do site da Oracle ?

Foi dos repositórios.

O primeiro eu acho que não vai funcionar. Uma vez, pra testar, eu encerrei a sessão usando ctrl + alt + backspace e depois desligando pela tela de login, mas mesmo assim deu kernel panic.

Pedro.

Segundo esse post, o problema é com o Virtualbox.

https://forums.linuxmint.com/viewtopic.php?t=330316

This is not a Mint issue; it is a Virtualbox issue. Research your version of Virtualbox and see what issues others have run into and how they were addressed. If you need to complete work immediately then go back to LM19 until Oracle gets things fixed.

Apesar de que, quando ele instalou pelos repositórios, o usuário em questão deixou de ter problemas.

It seems the problem is fixed after doing as i described above, re-installing LM 20 and then installing Vbox from the repository instead of using the direct one from Oracle. Thank you all to have helped me try to fix and address this problem.

Mesmo assim, parece que existe algo errado com o Mint 20 e o Virtualbox.

Uma tentativa de identificar isso, seria trocando pelo virt-manager, que faz exatamente a mesma coisa que o Virtualbox.

Não me entenda mal. Não estou sugerindo que você use esse ou aquele pacote. Só estou sugerindo um teste. Que ao invés de usar o Virtualbox, você teste usar o virt-manager e veja se o problema persiste.

1 curtida

Olha, por precaução, eu dei apt purge no virtualbox. Eu tinha baixado pra tentar usar um sistema android e rodar alguns jogos, mas acabei nem usando por me convencer de que o desempenho em maquina virtual não seria satisfatório, então por enquanto eu acho que não deve fazer falta. Mas se eu precisar testar algum sistema em maquina virtual, eu baixo esse que vc indicou.

1 curtida

@Micco , eu tentei a solução encontrada nesse tópico, mas infelizmente aqui não deu certo. Acabou acontecendo outro kernel panic:

@chimpa_theist, eu não entendi direito como fazer aquele item 2 que você tinha falado, então fui pro item 3. Criei aquele script e rodei tanto em uma situação em que não ocorreu o kernel panic, quanto em uma que aconteceu.

Shutdown normal:

Control group /:
-.slice
├─user.slice 
│ └─user-1000.slice 
│   └─user@1000.service …
│     ├─gvfs-goa-volume-monitor.service 
│     │ └─2112 /usr/libexec/gvfs-goa-volume-monitor
│     ├─xdg-permission-store.service 
│     │ └─1964 /usr/libexec/xdg-permission-store
│     ├─xdg-document-portal.service 
│     │ └─1861 /usr/libexec/xdg-document-portal
│     ├─zeitgeist.service 
│     │ ├─1772 /usr/bin/zeitgeist-daemon
│     │ └─1954 zeitgeist-datahub
│     ├─evolution-calendar-factory.service 
│     │ └─4928 /usr/libexec/evolution-calendar-factory
│     ├─pulseaudio.service 
│     │ └─1297 /usr/bin/pulseaudio --daemonize=no --log-target=journal
│     ├─gvfs-daemon.service 
│     │ ├─1422 /usr/libexec/gvfsd
│     │ ├─1427 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
│     │ └─3056 /usr/libexec/gvfsd-trash --spawner :1.13 /org/gtk/gvfs/exec_spaw…
│     ├─evolution-source-registry.service 
│     │ └─3804 /usr/libexec/evolution-source-registry
│     ├─gvfs-udisks2-volume-monitor.service 
│     │ └─2083 /usr/libexec/gvfs-udisks2-volume-monitor
│     ├─init.scope 
│     │ ├─1285 /lib/systemd/systemd --user
│     │ └─1289 (sd-pam)
│     ├─gpg-agent.service 
│     │ └─1417 /usr/bin/gpg-agent --supervised
│     ├─zeitgeist-fts.service 
│     │ └─1965 /usr/lib/zeitgeist/zeitgeist-fts
│     ├─gvfs-gphoto2-volume-monitor.service 
│     │ └─2119 /usr/libexec/gvfs-gphoto2-volume-monitor
│     ├─at-spi-dbus-bus.service 
│     │ ├─1396 /usr/libexec/at-spi-bus-launcher
│     │ └─1401 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/a…
│     ├─dbus.service 
│     │ ├─1305 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nop…
│     │ ├─1405 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
│     │ └─1647 /usr/libexec/dconf-service
│     ├─bamfdaemon.service 
│     │ └─29166 /usr/lib/x86_64-linux-gnu/bamf/bamfdaemon
│     ├─evolution-addressbook-factory.service 
│     │ └─5419 /usr/libexec/evolution-addressbook-factory
│     ├─gvfs-mtp-volume-monitor.service 
│     │ └─2105 /usr/libexec/gvfs-mtp-volume-monitor
│     └─gvfs-afc-volume-monitor.service 
│       └─2099 /usr/libexec/gvfs-afc-volume-monitor
├─init.scope 
│ ├─    1 /sbin/init
│ └─29127 (sd-sync)
└─system.slice 
  ├─systemd-udevd.service 
  │ ├─  420 /lib/systemd/systemd-udevd
  │ ├─29129 /lib/systemd/systemd-udevd
  │ ├─29131 /lib/systemd/systemd-udevd
  │ ├─29132 /lib/systemd/systemd-udevd
  │ ├─29133 /lib/systemd/systemd-udevd
  │ ├─29138 /lib/systemd/systemd-udevd
  │ ├─29139 /lib/systemd/systemd-udevd
  │ ├─29142 /lib/systemd/systemd-udevd
  │ ├─29143 /lib/systemd/systemd-udevd
  │ ├─29144 /lib/systemd/systemd-udevd
  │ ├─29146 /lib/systemd/systemd-udevd
  │ ├─29147 /lib/systemd/systemd-udevd
  │ ├─29148 /lib/systemd/systemd-udevd
  │ ├─29149 /lib/systemd/systemd-udevd
  │ ├─29150 /lib/systemd/systemd-udevd
  │ ├─29155 /lib/systemd/systemd-udevd
  │ ├─29161 /lib/systemd/systemd-udevd
  │ ├─29162 /lib/systemd/systemd-udevd
  │ ├─29163 /lib/systemd/systemd-udevd
  │ ├─29164 /lib/systemd/systemd-udevd
  │ └─29165 /lib/systemd/systemd-udevd
  ├─finalrd.service 
  │ ├─29134 /bin/sh /usr/bin/finalrd
  │ └─29329 [systemd-tmpfile]
  ├─wpa_supplicant.service 
  │ └─884 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
  ├─lightdm.service 
  │ ├─966 /usr/sbin/lightdm
  │ └─997 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:…
  ├─pedro_swapoff.service 
  │ ├─29140 /bin/sh /home/pedro/pedro_cgls.sh
  │ └─29175 systemd-cgls
  ├─systemd-journald.service 
  │ └─365 /lib/systemd/systemd-journald
  ├─hddtemp.service 
  │ ├─29137 /bin/sh /etc/init.d/hddtemp stop
  │ └─29202 systemctl -p LoadState --value show hddtemp.service
  ├─NetworkManager.service 
  │ └─848 /usr/sbin/NetworkManager --no-daemon
  ├─systemd-random-seed.service 
  │ └─29145 /lib/systemd/systemd-random-seed save
  ├─blk-availability.service 
  │ ├─29130 /bin/bash /sbin/blkdeactivate -u -l wholevg -m disablequeueing -r w…
  │ ├─29204 /bin/umount --help
  │ └─29205 grep -- --all-targets
  ├─grub-common.service 
  │ ├─29135 /bin/sh /etc/init.d/grub-common stop
  │ └─29201 systemctl -p LoadState --value show grub-common.service
  ├─ubuntu-system-adjustments.service 
  │ ├─29151 /usr/bin/python3 /usr/share/ubuntu-system-adjustments/systemd/stop
  │ └─29203 /usr/bin/python3 /usr/share/ubuntu-system-adjustments/systemd/adjus…
  ├─cups.service 
  │ └─846 /usr/sbin/cupsd -l
  ├─systemd-resolved.service 
  │ └─749 /lib/systemd/systemd-resolved
  ├─dbus.service 
  │ └─847 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile…
  └─systemd-logind.service 
    └─880 /lib/systemd/systemd-logind

Shutdown bugado:

Control group /:
-.slice
├─user.slice 
│ └─user-1000.slice 
│   ├─user@1000.service …
│   │ ├─gvfs-goa-volume-monitor.service 
│   │ │ └─2097 /usr/libexec/gvfs-goa-volume-monitor
│   │ ├─xdg-permission-store.service 
│   │ │ └─1923 /usr/libexec/xdg-permission-store
│   │ ├─xdg-document-portal.service 
│   │ │ └─1875 /usr/libexec/xdg-document-portal
│   │ ├─zeitgeist.service 
│   │ │ └─1913 /usr/bin/zeitgeist-daemon
│   │ ├─evolution-calendar-factory.service 
│   │ │ └─4336 /usr/libexec/evolution-calendar-factory
│   │ ├─pulseaudio.service 
│   │ │ └─1310 /usr/bin/pulseaudio --daemonize=no --log-target=journal
│   │ ├─gvfs-daemon.service 
│   │ │ ├─1436 /usr/libexec/gvfsd
│   │ │ ├─1441 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
│   │ │ └─3188 /usr/libexec/gvfsd-trash --spawner :1.13 /org/gtk/gvfs/exec_spaw…
│   │ ├─evolution-source-registry.service 
│   │ │ └─3482 /usr/libexec/evolution-source-registry
│   │ ├─gvfs-udisks2-volume-monitor.service 
│   │ │ └─2071 /usr/libexec/gvfs-udisks2-volume-monitor
│   │ ├─init.scope 
│   │ │ ├─1301 /lib/systemd/systemd --user
│   │ │ └─1302 (sd-pam)
│   │ ├─gpg-agent.service 
│   │ │ └─1431 /usr/bin/gpg-agent --supervised
│   │ ├─zeitgeist-fts.service 
│   │ │ └─2039 /usr/lib/zeitgeist/zeitgeist-fts
│   │ ├─gvfs-gphoto2-volume-monitor.service 
│   │ │ └─2131 /usr/libexec/gvfs-gphoto2-volume-monitor
│   │ ├─at-spi-dbus-bus.service 
│   │ │ ├─1410 /usr/libexec/at-spi-bus-launcher
│   │ │ └─1415 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/a…
│   │ ├─dbus.service 
│   │ │ ├─  1317 /usr/bin/dbus-daemon --session --address=systemd: --nofork --n…
│   │ │ ├─  1419 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
│   │ │ ├─  1818 /usr/libexec/dconf-service
│   │ │ ├─175115 /usr/bin/gnome-keyring-daemon --start --foreground --component…
│   │ │ └─300204 /usr/bin/snap userd
│   │ ├─bamfdaemon.service 
│   │ │ └─309580 /usr/lib/x86_64-linux-gnu/bamf/bamfdaemon
│   │ ├─evolution-addressbook-factory.service 
│   │ │ └─4650 /usr/libexec/evolution-addressbook-factory
│   │ ├─gvfs-mtp-volume-monitor.service 
│   │ │ └─2092 /usr/libexec/gvfs-mtp-volume-monitor
│   │ └─gvfs-afc-volume-monitor.service 
│   │   └─2084 /usr/libexec/gvfs-afc-volume-monitor
│   └─session-c2.scope 
│     └─1805 /snap/rambox/16/rambox --no-sandbox
├─init.scope 
│ └─1 /sbin/init
└─system.slice 
  ├─systemd-udevd.service 
  │ ├─   425 /lib/systemd/systemd-udevd
  │ ├─309546 /lib/systemd/systemd-udevd
  │ ├─309547 /lib/systemd/systemd-udevd
  │ ├─309548 /lib/systemd/systemd-udevd
  │ ├─309549 /lib/systemd/systemd-udevd
  │ ├─309550 /lib/systemd/systemd-udevd
  │ ├─309551 /lib/systemd/systemd-udevd
  │ ├─309552 /lib/systemd/systemd-udevd
  │ ├─309553 /lib/systemd/systemd-udevd
  │ ├─309554 /lib/systemd/systemd-udevd
  │ ├─309555 /lib/systemd/systemd-udevd
  │ ├─309556 /lib/systemd/systemd-udevd
  │ ├─309557 /lib/systemd/systemd-udevd
  │ ├─309558 /lib/systemd/systemd-udevd
  │ ├─309559 /lib/systemd/systemd-udevd
  │ ├─309560 /lib/systemd/systemd-udevd
  │ ├─309561 /lib/systemd/systemd-udevd
  │ ├─309562 /lib/systemd/systemd-udevd
  │ ├─309563 /lib/systemd/systemd-udevd
  │ ├─309564 /lib/systemd/systemd-udevd
  │ └─309565 /lib/systemd/systemd-udevd
  ├─finalrd.service 
  │ ├─309528 /bin/sh /usr/bin/finalrd
  │ └─309739 systemd-tmpfiles --create /usr/lib/finalrd/finalrd-static.conf /ru…
  ├─wpa_supplicant.service 
  │ └─889 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
  ├─lightdm.service 
  │ ├─1006 /usr/sbin/lightdm
  │ └─1036 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/…
  ├─pedro_swapoff.service 
  │ ├─309532 /bin/sh /home/pedro/pedro_cgls.sh
  │ └─309584 systemd-cgls
  ├─systemd-journald.service 
  │ └─366 /lib/systemd/systemd-journald
  ├─NetworkManager.service 
  │ └─866 /usr/sbin/NetworkManager --no-daemon
  ├─systemd-random-seed.service 
  │ └─309544 /lib/systemd/systemd-random-seed save
  ├─ubuntu-system-adjustments.service 
  │ └─309545 /usr/bin/python3 /usr/share/ubuntu-system-adjustments/systemd/stop
  ├─cups-browsed.service 
  │ └─953 /usr/sbin/cups-browsed
  ├─cups.service 
  │ ├─ 864 /usr/sbin/cupsd -l
  │ ├─1031 /usr/lib/cups/notifier/dbus dbus://
  │ └─1032 /usr/lib/cups/notifier/dbus dbus://
  ├─systemd-resolved.service 
  │ └─765 /lib/systemd/systemd-resolved
  ├─udisks2.service 
  │ └─888 /usr/lib/udisks2/udisksd
  ├─dbus.service 
  │ └─865 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile…
  ├─avahi-daemon.service 
  │ ├─862 avahi-daemon: running [pedro-Aspire-E1-431.local]
  │ └─917 avahi-daemon: chroot helper
  └─systemd-logind.service 
    └─885 /lib/systemd/systemd-logind

Eita que ontem até sonhei com esse bug (kkkkk) !

Sobre o post do @Micco, você deu boot pelo pen, passou um fsck no disco e a operação terminou sem nenhum erro reportado, foi isso ?

Bom. A lista de control groups, no final, não ajudou muito. É que a sessão que eu estava interessado já tinha morrido.

E no que diz respeito ao segundo ítem, é o seguinte.

  • editar o /etc/default/grub
  • na linha que tem
    GRUB_CMDLINE_LINUX_DEFAULT="xxx yyy"
    colocar
    GRUB_CMDLINE_LINUX_DEFAULT="xxx yyy systemd.log_level=debug"
    e depois executar sudo update-grub

onde “xxx yyy” é qualquer coisa que tenha lá.

Isso vai gerar um log relativamente maior. Assim que der o bug, disponibiliza o log e pode desfazer a mudança.

1 curtida

Ainda sobre a lista de cgroups.

Na verdade, no shutdown que deu bug, ficou o rambox pendurado na c2. Já no shutodwn que não deu bug, a c2 tinha morrido.

1 curtida

Sim, eu rodei o fsck e terminou sem erros. Agora que você falou do rambox, estou começando a suspeitar dos snaps. Isso porque eu instalei o rambox depois de começar os kernel panics, mas o snap eu creio que tenha sido antes. Talvez qualquer programa que rode via snap seja um possível culpado.

Vou fazer aquilo que vc falou no segundo item e assim que der o bug eu volto com o log.

1 curtida

Vc ainda vai descobrir a causa do bug e ganhar uma medalhinha da galera do Mint!

kkkk !

Eu até instalei o Mint numa vm aqui na esperança de reproduzir o comportamento. Habilitei o snap, instalei o rambox, e até o VirtualBox.

Mas, infelizmente, todos os shutdowns terminam normalmente.

Isso me faz duvidar que seja o Mint em si.

Mas, aproveitando o ensejo, ei @Pedroh99 ! Qual kernel você tá usando ?

uname -r