Olá pessoal!
Estava usando o MAD LINUX, aliás deveria ser a versão do ubuntu studio, um sistema leve e sem complicações, resolvi instalar o pop os e a partir daí tive esse problema. O sistema da aviso que tem apenas 615 MB disponível, com duas opções 1-examinar e 2- ignorar.
kern.log e syslog.1 estão enchendo o HD. Como solucionar isso focando na vida útil do hd? Terei que ficar o tempo todo apagando isso?
rodei os comandos abaixo para apagar.
Esse tipo de log é criado pelo kernel quando ocorrem certos evento, até a inicialização da máquina gera esses arquivos, em geral ele costuma ocupar menos de 1 mega, é provável que seja alguma configuração incorreta ou mesmo algum bug, existem formas de limitar o tamanho máximo de criação do arquivo, mais são soluções temporárias, se não quiser se preocupar com isso, a solução mais radical é simplesmente desabilitar a geração do LOG. (em meus testes isso não gerou consequências, mais fica o aviso)
Acesse: o arquivo rsyslog
sudo nano /etc/rsyslog.conf
Pesquise por ‘imklog’ e comente a linha que se parece com esta:
module(load=“imklog” permitnonkernelfacility=“on”)
se vc n tem o hábito de “ver log” ou não sabe como fazê-lo - ou seja - s n tem utilidade pra sua pessoa, desabilite sua geração ou bote pra RAM, no fstab.
nunca me preocupei com log. se der algum problema, formato e instalo de novo, oq nunca m ocorreu.
Boa noite! O arquivo log que fica gigante são 4: kern.log, kern.log.1, syslog, syslog.1 . Efetuando a mudança da linha de comando não traria problema ao sistema?
Pesquisando em alguns sites, vi uma solução. Pode-se determinar um tamanho específico do diretório e também determinar a rotação de logs. A solução foi feita no fedora.
Segue o link.
Diante de tudo isso, gostaria mesmo é que o sistema rodasse sem erros exacerbados como neste caso. Analisando o log, é melhor tentar arrumar, desligar a geração de log ou fazer a configuração do fedora do link acima?
pcieport 0000:00:1d.4: AER: Corrected error received: 0000:03:00.0
módulo do kernel pcieport (que controla a informação dos barramentos pci-express) corrigiu um erro no barramento 0000:00:1d.4 proveniente do dispositivo localizado no endereço 0000:03:00.0
alx 0000:03:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Módulo do kernel alx ( controlador de ethernet Qualcomm Atheros) está mandando uma mensagem sobre o dispositivo que está no endereço 0000:03:00.0. A mensagem é que houve um erro barramento PCI-express. Esse erro foi corrigido e é do tipo “camada física” (mas como geralmente a rede é onboard, somente um dano físico na placa mãe ou curto circuito interno nas trilhas poderia gerar algo terrível deste modo. Talvez seja indicação de erro físico mas na realidade seja um problema de driver inadequado)
alx 0000:03:00.0: device [1969:10a1] error status/mask=00000001/00002000
De novo o driver alx, dessa vez dando mais destalhes sobre o dispositivo, que é do fabricante 1969 (Qualcomm Atheros) ID 10a1 (QCA8171 Gigabit Ethernet). Erro 1, máscara 2000 (em hexadecimal)
alx 0000:03:00.0: [ 0] RxErr
Provavelmente a descrição do erro existente no driver: RxErr
Daí começa tudo de novo:
Jun 8 18:12:22 pop-os kernel: [82908.827918] pcieport 0000:00:1d.4: AER: Corrected error received: 0000:03:00.0
Como ter uns outros erros referente ao mesmo hardware, como BadDLLP e BadTLP, dá pra tentar essas soluções:
Habilite a opção “IOMMU” na BIOS.
adicionar a seguinte opção de kernel pci=nommconf que desabilita alguns recursos do barramento pci.
adicionar a seguinte opção de kernel pcie_aspm=off que desabilita o gerenciamento de energia no barramento pci-express. Pela documentação do kernel pode gerar travamento do computador.
Se vc está usando o computador no cabo de rede, faça uma verificação no cabo e tente colocam em outra porta do roteador. Talvez esse erro esteja associado com problemas na internet, lenta, perda de pacotes e desconexões aleatórias.
Dado que aparentemente já está definido que o problema tem a ver com a “placa” de rede, poderia tentar desabilitar a rede onboard (caso seja) e ver como se comporta. Se resolver é só colocar outra placa de rede.
Agora, como estava funcionando sem problema em outro sistema, outra alternativa é tentar trocar o driver dessa placa.
Atualizando: Desculpe, só vi agora que é um laptop. A ideia de colocar outra placa pode ser um pouco difícil.
No ubuntu já tive uma vez esse problema, no MADLINUX rodava liso como um mar sem ondas, no pop os está dando isso. Três duvidas me surgiu.
1 - Como poderia incluir esses dados que sugestionou, no kernel?
2 - Atualização do sistema de alguma forma poderia sobrescrever esta alteração que faremos no kernel?
3 - Questão de segurança do sistema é alterada?
Eu tive uma experiência semelhante, onde o disco começou a ficar cheio devido aos logs, no meu caso foi devido ao VLC ficar com um vídeo aberto quando o eu suspendia o computador. Em uma suspensão encheu o disco de logs. Nesse caso a solução foi fechar o VLC quando suspendo ou não suspender.
Mas esse foi um caso que aconteceu comigo, não necessariamente é o seu problema. O ponto é: dê uma olhada nos logs e veja o que causa isso, como já detalhado em respostas anteriores. Se isso está ocorrendo, não é devido à operação normal. Caso o que causa esses logs não é necessariamente um problema, aí pode desabilitar os logs nas configurações do rsyslog, de acordo com a categoria que eles se encaixam.
Tem esse vídeo que vc pode ver pra adicionar provisoriamente a opção de kernel na inicialização do grub. Se funcionar vc deve adicionar como opção de inicialização no /etc/default/grub seguindo algum tutorial. Se for o systemd-boot eu não sei como fazer…
A alteração é no grub dificilmente é sobrescrita em atualizações. No systemd-boot eu não sei.
Pelo que li dessa opção vc vai perder algumas funcionalidades com relação à economia de energia… Fique atento à duração da bateria pra ser se é impactante (assumindo que alguma das opções do outro post resolveu o problema).
