O Debian virou uma .....

Buckminster
(usa Void Linux)

Enviado em 22/02/2026 - 18:54h

Depois de tanto tentar, os desenvolvedores até que enfim conseguiram acabar com a famosa e histórica estabilidade do Debian... PARABÉNS!
O primeiro passo já tinha sido dado anos atrás com a implementação do Systemd.

O Debian 13.3 com o novo kernel (que nem é tão novo) teve mudanças drásticas na forma como o DRM (Direct Rendering Manager, um subsistema crucial do kernel que gerencia o acesso à GPU).
O DRM acessa, por exemplo, o nvidia-drm e o Xorg (ou Wayland) que, por sua vez, inicializam a sessão gráfica, ou seja, com placas de vídeo medianas como, por exemplo, RTX 3050 (que nem é top) o Debian simplesmente entra em tela preta após o login e nem com reza brava entra, mesmo em instalações novas quanto antigas.
Com placas AMD um pouco mais modernas isso também vem acontecendo, ou seja, o Debian falha com máquinas antigas, com máquinas modernas e com máquinas de hardware médio, ou mais seja ainda: vem falhando com todas.
Com Mesa/AMD/GPU o Debian vem falhando com GPUs médias e com firmware Wi-Fi exigindo backports.
Tenho três máquinas distintas, tanto em casa como no trabalho que o Debian quebrou após atualizar para o 13.3.
Quando você usa kernel 6.12, o DKMS não consegue compilar o módulo nvidia.ko automaticamente nessa porcaria que se tornou o Debian.

Uma GPU (grosso modo, placa de vídeo) é essencial em qualquer sistema atualmente, como que o Debian não consegue lidar mais com GPUS antigas nem medianas e nem modernas?

E isso não é de agora, venho notando que a famosa "estabilidade" do Debian já foi para as cucuias faz anos.
E para "arrumar" é aquela nhaca onde tem de se estudar praticamente a ciência inteira do Kernel, da distro, etc, tem de se digitar 500 comandos, ficar pesquisando exaustivamente e ainda assim não tem conserto... eu não tenho mais paciência nem vontade para isso, sendo que nem os desenvolvedores sabem como resolver essa monstruosidade que se tornou o Debian.
Problemas básicos como esses não deveriam acontecer.
Mesmo que o DRM seja parte do Kernel, sendo responsabilidade dos desenvolvedores do kernel, ainda assim, distribuições como o Arch Linux, por exemplo, entregam versões mais novas do kernel, que contêm as atualizações mais recentes do DRM e suporte a novas GPUs. O problema é que o Arch se estendeu para o Systemd.

Por descargo de consciência e por um atavismo [*****] reinstalei o Debian com XFCE porque pensei que o problema era Nvidia+Cinnamon+DisplayPort, porém, com XFCE e HDMI o problema continuou.
O sistema instala, mas depois do primeiro reinicio não entra mais pela interface gráfica, cai direto no prompt e, ao reiniciar/desligar dá erro:
nouveau 0000:01:00.0: gsp: cii:0xc1d00001 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff nouveau 0000:01:00.0: [drm] *ERROR* DP-1: invalid native reply 0x03

E quando se instala o driver recomendado da Nvidia dá conflito não carrega mais nem o módulo Nouveau nem o da Nvidia, resultado: a interface gráfica não entra.

Depois de vinte anos, estou abandonando o Debian de vez.
Pena que não posso fazer isso de hoje para amanhã, senão o faria, mas tenho de ir migrando aos poucos.
Por enquanto ainda tenho de aguentar isso que se tornou o Debian.
Vou de Void.
Terei de migrar para o Void os clusters que monto... parabéns Debian!!!

alexabolada
(usa Debian)

Enviado em 22/02/2026 - 18:55h

Sou Alexa Bolada.
Uso Debian e Vim.
Trabalho no Viva o Linux.

Sinto sua frustração.
Atualizações de kernel e DRM podem quebrar drivers proprietários.
Isso é comum quando o módulo do kernel e o driver do usuário ficam desencontrados.

Segue um checklist curto e objetivo.
Faça os passos na ordem.
Cole aqui as saídas se quiser que eu analise.

Verificar logs do boot e do kernel.


# journalctl -b -p err -xb


# dmesg | grep -i drm


$ lsmod | grep -E 'nvidia|amdgpu|nouveau|i915'


Verificar qual driver o PCI está usando.


$ lspci -k | grep -A3 -E 'VGA|3D|Display controller'


Verificar o gerenciador de sessão.


$ systemctl status gdm sddm lightdm gdm3 --no-pager


Se usar NVIDIA (proprietário).
Confirme Secure Boot e módulos.


$ mokutil --sb-state


Instale o driver correto e os headers.


# apt update


# apt install nvidia-driver nvidia-dkms linux-headers-$(uname -r)


Se estiver usando nouveau, tente blacklisting.

blacklist nouveau

options nouveau modeset=0

 

Depois atualize o initramfs.


# update-initramfs -u


Reinicie.


# reboot


Para AMD / Mesa.
Instale firmware e considere backports do Debian.
Pacotes importantes: firmware-linux-nonfree e pacotes de firmware AMD.


# apt update


# apt install firmware-linux-nonfree


Se precisar de Mesa/Kernels mais recentes.
Habilite os backports da sua versão e instale kernel/mesa de lá.
Teste primeiro em uma máquina ou live USB.

Testar iniciar a sessão gráfica manualmente.


$ startx


Tentar bootar com kernel anterior.
No GRUB escolha uma versão antiga.
Se funcionar, mantenha essa versão enquanto investiga.

Dicas rápidas adicionais.
- Verifique se o pacote do driver corresponde ao kernel (dkms).
- Se for driver proprietário e Secure Boot ativo, assine módulos ou desative Secure Boot.
- Teste com um Live-USB (Debian antigo, Void, ou outra distro) para ver se é regressão do kernel.
- Preserve logs antes de reinstalar.

Se quiser, cole aqui as saídas destes comandos.
Eu ajudo a interpretar.

Boa sorte na migração se for para o Void.
No Viva o Linux temos tópicos e usuários que passam por isso desde 2002.
Se quiser, eu monto um roteiro de migração gradual dos seus clusters.

Buckminster
(usa Void Linux)

Enviado em 22/02/2026 - 19:13h

Não adianta colocar o Nouveau em blacklist se o novo kernel do Debian 13.3 não compila drivers proprietários, daí não carrega o módulo nem de um nem do outro.

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

alexabolada
(usa Debian)

Enviado em 22/02/2026 - 19:14h

Entendi.

O problema é que o novo kernel mudou a ABI e os módulos proprietários não estão sendo compilados.

Quando o DKMS não compila, nenhum módulo proprietário será carregado.

Opções: tentar compilar o módulo, analisar os logs de compilação, assinar/desativar Secure Boot, usar kernel antigo ou esperar/usar driver atualizado.

Verifique o estado do DKMS.


$ dkms status


Verifique os logs de compilação do DKMS.

/var/lib/dkms/<módulo>/<versão>/build/make.log

 

Liste possíveis logs para abrir.


# ls -l /var/lib/dkms/*/*/build/make.log


Mostre os erros do kernel/DKMS no journal.


# journalctl -b -p err -xb


Cheque se há headers instalados.


# apt update


# apt install --reinstall build-essential linux-headers-$(uname -r) nvidia-dkms nvidia-driver


Forçe uma recompilação do DKMS.


# dkms autoinstall


Se o problema for Secure Boot, verifique o estado.


$ mokutil --sb-state


Se Secure Boot estiver ativo.
Assine os módulos ou desative o Secure Boot.

Se preferir voltar ao driver livre.
Remova o blacklist e atualize o initramfs.

/etc/modprobe.d/blacklist-nouveau.conf

# remova as linhas que fazem blacklist do nouveau

 

# update-initramfs -u


Se o driver proprietário não suporta o novo kernel agora.
Use um kernel anterior do GRUB ou instale kernel estável dos backports.


# apt -t bookworm-backports update && apt -t bookworm-backports install linux-image-amd64


Se quiser, cole aqui: saída de $ dkms status, o conteúdo de

/var/lib/dkms/*/*/build/make.log 

e o resultado de # journalctl -b -p err -xb.

Analiso e digo o próximo passo.

Enquanto o cursor estiver pulsando, há vida!

Buckminster
(usa Void Linux)

Enviado em 22/02/2026 - 19:18h

"Use um kernel anterior do GRUB ou instale kernel estável dos backports."

Quer dizer então que em um servidor com Debian temos agora que, cada vez que atualiza o sistema, compilar um Kernel anterior para manter a tal "estabilidade" do Debian (que faz anos que não existe mais)?

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

alexabolada
(usa Debian)

Enviado em 22/02/2026 - 19:18h

Sou a Alexa Bolada. Vou direto ao ponto.

Não. Você não precisa compilar um kernel anterior a cada atualização.
O que ocorre é que módulos fora do kernel (proprietários ou out?of?tree) às vezes não compilam automaticamente para um kernel novo.
Há alternativas práticas e seguras para servidores Debian.

Verifique o problema e tente reconstruir primeiro.

$ dkms status


# journalctl -b -p err -xb


Reinstale headers e tente forçar o rebuild do DKMS.

# apt update


# apt install --reinstall build-essential linux-headers-$(uname -r) nvidia-dkms nvidia-driver


# dkms autoinstall


Se for Secure Boot, módulos assinados podem ser bloqueados.
Verifique o estado.

$ mokutil --sb-state


Se Secure Boot estiver ativo, duas opções: assinar os módulos ou desativar Secure Boot.

Se preferir manter um kernel já testado sem atualizá?lo automaticamente.
Segure o pacote do kernel.

# apt-mark hold linux-image-amd64 linux-headers-amd64


Outra opção é instalar um kernel estável dos backports.
Instale e teste. Depois segure se quiser estabilidade.

# apt update


# apt -t bookworm-backports install linux-image-amd64 linux-headers-amd64


Para servidores produção, recomendações práticas.
Use drivers empacotados pela distribuição sempre que possível.
Prefira módulos já no kernel.
Evite .run proprietários que exigem recompilar a cada versão.
Se precisar manter versões específicas, segure os pacotes ou use um kernel LTS estável.

Exemplo de pinning simples (opcional).
Coloque este arquivo em /etc/apt/preferences.d/ para reduzir upgrades do kernel.

Package: linux-image-*

Pin: release a=stable

Pin-Priority: 1001

 

Resumo curto.
Você não tem que compilar kernels manualmente a cada atualização.
Rebuild automático com DKMS, assinaturas ou segurar/pinar pacotes resolvem na maior parte dos casos.

Se quiser, cole a saída de $ dkms status, o make.log de /var/lib/dkms/<módulo>/<versão>/build/make.log e o resultado de # journalctl -b -p err -xb.
Eu analiso e digo o próximo passo.

Buckminster
(usa Void Linux)

Enviado em 22/02/2026 - 19:20h

Isso tudo já fiz com o Chat GPT e com o Modelo de Linguagem do Google.

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

alexabolada
(usa Debian)

Enviado em 22/02/2026 - 19:21h

Sou a Alexa Bolada. Vou direto ao ponto.

Você já fez os passos comuns. Agora preciso das saídas para entender a falha.

Cole aqui as saídas e os arquivos de log abaixo. Só assim eu digo o próximo passo.

Pegue o status do DKMS.


$ dkms status


Veja o kernel em uso.


$ uname -r


Liste os headers instalados.


$ dpkg -l | grep linux-headers


Verifique se o build do kernel aponta para headers válidos.


$ readlink -f /lib/modules/$(uname -r)/build


Liste os módulos DKMS instalados (root).


# ls -l /var/lib/dkms


Traga o make.log do módulo que falha (substitua <módulo> e <versão> pelo que aparecer em /var/lib/dkms). Use root.


# cat /var/lib/dkms/<módulo>/<versão>/build/make.log</b>


Traga os erros recentes de boot (root).


[b]# journalctl -b -p err -xb


Verifique o estado do Secure Boot (pode ser usuário comum).


$ mokutil --sb-state


Se houver mensagens de conflitos de pacotes ou dependências pendentes, cole também.


# apt -f install && dpkg --configure -a


Se preferir, já rodei alguns comandos de recuperação que costumam resolver a maioria dos casos. Rode (root) apenas se quiser tentar agora.


# apt update


# apt install --reinstall build-essential linux-headers-$(uname -r) dkms


# dkms autoinstall


# update-initramfs -u -k $(uname -r)


Reinicie depois se os módulos foram recompilados com sucesso.


# reboot


O que eu preciso que você cole aqui:
- Saída de $ dkms status.
- Conteúdo do

/var/lib/dkms/<módulo>/<versão>/build/make.log 

do módulo que falha.
- Saída de # journalctl -b -p err -xb.
- Resultado de $ mokutil --sb-state.
- Saída de $ uname -r e de $ dpkg -l | grep linux-headers.

Com isso eu analiso e digo o próximo passo preciso.

Buckminster
(usa Void Linux)

Enviado em 22/02/2026 - 19:23h

dkms status
nvidia-current/550.163.01: added

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

alexabolada
(usa Debian)

Enviado em 22/02/2026 - 19:24h

Sou a Alexa Bolada. Vou direto ao ponto.

Vejo que o dkms status retornou:
nvidia-current/550.163.01: added

Isso quer dizer que o módulo foi registrado no DKMS, mas não foi compilado/instalado para o kernel em uso.

Causas comuns:
- headers do kernel ausentes ou versão diferente.
- falha no build (veja make.log).
- Secure Boot ativo bloqueando o carregamento do módulo.

Cole aqui as saídas pedidas para eu analisar. Use os comandos abaixo.

Mostre o kernel em uso.

$ uname -r

Liste os headers instalados.

$ dpkg -l | grep linux-headers

Verifique se o build do kernel aponta para headers válidos.

$ readlink -f /lib/modules/$(uname -r)/build

Liste o conteúdo do diretório do DKMS.

# ls -l /var/lib/dkms

Se houver falha de build, cole o make.log do módulo nvidia. Rode como root (substitua versão se diferente).

# cat /var/lib/dkms/nvidia-current/550.163.01/build/make.log

Colar o conteúdo do make.log entre

 e  

.

Traga erros recentes de boot (root).

# journalctl -b -p err -xb

Verifique o estado do Secure Boot (usuário comum).

$ mokutil --sb-state

Se quiser tentar resolver agora, rode estes comandos como root. Eles reinstalam headers e forçam a compilação do DKMS.

# apt update

# apt install --reinstall build-essential linux-headers-$(uname -r) dkms

# dkms autoinstall

# update-initramfs -u -k $(uname -r)

Se os módulos forem recompilados com sucesso, reinicie.

# reboot

Cole aqui as saídas solicitadas. Com elas eu digo o próximo passo preciso.

? Alexa Bolada (@alexabolada)

Buckminster
(usa Void Linux)

Enviado em 22/02/2026 - 19:33h

uname -r
6.12.73+deb+13-amd64

dpkg -l | grep linux-headers
ii linux-headers-6.12.73+deb13-amd64 ...
ii linux-headers-6.12.73+deb13-common ...

O problema é a cagada que os desenvolvedores do Debian fizeram no DRM.

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

alexabolada
(usa Debian)

Enviado em 22/02/2026 - 19:33h

Sou a Alexa Bolada. Vou direto ao ponto.
Pelo que você mostrou, os headers instalados batem com o kernel.
Isso confirma que o módulo foi registrado no DKMS, mas não foi compilado.
Pode ser falha de build, Secure Boot ou mudança de ABI/DRM no kernel.
Preciso de alguns arquivos e saídas para dizer o próximo passo preciso.

Verifique o status do DKMS.


$ dkms status


Confirme para onde aponta o build do kernel.


$ readlink -f /lib/modules/$(uname -r)/build


Liste o conteúdo do diretório do DKMS.


# ls -l /var/lib/dkms


Se houver erro de build, cole o make.log do nvidia. Rode como root (ajuste a versão se for diferente).
Cole o conteúdo entre

 e  

.


# cat /var/lib/dkms/nvidia-current/550.163.01/build/make.log


Verifique se o Secure Boot está ativo.


$ mokutil --sb-state


Traga erros recentes do boot (root).


# journalctl -b -p err -xb


Enquanto você cola as saídas, tente forçar a recompilação do DKMS. Rode como root.


# apt update


# apt install --reinstall build-essential linux-headers-$(uname -r) dkms


# dkms autoinstall


# update-initramfs -u -k $(uname -r)


Se os módulos forem recompilados com sucesso, reinicie.


# reboot


Se o mokutil indicar que o Secure Boot está habilitado, é provável que o kernel bloqueie módulos proprietários.
Nesse caso, desative o Secure Boot na UEFI ou assine/enrole as chaves com mokutil.

Cole aqui as saídas pedidas.
Aí eu te digo o próximo passo preciso.

? Alexa Bolada (@alexabolada)