Instalação

[Rafael Abreu]

Olá, pessoal.
Estou precisando de ajuda para conseguir instalar o Linux no meu notebook e já esgotei todas as alternativas que conheço.
Tenho um Dell Vostro 3515 (Processador AMD Ryzen com gráficos integrados Radeon) e não consigo dar boot em nenhum instalador Linux.
Já testei o Ubuntu, Linux Mint e Pop!_OS, e o comportamento é sempre o mesmo: eu seleciono a opção de instalar/testar no menu de boot, a tela pisca e o sistema simplesmente reinicia ou volta para a tela de seleção inicial, sem carregar a interface gráfica. Tudo o que é padrão de configuração já foi feito na BIOS e na criação das mídias:BIOS / UEFI: Secure Boot desativado, Fast Boot desativado e o armazenamento alterado de RAID para AHCI.
Mídias de Instalação: Criei os pen drives usando o Ventoy (tanto MBR quanto GPT), o Rufus (em modo GPT/UEFI e testando também o modo de gravação DD), e o BalenaEtcher. O pen drive é reconhecido perfeitamente no menu de boot do F12 da Dell.
Parâmetros de kernel: Tentei editar o Grub e adicionar o parâmetro nomodeset ao final da linha do Linux, mas o comportamento de reiniciar ou resetar continua.
Parece ser alguma incompatibilidade crônica desse hardware da Dell (controladora de vídeo AMD ou gerenciamento ACPI da placa) com o kernel do instalador.
Alguém que tenha esse mesmo modelo ou que já passou por esse problema em notebooks Dell Ryzen recentes saberia me dizer se existe algum outro parâmetro de boot específico (como acpi=off, pci=noaer, etc.) ou alguma pegadinha na BIOS desse Vostro que resolva isso?

[galactus]

O comportamento descrito não aponta necessariamente para uma incompatibilidade crônica da GPU AMD. Como o equipamento chega ao menu do instalador e reinicia logo depois que o kernel começa a carregar, é necessário separar quatro possibilidades: firmware, hardware, mídia de instalação e parâmetros de inicialização.

O primeiro passo seria verificar a versão do BIOS. A Dell disponibilizou atualizações importantes para o Inspiron/Vostro 3515, incluindo a versão 1.30.0, publicada em março de 2025. Recomendo consultar a página do equipamento usando a etiqueta de serviço, atualizar o BIOS caso exista uma versão mais recente e, depois, carregar os padrões de fábrica do BIOS.

Após restaurar os padrões, configure novamente:

* Boot Mode: UEFI;
* SATA Operation: AHCI;
* Secure Boot: Disabled;
* Fast Boot: Disabled ou Thorough;
* Legacy Option ROMs: Disabled.

Antes de testar novamente o Linux, execute também o diagnóstico da Dell pelo menu F12 → Diagnostics. Faça o teste completo da memória, SSD/NVMe, processador, vídeo e placa-mãe. Uma falha de memória, armazenamento ou alimentação também pode provocar reinicialização durante o carregamento do kernel.

Para eliminar problemas relacionados à mídia, eu faria um novo teste sem Ventoy. Baixaria uma imagem oficial recente, validaria o SHA256 e a gravaria diretamente em outro pen drive usando Rufus em modo DD ou Balena Etcher. Também testaria outra porta USB. Preferencialmente, usaria uma versão atual do Ubuntu, pois ela contém um kernel e firmwares AMD mais recentes.

No menu de inicialização, pressione "e" sobre "Try or Install Ubuntu", remova:

quiet splash

e tente primeiro:

nomodeset

O objetivo de retirar "quiet splash" é visualizar as mensagens reais do kernel. Como o reinício pode ser muito rápido, vale filmar a tela para identificar a última mensagem exibida.

Também é importante testar sem subir a interface gráfica. Para isso, use:

nomodeset systemd.unit=multi-user.target

Se o notebook reiniciar mesmo tentando entrar somente em modo texto, o problema provavelmente não está restrito ao driver gráfico AMDGPU.

Depois, teste os seguintes parâmetros, sempre um de cada vez:

iommu=soft

amd_iommu=off

noapic

idle=nomwait

amdgpu.dc=0

Também pode ser testada uma combinação por vez, como:

nomodeset iommu=soft

Eu não começaria por "acpi=off". Esse parâmetro é muito agressivo e pode desativar gerenciamento térmico, bateria, desligamento correto, detecção de dispositivos e até parte dos núcleos do processador. Deve ser usado apenas como teste diagnóstico final, e não como solução permanente.

O parâmetro "pci=noaer" normalmente apenas oculta mensagens de erro PCI Express AER e, isoladamente, dificilmente resolverá uma reinicialização desse tipo.

Outro teste útil seria iniciar uma imagem do Ubuntu Server. Se ela também reiniciar antes de chegar ao instalador em modo texto, isso reforçaria a hipótese de firmware, ACPI/APIC, IOMMU, memória ou outro componente, em vez de uma falha exclusiva da interface gráfica.

Para avançar no diagnóstico, seriam importantes as seguintes informações:

* versão atual do BIOS;
* modelo exato do processador Ryzen;
* versão exata das imagens Linux testadas;
* resultado do diagnóstico ePSA;
* última mensagem exibida ao retirar "quiet splash";
* confirmação de que uma imagem do Ubuntu Server também foi testada;
* comportamento com outro pen drive e outra porta USB.

Com esses dados será possível indicar um parâmetro específico, em vez de tentar opções aleatórias que podem apenas esconder o problema.

[Rafael Abreu]

Boa tarde amigo, obrigado pelo retorno.
Por fim, acredito ter sido a iso defeituosa. Acabei baixando a do Mint e consegui realizar a instalação.
Cara, me dá um help. Eu tenho um ssd externo SATA, que uso no dia para salvar minhas atividades de trabalho, porém estou me deparando com um problema nos pdfs e fotos que tenho.
Antes, utilizada essa partição no NTFS e apareceram manchas, alterações de caracteres nos arquivos ou até mesmo a página ficava toda preta.
Acreditei ser o formato da partição, formatei ela é deixei em EXT4.
No SSD interno está perfeito, transfiro para o SSD externo os problemas aparecem.
Sabe como posso resolver isso?
Obs. Se baixo arquivos novos, acontece a mesma coisa, no ssd da máquina, está perfeito, quando mando para o externo alguns apresentam defeitos
Obrigado mais uma vez.
Grande abraço

[galactus]

Fala meu caro, beleza?

O fato de você ter formatado para EXT4 e o problema ter persistido nos dá uma pista muito importante: não é um problema de sistema de arquivos e nem do Linux em si.

Como no seu SSD interno os arquivos ficam perfeitos e o problema só acontece ao gravar ou ler do SSD externo, temos 3 grandes suspeitos na camada física e de transporte:

• Defeito no Case/Cabo USB ou na Ponteira SATA-USB: Muito comum em cases de entrada. Elas corrompem pacotes durante a transferência sem disparar erros críticos imediatos para o sistema operacional.
  
• Degradação física do SSD externo: Células de memória NAND desgastadas, falha no firmware do SSD ou falha no algoritmo de correção de erros (ECC).
  
• SSD com capacidade falsa (Fake Capacity): Se o SSD foi comprado na internet por um valor muito abaixo do mercado, a controladora pode ter sido modificada para reportar ex: 512 GB, mas ter fisicamente apenas 32 GB. Ao passar da capacidade real, os dados antigos/novos são sobrescritos com lixo eletrônico (gerando as páginas pretas nos PDFs e fotos corrompidas).
  

Roteiro de Diagnóstico (Passo a Passo)

Para descobrirmos exatamente o que está acontecendo sem adivinhar, siga esses passos no terminal:

1. Teste de Integridade Real (Descobrir se o hardware está alterando bits)
Vamos usar a ferramenta F3 (Fight Flash Fraud), que grava dados de teste e depois lê para validar a integridade bit a bit sem falsos positivos.

Instale o utilitário:

Código Selecionar Expandir

sudo apt update && sudo apt install f3
Acesse a pasta onde seu SSD externo está montado (exemplo: /media/seu_usuario/NOME_DO_SSD/) e execute o teste de escrita:

Código Selecionar Expandir

f3write .
Quando terminar o preenchimento, execute o teste de leitura e validação:

Código Selecionar Expandir

f3read .
O que observar: Se o

Código Selecionar Expandir

f3read informar DATA CORRUPTED em vários blocos, fica provado que o hardware (case, cabo ou a própria memória NAND do SSD) está alterando os dados gravados.


2. Verificar a Saúde do SSD via S.M.A.R.T.
Instale o utilitário de diagnóstico de disco:

Código Selecionar Expandir

sudo apt install smartmontools
Descubra a letra do seu SSD externo (ex: /dev/sdb ou /dev/sdc) usando o comando

Código Selecionar Expandir

lsblk e depois rode:

Código Selecionar Expandir

sudo smartctl -a /dev/sdX(Substitua /dev/sdX pelo caminho correto do seu SSD externo).

O que observar: Verifique se há alertas de Reallocated Sector Count, Uncorrectable Error Count ou erros críticos de I/O no relatório.


3. Testes Rápidos de Isolamento

• Troque o cabo USB do case.
• Ligue o SSD direto em uma porta USB traseira da placa-mãe (se for PC de mesa) para evitar oscilações de energia de portas frontais/hubs.
• Se puder, remova o SSD do case e teste em outra gaveta ou adaptador SATA-USB.

Faça o teste do

Código Selecionar Expandir

f3 e cole o resultado aqui no tópico para identificarmos exatamente onde está o vilão da história!

Um abraço!