Fedora 44 + NVIDIA GTX 1050: como resolver o erro “GPU not supported by open nvidia.ko” (GSP)

Introdução

Então, meu pinguim amigo, você acabou de atualizar seu Fedora 43 para 44 e está tudo lindo, aparentemente. Mas, do nada, você começa a ter algum desses problemas:

• Resolução estourada (tela com aspecto de baixa qualidade)
• Perda de performance gráfica (tudo travando ou lento)
• Monitor secundário que não liga ou fica com resolução incorreta
• Glitches, artefatos visuais ou tela piscando

Você resolve verificar se a sua f*** NVIDIA ainda está sendo reconhecida pelo novo kernel 7.x e, bazinga: quem está gerenciando tudo é o Nouveau (o driver open-source genérico).

Você pensa: “OK, vou reinstalar os drivers da NVIDIA”. Nada. “Vou forçar o blacklist do Nouveau”. Aí a coisa piora — você perde até a aceleração básica.

Calma. Pode ser que o seu caso seja como o meu: a mudança para módulos open por padrão (exigida a partir do kernel 6.12+ e adotada no Fedora 44) e a exigência do GSP (GPU System Processor) – um firmware presente apenas em GPUs RTX 20+ (arquitetura Turing) – são a causa raiz. No meu caso, uso uma velha GeForce GTX 1050 Ti (arquitetura Pascal), que não possui GSP.

Para ter certeza, vamos apenas identificar a arquitetura da sua GPU e confirmar o erro do GSP. Se for isso, siga a solução que funcionou para mim.

Diagnóstico rápido (antes de começar)

Execute no terminal:

lspci -nn | grep -i nvidia

Veja o PCI ID no final (ex: 10de:1c82). Depois consulte a arquitetura em PCI IDs da NVIDIA ou use:

sudo dmesg | grep -i "NVRM"

Se aparecer algo como:

NVRM: The NVIDIA GPU ... is not supported by open nvidia.ko because it does not include the required GPU System Processor (GSP).

Você confirmou: sua GPU é anterior à série RTX 20 e precisa do driver proprietário tradicional, não o módulo open.

Solução passo a passo (testada no Fedora 44, kernel 7.0.4)

1. Limpeza completa de pacotes NVIDIA conflitantes

Antes de instalar o driver correto, remova qualquer vestígio de versões anteriores.

# Remove todos os pacotes NVIDIA, mas mantém o firmware (necessário)
sudo dnf remove \*nvidia\* --exclude nvidia-gpu-firmware

# Remove arquivos órfãos de compilações antigas
sudo rm -rf /etc/pki/akmods
sudo rm -rf /var/cache/akmods
sudo rm -rf /usr/lib/modules/*/extra/nvidia

Nota: Se você estiver em um ambiente sem interface gráfica (apenas TTY), use Ctrl+Alt+F3 para abrir um terminal de texto e faça login normalmente.

2. Instalar o driver compatível com Pascal (GTX 1050 Ti)

O segredo está na versão 580xx – uma série mais antiga, porém estável, que ainda mantém suporte completo para Maxwell, Pascal e Volta.

sudo dnf install akmod-nvidia-580xx xorg-x11-drv-nvidia-580xx xorg-x11-drv-nvidia-580xx-cuda

3. Forçar a compilação do módulo do kernel

sudo akmods --force

Aguarde pacientemente. O processo pode levar alguns minutos. Para monitorar o progresso e garantir que não há erros, abra outro terminal (ou outra sessão TTY) e execute:

tail -f /var/log/akmods/akmods.log

Você verá linhas como Building RPM, Installing newly built rpms e finalmente Successful.

Comportamento interessante: Durante a compilação, assim que o módulo .ko fica pronto, o sistema pode carregá-lo dinamicamente com modprobe. Você pode perceber que o segundo monitor liga e a resolução volta ao normal antes mesmo do comando akmods --force terminar – isso é normal e indica que o driver já está funcionando.

4. Reconstruir a initramfs

Após o akmods --force terminar, recrie a imagem de inicialização para garantir que o sistema use o módulo correto desde o boot.

sudo dracut --force

5. Reiniciar

sudo reboot

Verificação pós-reboot

Depois de reiniciar, execute os seguintes comandos para confirmar que tudo está no lugar.

1. Módulo NVIDIA carregado:

   lsmod | grep nvidia

   Você deve ver várias linhas começando com nvidia, nvidia_drm, nvidia_modeset, etc.

2. Versão do driver instalado:

   nvidia-smi

   Exemplo de saída esperada:

   NVIDIA-SMI 580.159.03    Driver Version: 580.159.03    CUDA Version: 13.0
   
   

   E sua GPU GeForce GTX 1050 Ti listada.

3. Aceleração 3D funcionando:

   glxinfo | grep "OpenGL renderer"

   Deve mostrar algo como:

   OpenGL renderer string: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2

Proteção contra futuras atualizações

O akmod já recompila automaticamente o módulo quando um novo kernel é instalado. Porém, para garantir que nenhuma atualização futura force novamente a versão “open” do driver (incompatível com sua GPU), você pode fixar a versão do driver com o dnf versionlock:

sudo dnf versionlock add akmod-nvidia-580xx xorg-x11-drv-nvidia-580xx

Além disso, se um dia quiser desfazer o bloqueio e permitir atualizações normais basta usar:

sudo dnf versionlock clear

Comandos úteis para diagnóstico (se algo ainda não funcionar)

Aqui estão alguns comandos que ajudam a investigar problemas semelhantes em outras GPUs ou distribuições.

Dica de diagnóstico com IA:
Cole as saídas de dmesg | grep -i nvidia e cat /var/log/akmods/akmods.log em um chat com uma LLM (como o DeepSeek, que me ajudou), mas atenção: remova informações sensíveis (nomes de usuário, serial numbers, etc.) antes de compartilhar.

Conclusão

A solução apresentada é específica para GPUs NVIDIA anteriores à série RTX 20 (Maxwell, Pascal, Volta) no Fedora 44 (kernel 7.x). Se você tem uma placa mais nova (RTX 20, 30, 40), provavelmente o driver open padrão funcionará – mas aí você não estaria lendo este artigo.

Portanto, caso sua GPU seja de outra arquitetura (ex: Kepler, Fermi), você pode precisar de versões ainda mais antigas, como a 470xx ou 390xx. O princípio é o mesmo: identificar o driver correto através do site da NVIDIA ou de fóruns, instalar o akmod-<versão> correspondente e seguir os passos 3 a 5.

Mantenha a calma, leia os logs e não desista. Life long and Linux.

Agradecimentos

Agradecimento especial ao DeepSeek (a IA que me ajudou a estruturar o diagnóstico e a solução) e à comunidade do Fedora que mantém a documentação viva.

Se você achou este artigo útil, compartilhe com outros que sofrem com a mesma tela estourada. E lembre-se: toda atualização é uma aventura.

The post Sua placa NVIDIA parou no Fedora 44? first appeared on Coisa de Dev Academy.

Resumo

Após remover uma distribuição Linux ou substituir uma instalação anterior por Windows 11, é comum que entradas antigas de boot continuem aparecendo no menu UEFI da máquina.

Isso pode acontecer com distribuições como Pop!_OS, Ubuntu, Arch Linux, Fedora, Linux Mint e outras.

O motivo é simples: em sistemas UEFI, as informações de inicialização não ficam em apenas um lugar. Normalmente elas existem em dois pontos:

1. Partição do Sistema EFI, também conhecida como ESP.
2. Entradas de boot da NVRAM UEFI, armazenadas pelo firmware.

Para limpar corretamente entradas órfãs de boot, geralmente é necessário verificar os dois locais.

Atenção: antes de começar, faça backup dos seus dados. Modificar a partição EFI ou entradas da NVRAM pode tornar o sistema não inicializável se o procedimento for feito incorretamente.

Contexto técnico: onde ficam as entradas de boot?

Partição do Sistema EFI

A Partição do Sistema EFI é uma partição normalmente formatada em FAT32. Ela armazena os carregadores de boot dos sistemas operacionais instalados na máquina.

Uma estrutura comum pode ser parecida com esta:

EFI/
├── Microsoft/
├── Boot/
├── pop_os/
├── systemd/
├── ubuntu/
└── linux/

As pastas de distribuições Linux podem continuar ali mesmo depois que o sistema foi removido.

Nunca remova estas pastas se você quer manter o Windows funcionando:

• Microsoft/
• Boot/

Entradas de boot da NVRAM

Além dos arquivos presentes na partição EFI, o firmware UEFI também mantém entradas de boot em uma memória não volátil, chamada NVRAM.

Cada entrada pode conter:

• um identificador;
• uma descrição;
• o caminho para o carregador EFI;
• uma referência de dispositivo.

Por isso, remover apenas a pasta antiga da partição EFI nem sempre remove a opção do menu de boot. Em muitos casos, também é necessário remover a entrada órfã da NVRAM.

Passo 1 — Abrir o Prompt de Comando como administrador

No Windows 11, abra o menu Iniciar, pesquise por Prompt de Comando, clique com o botão direito e selecione Executar como administrador.

Em seguida, execute:

diskpart

Liste os discos disponíveis:

list disk

Selecione o disco principal do sistema. Na maioria dos casos será o disco 0:

select disk 0

Agora liste as partições:

list partition

Procure pela partição EFI. Ela costuma ter entre 100 MB e 500 MB e geralmente aparece como uma partição do tipo Sistema.

Atenção: confirme cuidadosamente o número do disco e da partição antes de continuar. O número pode variar de um computador para outro.

Passo 2 — Montar a partição EFI

Depois de identificar a partição EFI, selecione-a. Neste exemplo, vamos considerar que ela é a partição 1:

select partition 1

Atribua uma letra temporária para acessar a partição:

assign letter=Z

Saia do DiskPart:

exit

Agora a partição EFI deve estar acessível pela letra Z:.

Passo 3 — Verificar as pastas dentro da EFI

No Prompt de Comando, acesse a unidade recém-montada:

Z:

Entre na pasta EFI:

cd \EFI

Liste as pastas disponíveis:

dir

Você pode encontrar pastas como:

• Microsoft
• Boot
• ubuntu
• pop_os
• systemd

As pastas Microsoft e Boot devem ser preservadas.

Passo 4 — Remover arquivos antigos de boot do Linux

Se você encontrou pastas antigas de distribuições Linux que não usa mais, pode removê-las com cuidado.

Exemplo para remover uma pasta systemd:

rmdir /s /q systemd

Exemplo para remover uma pasta pop_os:

rmdir /s /q pop_os

Os parâmetros usados são:

• /s — remove diretórios e subdiretórios recursivamente;
• /q — executa em modo silencioso, sem pedir confirmação.

Atenção: remova apenas pastas que você tem certeza que pertencem a instalações Linux antigas. Não remova Microsoft nem Boot.

E se aparecer erro de permissão?

Em alguns casos, o Windows pode negar permissão para excluir uma pasta dentro da partição EFI.

Você pode assumir a propriedade da pasta com:

takeown /f systemd /r /d y

Em instalações do Windows em português, pode ser necessário usar /d s no lugar de /d y:

takeown /f systemd /r /d s

Depois conceda permissão total ao grupo de administradores:

icacls systemd /grant Administradores:F /t

Agora tente remover a pasta novamente:

rmdir /s /q systemd

Passo 5 — Listar entradas de boot da NVRAM

Depois de limpar a partição EFI, ainda pode ser necessário remover entradas antigas da NVRAM UEFI.

Para listar as entradas de firmware, execute:

bcdedit /enum firmware

Você verá uma saída parecida com esta:

Aplicativo de Firmware (101fffff)
---------------------------------
identificador           {29c75bf6-3303-11f1-b7f4-e7fe7d8485ec}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\systemd\systemd-bootx64.efi
description             Pop!_OS

Aplicativo de Firmware (101fffff)
---------------------------------
identificador           {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

Procure entradas que apontem para caminhos antigos, como:

• \EFI\systemd\
• \EFI\pop_os\
• \EFI\ubuntu\
• \EFI\linux\

Passo 6 — Remover uma entrada órfã de boot

Depois de identificar a entrada antiga, copie o identificador dela.

Exemplo:

{29c75bf6-3303-11f1-b7f4-e7fe7d8485ec}

Para remover a entrada, execute:

bcdedit /delete {29c75bf6-3303-11f1-b7f4-e7fe7d8485ec} /f

O parâmetro /f força a exclusão sem confirmação.

Nunca exclua estas entradas:

• {bootmgr}
• {current}

A entrada {bootmgr} normalmente representa o Windows Boot Manager. Apagar essa entrada pode impedir o Windows de inicializar corretamente.

Passo 7 — Remover a letra temporária da partição EFI

Depois de concluir a limpeza, remova a letra atribuída à partição EFI.

Abra novamente o DiskPart:

diskpart

Selecione o disco:

select disk 0

Selecione a partição EFI:

select partition 1

Remova a letra:

remove letter=Z

Saia do DiskPart:

exit

Solução de problemas

Acesso negado ao excluir uma pasta

Use os comandos de propriedade e permissão:

takeown /f systemd /r /d s
icacls systemd /grant Administradores:F /t
rmdir /s /q systemd

Falha ao excluir uma entrada com bcdedit

Possíveis causas:

• a entrada já foi removida;
• a entrada está protegida pelo firmware;
• o identificador foi copiado incorretamente;
• a referência é inválida.

Possíveis soluções:

• reinicie o sistema e tente novamente;
• remova primeiro os arquivos antigos da partição EFI;
• execute o Prompt de Comando como administrador;
• verifique novamente a saída de bcdedit /enum firmware.

A entrada ainda aparece no menu de boot

Isso pode acontecer por cache do firmware, fallback bootloader ou comportamento específico da BIOS/UEFI.

Possíveis soluções:

• reinicie o computador duas vezes;
• acesse a BIOS/UEFI e confira a ordem de boot;
• remova a entrada manualmente pelo setup da BIOS, se a opção existir;
• atualize a BIOS/UEFI, se necessário.

O Windows não inicializa depois do procedimento

Se algo der errado, use um pendrive de instalação do Windows.

1. Inicialize pelo pendrive.
2. Clique em Reparar o computador.
3. Acesse Solução de Problemas → Reparo de Inicialização.

Também é possível reconstruir o bootloader com:

bcdboot C:\Windows /s Z: /f UEFI

Atenção: esse comando exige que a partição EFI esteja montada novamente como Z:.

Comandos utilizados

Checklist rápido

• Backup realizado.
• Números de disco e partição conferidos.
• Partição EFI identificada corretamente.
• Pastas Microsoft e Boot preservadas.
• Entradas {bootmgr} e {current} não foram excluídas.
• Letra Z: removida ao final.

Ambiente testado

• Windows 11 24H2
• Firmware UEFI
• Disco GPT
• Pop!_OS com systemd-boot

Conclusão

Entradas órfãs de boot em sistemas UEFI são comuns depois de remover ou substituir uma instalação Linux. O motivo é que o processo de boot envolve tanto arquivos na partição EFI quanto registros mantidos pela NVRAM do firmware.

Por isso, a limpeza completa normalmente exige duas etapas: remover os arquivos antigos da partição EFI e apagar as entradas órfãs com bcdedit.

Com cuidado, backup e atenção aos identificadores corretos, é possível deixar o menu de boot limpo sem comprometer a inicialização do Windows.

Próximo passo

Se você usa dual boot, Linux, Windows e ferramentas de desenvolvimento no dia a dia, acompanhe a Coisa de Dev Academy. Aqui a ideia é aprender tecnologia com prática, contexto e explicações diretas ao ponto.

Referências técnicas

• Microsoft Docs — diskpart
• Microsoft Docs — bcdedit
• Microsoft Docs — takeown
• Microsoft Docs — icacls
• Microsoft Docs — rmdir
• Microsoft Docs — bcdboot

The post Como remover entradas de boot órfãs do Linux no Windows 11 UEFI first appeared on Coisa de Dev Academy.

Esse problema pode acontecer em diferentes distribuições, como Ubuntu, Linux Mint, Fedora, Big Linux e várias outras. Na maioria dos casos, ele não está ligado a um bug específico da distribuição, mas a uma diferença conceitual entre Windows e Linux na forma como cada sistema operacional interpreta o relógio de hardware do computador.

Neste artigo, você vai entender por que isso acontece, como Windows e Linux lidam de forma diferente com timezone e RTC, e qual é a solução mais recomendada do ponto de vista técnico.

O que é o RTC e qual seu papel no sistema?

Todo computador possui um RTC, sigla para Real-Time Clock. Ele também é conhecido como hardware clock.

Esse relógio é mantido pela bateria da placa-mãe e continua contando o tempo mesmo quando o computador está desligado. Ele fica armazenado no firmware, seja BIOS ou UEFI, e fornece a referência inicial de data e hora para o sistema operacional durante o boot.

O ponto crítico é que o RTC não armazena informação de timezone. Ele guarda apenas um valor bruto de data e hora.

A interpretação desse valor — se ele representa UTC ou horário local — é responsabilidade do sistema operacional.

É exatamente aqui que nasce o conflito entre Windows e Linux.

Como o Linux trata o horário e o timezone

Distribuições Linux e, de forma geral, sistemas Unix-like seguem uma abordagem historicamente consolidada para o controle de tempo.

No Linux, o RTC costuma ser tratado como estando em UTC, ou Coordinated Universal Time.

O sistema operacional aplica o offset de timezone em nível de software, utilizando bases como tzdata e serviços de sincronização via NTP, que também trabalham com UTC.

Na prática, o Linux lê o RTC como UTC durante a inicialização e converte esse valor para o horário local configurado no sistema.

Por exemplo, se o sistema estiver configurado para o horário de Brasília, o Linux aplica o offset correspondente ao fuso horário brasileiro e exibe a hora correta para o usuário.

Quando grava o horário de volta no hardware, ele mantém o padrão UTC.

Essa abordagem é robusta e faz bastante sentido em ambientes com múltiplos sistemas, servidores, mudanças frequentes de fuso horário e necessidade de sincronização precisa de tempo.

Como o Windows trata o horário do sistema

O Windows adota uma lógica diferente.

Por padrão, ele assume que o RTC está configurado em horário local. Isso significa que o valor lido do relógio de hardware já é considerado o horário final a ser exibido, sem uma conversão inicial de UTC para o fuso local.

Essa decisão tem raízes históricas, ligadas à compatibilidade com versões antigas do DOS e do próprio Windows, além de cenários onde apenas um sistema operacional é utilizado na máquina.

Quando o computador roda apenas Windows, isso geralmente não causa problema. O conflito aparece quando o Windows passa a dividir o mesmo hardware com um sistema que usa outra convenção.

Por que o relógio fica adiantado no dual boot Windows e Linux?

Em um sistema configurado para o fuso horário do Brasil, geralmente UTC−3, a sequência típica é a seguinte:

• O Linux inicia o sistema.
• Ele sincroniza o horário via NTP.
• Ele grava o horário correto em UTC no RTC.
• Depois, o computador é reiniciado.
• O Windows inicia e lê o RTC como se aquele valor estivesse em horário local.

Veja um exemplo prático:

• Horário real em Brasília: 15h
• UTC correspondente: 18h
• Linux grava 18h no RTC
• Windows lê 18h como horário local

O resultado é um relógio exibindo 3 horas a mais no Windows.

Não se trata de erro de sincronização, nem necessariamente de configuração incorreta de timezone. O problema nasce do conflito entre dois modelos diferentes de tratamento do tempo.

Pra facilitar, veja o infográfico a seguir:

Solução recomendada: configurar o Windows para usar UTC

Do ponto de vista técnico, a solução mais limpa é alinhar o Windows ao comportamento do Linux, fazendo com que ele passe a interpretar o RTC como UTC.

Isso pode ser feito por meio de uma configuração no Registro do Windows.

Como configurar o Windows para usar UTC

Abra o Editor do Registro do Windows com privilégios de administrador.

Para isso, pressione Win + R, digite:

regedit

Depois navegue até o caminho:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Dentro dessa chave, crie um novo valor do tipo DWORD (32 bits) com o nome:

RealTimeIsUniversal

Defina o valor como:

1

Depois disso, reinicie o computador.

Com essa configuração, o Windows passa a tratar o RTC como UTC e aplica corretamente o offset de timezone. Isso elimina o problema do relógio adiantado em dual boot.

Solução alternativa: configurar o Linux para usar horário local

Também é possível fazer o caminho inverso: configurar o Linux para tratar o RTC como horário local, seguindo o comportamento padrão do Windows.

O comando seria:

timedatectl set-local-rtc 1 --adjust-system-clock

Apesar de funcionar, essa abordagem não é a mais recomendada.

Ela vai contra o padrão adotado por sistemas Unix-like, pode causar inconsistências com sincronização via NTP e pode gerar problemas em mudanças de timezone ou horário de verão em alguns cenários.

Por isso, essa opção deve ser tratada como um workaround, não como a solução ideal.

Qual solução eu recomendo?

Se você usa dual boot com Windows e Linux, a melhor solução é configurar o Windows para interpretar o relógio de hardware como UTC.

Essa abordagem mantém o Linux dentro do padrão esperado, evita problemas com sincronização de tempo e deixa os dois sistemas trabalhando com a mesma lógica.

Em outras palavras: em vez de adaptar o Linux ao comportamento histórico do Windows, é mais consistente fazer o Windows trabalhar com UTC.

Conclusão

O relógio adiantado em sistemas dual boot não é exatamente um bug. Ele é consequência de decisões diferentes tomadas por Windows e Linux ao interpretar o relógio de hardware do computador.

O Linux trabalha com UTC no hardware e aplica o timezone em software. O Windows, por padrão, assume que o relógio de hardware já está em horário local.

Quando os dois sistemas dividem a mesma máquina, essa diferença pode fazer o relógio do Windows aparecer algumas horas adiantado ou atrasado.

Ajustar o Windows para usar UTC é a solução mais limpa, previsível e tecnicamente consistente.

Se você trabalha com Linux, dual boot, desenvolvimento ou manutenção de sistemas, entender esse detalhe ajuda a evitar um problema simples, mas bastante confuso para quem encontra isso pela primeira vez.

Próximo passo

Se você gosta de entender Linux de forma prática, sem decorar comandos soltos, acompanhe os conteúdos da Coisa de Dev Academy. A proposta é aprender tecnologia com exemplos reais, contexto e aplicação no dia a dia.

Referências técnicas

• Microsoft Documentation — Windows Time Service
• systemd Documentation — timedatectl
• Arch Linux Wiki — System time
• Ubuntu Documentation — Time and Date

The post Relógio adiantado no dual boot Windows e Linux: entenda o problema de timezone first appeared on Coisa de Dev Academy.