Registro do 'last" errado [RESOLVIDO]

ruanelivelton18
(usa Arch Linux)

Enviado em 31/12/2025 - 18:29h

Ola pessoal!
To com o Debian 13 aq e não consigo monitorar as entradas e saidas do sistema, no last entra registros de 'crash' sem ter realmente um 'crash'
Sera mais uma falha que passou batido novamente? existe solução? ou so aceitar kkkkkk
Ex:

Buckminster
(usa Debian)

Enviado em 31/12/2025 - 18:47h

Verifique os logs!

Para procurar mensagens de erro ou pânico de kernel no momento do suposto "crash", procure as últimas entradas antes do novo boot:
$ journalctl -k -b -1 -r

Para ver logs de inicialização:
$ journalctl -b -1

Últimos boots:
$ journalctl --list-boots

Verifique com o dmesg também:
$ dmesg | grep -i error
$ dmesg | grep -i warning

Pode não ser um crash. Geralmente quando o sistema é desligado incorretamente o registro de logout estará para as sessões ativas fazendo o last registrar a entrada como "crash" (falha) porque a sessão não foi encerrada de forma limpa.
Verifique os logs.

_________________________________________________________
Rule number one: Always listen 'to' Buck!
Enquanto o cursor estiver pulsando, há vida!

ruanelivelton18
(usa Arch Linux)

Enviado em 31/12/2025 - 19:36h

O porem e que ta meio exclusivo so ao Debian, ja testei outras e as entradas ocorrem normalmente. Tenho essa G210 nessa maquina separada mas sem ela o registro mostra o 'crash' por igual.
Cheguei a conferir e não vi algo proximo de panic ou falha de interrupção, mas vou deixar as colas kkkk vai que eu não to enxergando
https://pastebin.com/ksuzuFn0
https://pastebin.com/1S3MWk9w
https://pastebin.com/APfKTwhM
https://pastebin.com/08yVeGac
https://pastebin.com/NkPtT248

ruanelivelton18
(usa Arch Linux)

Enviado em 31/12/2025 - 21:20h

Bizarro, aq já entrei até no celular e mostra normal o pastebin, será que o DNS aí não tá bloqueando? Ou até no hosts?

Buckminster
(usa Debian)

Enviado em 31/12/2025 - 21:33h

Só se o provedor (Nio Fibra) está bloqueando o pastebin, mas não vejo porque.
No celular pelo wifi também dá a mesma coisa.

Encontrei aqui:
https://tecnoblog.net/comunidade/t/pastebin-bloqueado-na-oi-fibra-ou-o-contrario/21077

Pelo visto a Nio Fibra (antiga Oi) bloqueia o pastebin, mas não se sabe o porquê.


_________________________________________________________
Rule number one: Always listen 'to' Buck!
Enquanto o cursor estiver pulsando, há vida!

ruanelivelton18
(usa Arch Linux)

Enviado em 31/12/2025 - 21:40h

Ve se agora da!
https://hastebin.com/share/esadoneqox.yaml
https://hastebin.com/share/zasixewove.yaml
https://hastebin.com/share/owanofecis.yaml
https://hastebin.com/share/acabogodeh.lua
https://hastebin.com/share/cudurujere.python

ruanelivelton18
(usa Arch Linux)

Enviado em 31/12/2025 - 21:45h

ixi, então vai ficar ruim de filtrar as 'reais' quedas ou de energia ou algum reinicio inesperado, o foda e que o Ubuntu so da pra testar na hora que sair a proxima LTS ja que a atual não ta com o novo wtmp, fora que andei observando vi o mesmo problema no sddm quando uso com KDE(as vezes reinstalo tudo novamente com outro ambiente)

Buckminster
(usa Debian)

Enviado em 31/12/2025 - 21:46h

Agora foi.
Estou vendo.

Encontrei aqui:
https://tecnoblog.net/comunidade/t/pastebin-bloqueado-na-oi-fibra-ou-o-contrario/21077

Pelo visto a Nio Fibra (antiga Oi) bloqueia o pastebin, mas não se sabe o porquê.

No primeiro link do hastebin tem no final:

dez 31 17:24:19 desktop kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.12.57+deb13-amd64 root=UUID=8498b859-3525-4c86-8d1b-86dc6bfe49f1 ro quiet mitigations=off
dez 31 17:24:19 desktop kernel: Linux version 6.12.57+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binu>
lines 811-849/849 (END)

Com mitigations=off o sistema fica mais rápido, mas fica mais vulnerável a ataques que exploram falhas do processador.
Caso for um servidor, sistema multiusuário, ambiente corporativo, máquina que roda código não confiável (VMs, containers, usuários externos), etc, aconselho a tirar mitigations=off.
Isso pode dar uma falha de segurança.

E joguei o link do log no Chat "Jarvis" GPT (para isso ele é excelente):

"O que aparece e pode ser só benign warnings
nouveau ... trapped read/write ...

Várias linhas do driver de vídeo nouveau repetindo:

nouveau 0000:01:00.0: fb: trapped read ...
gr: TRAP_PROP ...

Isso indica que o driver gráfico tentou acessar a GPU de forma irregular, geralmente por causa de:
driver experimental ou instável
falta de firmware específico
incompatibilidade com sua GPU
Por si só não é necessariamente um crash do kernel, é mais um warning/error do driver gráfico.

Esse tipo de mensagem normalmente não faz o sistema travar, ele apenas registra essas exceções."

Jogue os outros links dos logs nele e peça para ele analisar se tem algum crash ou kernel panic.

Sobre essa mensagem específica (error -2)

error -2 normalmente significa “arquivo não encontrado”

O driver tentou carregar o firmware nva8_fuc084* e não achou

Você pode instalar o pacote de firmware relacionado (firmware-misc-nonfree) se quiser tentar resolver isso — mas isso é opcional e não é um crash.

_________________________________________________________
Rule number one: Always listen 'to' Buck!
Enquanto o cursor estiver pulsando, há vida!

ruanelivelton18
(usa Arch Linux)

Enviado em 31/12/2025 - 22:18h

Sabia que vc iria reparar na flag do grub kkkkk infelizmente acostumei pq da uma diferença de desempenho, e uma maquina que fica mais de lado aq servindo de NAS ou um backup mas sobre a NVIDIA ja veio com o pacote instalado mas parece que o modulo divide com outros, mas pelo menos deu pra ver que infelizmente trocaram um modelo que tava funcionam bem pra um banco de dados SQL que mal consegue pegar uma saida corretamente... E olha que o problema so vai aparecer em 2038... uma troca precoce infelizmente.