Lentidão de Mais de 2 Minutos no Boot do Linux Mint — Causa: Periférico USB Bluetooth
Sem tempo, irmão:
Se o seu Linux demora muito tempo para inicializar e o
systemd-analyzemostra um tempo de kernel acima de 10 segundos, há grande chance de algum periférico estar causando timeout no carregamento do driver.
No caso dos dongles Bluetooth com chipset BR8651, o problema é conhecido e pode ser resolvido desconectando o dispositivo antes da inicialização.
Utilize odmesge olsusbpara identificar o periférico causador e verificar exatamente onde o kernel está perdendo tempo durante o boot.
Olá, comunidade DiolinuxPlus!
Recentemente enfrentei uma lentidão extrema na inicialização do meu Linux Mint, com o tempo total de boot ultrapassando 2 minutos.
A causa principal estava no kernel, e a solução foi surpreendentemente simples — mas exigiu um diagnóstico cuidadoso.
Compartilho abaixo o passo a passo da investigação e a solução, que pode ajudar quem passa pelo mesmo problema.
1. Diagnóstico Inicial — O Vilão Era o Kernel
O primeiro passo foi usar o utilitário systemd-analyze para medir o tempo de inicialização:
rafael@rafael:~$ systemd-analyze
Startup finished in 32.247s (firmware) + 8.658s (loader) + 1min 19.281s (kernel) + 12.775s (userspace) = 2min 12.963s
graphical.target reached after 12.728s in userspace.
Análise da Saída
- Kernel: 1 minuto e 19 segundos — principal gargalo.
- Userspace: 12,7 segundos — dentro do normal.
- Conclusão: o kernel estava travando na inicialização de algum hardware.
2. Gargalo Secundário — Espera da Rede
O comando systemd-analyze critical-chain revelou um segundo atraso, menor mas notável:
rafael@rafael:~$ systemd-analyze critical-chain
[...]
└─NetworkManager-wait-online.service @5.326s +7.361s
[...]
O serviço NetworkManager-wait-online.service adicionava cerca de 7 segundos, pois espera que a conexão de rede esteja totalmente ativa antes de liberar o ambiente gráfico.
É tolerável, mas pode ser desativado posteriormente para otimização adicional.
3. O Culpado: Dongle Bluetooth Baseus BA04 (Chipset BR8651)
Usando o comando dmesg, identifiquei que o kernel estava travando na etapa de inicialização de um dongle Bluetooth USB Baseus BA04, que utiliza o chipset Barrot BR8651.
Esse chipset é conhecido por apresentar problemas de compatibilidade com o Linux.
O problema ocorre porque o driver tenta carregar o firmware do dispositivo durante o boot, mas o dongle não responde dentro do tempo esperado pelo kernel, gerando um timeout.
3.1. Entendendo o Timeout
Durante o processo de inicialização, o kernel executa uma sequência de detecção e configuração de drivers e dispositivos conectados (como USBs e Bluetooths).
Quando um periférico não responde corretamente aos comandos de inicialização, o kernel tenta reenviar as solicitações diversas vezes antes de desistir — esse tempo de espera é chamado de timeout.
No caso do BR8651, o driver aguarda aproximadamente 90 segundos até concluir que o dispositivo não pode ser inicializado.
Somente após esse tempo o boot prossegue, o que explica o atraso de 1 minuto e 19 segundos observado na análise.
4. Como Identificar o Periférico Problemático no dmesg
O comando dmesg é uma ferramenta poderosa para visualizar mensagens do kernel e descobrir exatamente onde o sistema está travando.
A seguir estão alguns comandos e técnicas que ajudam a identificar o periférico causador do problema.
4.1. Exibir o log completo do kernel:
dmesg | less
Percorra as mensagens em busca de linhas com grandes lacunas de tempo.
Esses intervalos costumam indicar tentativas repetidas de inicialização de um dispositivo que não está respondendo.
4.2. Filtrar apenas mensagens relacionadas a Bluetooth:
dmesg | grep -i bluetooth
Esse comando retorna apenas as linhas referentes ao subsistema Bluetooth.
Se houver travamentos, será comum ver algo semelhante a:
Bluetooth: hci0: command 0x1001 tx timeout
Bluetooth: hci0: BCM: failed to write update baudrate (-110)
Bluetooth: hci0: BCM: patch failed (-110)
A expressão tx timeout ou failed com código (-110) é um indicativo claro de que o dispositivo não respondeu dentro do prazo esperado.
4.3. Ver logs com timestamps legíveis:
Vou usar, aqui, um exemplo de como identificar o problema por meio do dmesg:
dmesg --ctime | less
O parâmetro --ctime exibe as horas reais das mensagens, facilitando perceber onde há uma pausa longa.
Por exemplo:
[Wed Oct 23 09:41:12 2025] usb 1-3: new full-speed USB device number 4 using xhci_hcd
[Wed Oct 23 09:42:43 2025] Bluetooth: hci0: command 0x1001 tx timeout
Nesse exemplo, há 1 minuto e 31 segundos entre as mensagens, o que confirma o timeout causado pelo dongle Bluetooth.
4.4. Identificar o dispositivo pelo nome ou fabricante:
Se quiser confirmar que o problema vem do dongle USB específico, use:
lsusb
O comando lista todos os dispositivos USB conectados.
No caso do Baseus BA04, o resultado pode ser algo semelhante a:
Bus 001 Device 004: ID 13d3:3549 Barrot Technology Ltd. BR8651 Bluetooth Adapter
Com o ID e nome do fabricante confirmados, basta desconectá-lo e refazer o teste de inicialização.
4.5. Repetir o teste sem o periférico:
Depois de removê-lo, execute novamente:
systemd-analyze
Compare os tempos de boot e confirme a redução drástica na fase do kernel.
Essas etapas permitem identificar, com precisão, qual dispositivo está causando o atraso e em qual momento o kernel fica travado, facilitando diagnósticos em qualquer máquina Linux.
4.6.Solução Adotada
A solução mais simples e eficaz foi remover o dongle Bluetooth da porta USB durante o boot e conectá-lo somente quando necessário.
Dessa forma, o kernel não tenta carregar o driver problemático durante a inicialização, eliminando completamente o timeout.
5. Resultado Final — Boot Otimizado
Após remover o periférico, o tempo de inicialização caiu drasticamente:
rafael@rafael:~$ systemd-analyze
Startup finished in 11.545s (firmware) + 6.280s (loader) + 5.744s (kernel) + 12.855s (userspace) = 36.425s
graphical.target reached after 12.782s in userspace.
5.1.Comparativo Antes x Depois
| Fase de Boot | Tempo Anterior | Novo Tempo | Redução |
|---|---|---|---|
| Kernel | 1 min 19.281 s | 5.744 s | Redução de aproximadamente 1 min 13 s |
| Firmware | 32.247 s | 11.545 s | Redução de aproximadamente 20,7 s |
| Total | 2 min 12.963 s | 36.425 s | Redução de aproximadamente 1 min 36 s |
O boot passou de mais de 2 minutos para menos de 40 segundos, um resultado excelente.
6. Conclusões e Dicas Finais
Se o seu systemd-analyze mostrar um tempo anormalmente alto no kernel ou firmware, siga estas etapas:
-
Desconfie de periféricos USB:
Desconecte dongles, adaptadores de rede, impressoras, HDs externos ou outros dispositivos e teste novamente o boot. -
Verifique os logs do kernel:
dmesg | lessProcure por intervalos grandes de tempo entre as mensagens. Essas lacunas revelam onde o timeout ocorre.
-
Otimização opcional da rede:
Caso queira eliminar o pequeno atraso adicional do NetworkManager, execute:sudo systemctl disable NetworkManager-wait-online.service
Espero que essa experiência detalhada ajude outros membros da comunidade a diagnosticar e resolver problemas de boot lento! Um abraço a vocês e fiquem bem 
