Fórum Ubuntu Linux - PT
Área para Iniciantes => Dicas e Truques => Tópico iniciado por: Sampayu em 19 de Agosto de 2016, 19:19
-
Notas preliminares:
i) A abreviatura GPU significa Graphics Processing Unit, que significa "Unidade de Processamento Gráfico". Trata-se de uma expressão genérica: pode referir-se a uma placa de vídeo PCI, ou a uma placa de vídeo AGP, ou a uma placa de vídeo ISA, ou a uma placa de vídeo PCI Express, ou referir-se a algum chip gráfico instalado diretamente na placa-mãe (motherboard) do seu computador, ou mesmo referir-se a um pequeno circuito integrado, de processamento gráfico, que se encontre embutido no processador (CPU) do seu computador. Muitos dos recentes processadores da Intel possuem uma GPU embutida.
ii) O computador que possui duas ou mais GPU é denominado "computador híbrido" ou "computador com gráficos híbridos (https://wiki.archlinux.org/index.php/hybrid_graphics)". Os computadores híbridos geralmente têm uma GPU Intel no processador, mas além disso têm uma GPU (da marca AMD/ATI ou então da marca Nvidia) instalada na placa-mãe, o que pode ser ou um chip de uma GPU onboard ou então uma placa GPU conectada a algum slot da placa-mãe.
iii) Utilizarei a palavra *Ubuntu para me referir a todas as (ou a qualquer uma das) versões do sistema operacional suportado pela empresa Canonical (http://www.canonical.com): Ubuntu (http://www.ubuntu.com/), XUbuntu (http://xubuntu.org/), KUbuntu (http://www.kubuntu.org/) etc.
iv) O kernel é o núcleo do Linux. Sem o kernel, não existe sistema operacional. Durante o boot (a inicialização do sistema operacional), o kernel Linux inicializa diversos módulos do kernel (abreviadamente chamados de módulos). Os módulos do kernel são essencialmente pequenos arquivos com extensão .ko (abreviatura de kernel object, que significa "objeto do kernel"). Os módulos que são ligados ao kernel complementam o kernel, tornando-o capaz de executar mais funções. Atualmente, muitos drivers de dispositivo são módulos do kernel: esses drivers são vinculados ao kernel durante o boot, de modo que cada dispositivo do seu computador encontre o driver necessário para poder funcionar (cada driver possibilita a interação de um dispositivo com o kernel Linux).
A quem este pequeno tutorial pode interessar:
Este tutorial provavelmente interessará a quem possua computador com ao menos uma GPU da fabricante AMD e esteja se deparando com um cenário no qual o *Ubuntu "congela" durante o processamento de gráficos 3D. Esse tipo de problema tem sido bastante recorrente em computadores híbridos em que a GPU embutida no processador é da fabricante Intel mas a GPU externa é da fabricante AMD.
O lançamento dos *Ubuntu 16.04, por exemplo, trouxe muitas novidades, inclusive a ausência de suporte dos kernels versão 4.4.X ao driver gráfico proprietário fglrx (http://support.amd.com/pt-br/download/desktop?os=Ubuntu%20x86%2064#), desenvolvido pela AMD (http://www.amd.com/pt-br). Por causa disso, nos *Ubuntu 16.04 iniciais (versão 16.04.1) o proprietário de um computador que possua ao menos uma GPU da AMD terá de utilizar um destes dois drivers gráficos de código aberto: amdgpu e radeon. Esses drivers são automaticamente instalados e ativados quando você instala o *Ubuntu 16.04 num computador que possua alguma GPU da AMD: durante o boot, o kernel Linux automaticamente identifica qual GPU AMD seu computador possui e então seleciona o módulo que deve ser inicializado (o kernel inicializa somente um dos dois drivers: ou o driver radeon, que foi desenvolvido para alguns modelos de GPU da AMD, ou então o driver amdgpu, que foi desenvolvido para os demais modelos). No meu notebook, por exemplo (um Dell Inspiron 5548 com XUbuntu 16.04 de 64 bits), o módulo em execução é o arquivo amdgpu.ko.
O problema:
Embora o *Ubuntu 16.04.1 venha com kernel versão 4.4.X, que não dá suporte ao driver fglrx (o que nos obriga a usar o módulo amdgpu/radeon, automaticamente instalado pelo *Ubuntu 16.04.1), os kernels das séries 4.4.X e 4.5.X possuem um bug que faz com que o driver amdgpu/radeon seja inicializado de maneira errada: o kernel acaba apontando para um ponteiro inválido (porque não foi ainda criado) e daí surge um kernel panic ("pânico do kernel") que provoca o completo travamento / congelamento do sistema operacional, e aí o jeito é desligar o computador "no dedo" (pressionando o botão power / "liga-desliga").
Inclusive, há tópicos relacionados a este assunto em que usuários indicam ativar a função nomodeset, no GRUB. No entanto, isso é contraindicado porque tornará o desempenho gráfico em 3D extremamente lento, além de geralmente inutilizar as saídas HDMI. Há também quem proponha adicionar os drivers amdgpu e radeon à blacklist ("lista negra" de módulos do kernel), o que fará com que esses drivers não sejam inicializados pelo kernel, mas isso também é contraindicado porque o driver fglrx não funciona com esses kernels mais novos. Consequentemente, se o usuário desativar aqueles dois drivers o sistema operacional ficará sem driver para a GPU da AMD, o que resultará em "tela preta" e impossibilidade de usar o computador, além de que o problema não está nos drivers amdgpu/radeon, mas sim nos kernels 4.4.X e 4.5.X (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1608042/comments/31).
Alguns benchmarks (testes de desempenho) realizados com 5 diferentes GPU da AMD, para comparar a diferença de desempenho gráfico entre o *Ubuntu 14.04 com driver fglrx e o *Ubuntu 16.04 com driver amdgpu/radeon, indicaram que no uso cotidiano da interface gráfica do Linux os drivers amdgpu/radeon apresentaram desempenho superior ao do driver fglrx (fonte: http://www.phoronix.com/scan.php?page=article&item=ubuntu-1604-amd&num=2), portanto não fique triste por ter de usar um driver de código aberto no lugar do driver proprietário. ;)
A solução:
A solução recomendada para acabar com os congelamentos / travamentos / kernel panics consiste em instalar um kernel estável¹ da série 4.6.X ou posterior, pois os kernels dessas séries não possuem esse bug. Neste tutorial, explicarei como instalar o kernel 4.14.14 (versão posterior à 4.6.X) , que é o que eu utilizo desde 15/12/2017 e recomendo por atualmente ser a mais recente versão estável do kernel Linux que eu já testei por várias semanas, no meu próprio computador, sem detectar problema nenhum. Além disso, neste tutorial eu também explico como instalar o kernel 4.7.10, já que ele é superestável e eu o usei por 14 meses, sem vivenciar problema nenhum. Se o kernel 4.14.14 não ajudar você, experimente o kernel 4.7.10.
IMPORTANTE: SEU SISTEMA TRAVA/CONGELA ANTES QUE VOCÊ POSSA USAR ESTE TUTORIAL? Então primeiro desabilite o KMS (http://ubuntuforum-br.org/index.php/topic,120620.msg662202.html#msg662202) (e depois volte para cá). ;)
Passo-a-passo para instalação do kernel 4.7.14:
1) O primeiro passo consiste em executar o supercomando abaixo. Esse supercomando² automaticamente identificará a arquitetura do seu sistema operacional (32 bits ou 64 bits) e o tipo de kernel atualmente utilizado pelo seu sistema (generic/"genérico" ou lowlatency/"baixa latência") e, com base nessas duas informações, obterá os arquivos do kernel 4.14.14 apropriados para seu computador e os instalarão, e em seguida reiniciará o seu computador, portanto não se assuste quando seu computador reiniciar. ;D Enfim: abra uma janela do emulador de terminal do shell e execute este supercomando:
if [ `uname -a |grep -io generic` = "generic" ]; then meukernel=generic; else meukernel=lowlatency; fi; wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.14/linux-headers-4.14.14-041414_4.14.14-041414.201801201219_all.deb -O /tmp/41414all.deb; if [ `getconf LONG_BIT` == 64 ]; then sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.14/linux-headers-4.14.14-041414-`echo $meukernel`_4.14.14-041414.201801201219_amd64.deb -O /tmp/41414headers.deb; sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.14/linux-image-4.14.14-041414-`echo $meukernel`_4.14.14-041414.201801201219_amd64.deb -O /tmp/41414image.deb; else sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.14/linux-headers-4.14.14-041414-`echo $meukernel`_4.14.14-041414.201801201219_i386.deb -O /tmp/41414headers.deb; sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.14/linux-image-4.14.14-041414-`echo $meukernel`_4.14.14-041414.201801201219_i386.deb -O /tmp/41414image.deb; fi; sudo dpkg -i /tmp/41414*.deb; sudo update-grub ; sudo telinit 6
2) Agora que seu computador obteve e instalou o kernel 4.14.14, atualizou o GRUB (gerenciador de boot do Linux) e reiniciou o sistema, é hora de executar o comando abaixo para confirmar que seu sistema está executando o kernel 4.14.14:
uname -r
Caso o resultado do comando acima inicie com 4.14.14, parabéns: seu sistema está executando o kernel versão 4.14.14 e o GRUB está inicializando esse kernel por padrão. 8)
Se o comando acima informar que seu sistema Linux continua, por padrão, executando um kernel cuja versão é posterior à do kernel que você instalou com ajuda deste tutorial, leia este post (https://ubuntuforum-br.org/index.php/topic,120620.msg672814.html#msg672814) para aprender a definir temporariamente o kernel deste tutorial como sendo o kernel que deverá ser usado pelo seu sistema. Após seu sistema executar ("boot" / inicializar) o kernel que foi instalado com auxílio deste tutorial, execute os testes explicados no item 3 deste tutorial para verificar se o kernel que você instalou resolveu seu problema. Se o tal kernel não resolveu o problema, ok: basta reiniciar o computador que o sistema voltará a usar o kernel padrão, ao invés de usar o kernel que você instalou manualmente seguindo este tutorial...
...mas, caso o kernel instalado com ajuda deste tutorial resolva o seu problema, então leia este outro post (https://ubuntuforum-br.org/index.php/topic,120620.msg673811.html#msg673811) para saber como fazer para definir esse "kernel bom" como sendo o kernel padrão do seu sistema (kernel padrão = kernel que o seu sistema sempre inicializará, automaticamente). ;)
3) Depois que você conseguir inicializar o Linux com o kernel que você instalou com ajuda deste tutorial, retorne ao emulador de terminal do shell e execute o comando abaixo:
DRI_PRIME=1 glxgears
Esse comando executa um programa que testa o processamento gráfico 3D. Se as engrenagens surgirem e ficarem girando, e se mesmo assim seu sistema não "congelar", eis aí uma confirmação de que o bug não está mais presente. Mas você pode fazer outros testes: deixe as engrenagens girando lá e, enquanto isso, execute algum jogo que use gráficos em 3D, ou algum descanso de tela (alguma proteção de tela) que use gráficos em 3D. Observe o comportamento do seu computador e repare que o desempenho gráfico melhorou significativamente.
CASO VOCÊ PREFIRA INSTALAR O KERNEL 4.7.10...
...então não execute o supercomando do item 1 e, no lugar dele, execute este supercomando:
if [ `uname -a |grep -io generic` = "generic" ]; then meukernel=generic; else meukernel=lowlatency; fi; wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.10/linux-headers-4.7.10-040710_4.7.10-040710.201610220847_all.deb -O /tmp/4710all.deb; if [ `getconf LONG_BIT` == 64 ]; then sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.10/linux-headers-4.7.10-040710-`echo $meukernel`_4.7.10-040710.201610220847_amd64.deb -O /tmp/4710headers.deb; sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.10/linux-image-4.7.10-040710-`echo $meukernel`_4.7.10-040710.201610220847_amd64.deb -O /tmp/4710image.deb; else sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.10/linux-headers-4.7.10-040710-`echo $meukernel`_4.7.10-040710.201610220847_i386.deb -O /tmp/4710headers.deb; sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.10/linux-image-4.7.10-040710-`echo $meukernel`_4.7.10-040710.201610220847_i386.deb -O /tmp/4710image.deb; fi; sudo dpkg -i /tmp/4710*.deb; sudo update-grub ; sudo telinit 6
...e, após seu computador reiniciar, execute as orientações dos itens 2 e 3. ;)
Quando você se convencer de que está livre do bug, feche a janela do emulador de terminal e retome sua rotina. 8)
COMO DESINSTALAR O KERNEL:
IMPORTANTE: seu sistema precisa ter ao menos um kernel instalado. Conforme explicado lá no início do tutorial, o kernel é o núcleo do sistema. Portanto, caso você desinstale todos os kernels do seu sistema, não haverá mais sistema operacional! Enfim: certifique-se de deixar ao menos um kernel instalado, para você poder continuar conseguindo inicializar o Linux do seu computador.
Caso queira ver quais são todos os kernels atualmente instalados em seu sistema, execute este comando, no terminal do shell:
ls -lx /lib/modules/
Ok: agora que o aviso foi dado, caso queira desinstalar um dos (ou mais) kernels que você instalou com ajuda deste tutorial, retorne ao terminal do shell e execute o(s) comando(s) abaixo, conforme sua necessidade:
D1) Para desinstalar o kernel versão 4.7.10, execute este comando:
sudo apt-get purge linux-*-4.7.10* -y
D2) Para desinstalar o kernel versão 4.14.14, execute este comando:
sudo apt-get purge linux-*-4.14.14* -y
D3) Regra geral, para desinstalar um kernel qualquer, da versão A.B.C, execute este comando:
sudo apt-get purge linux-*-A.B.C* -y
...sendo que, no comando acima (mencionado no item D3), você obviamente deverá substituir as letras A, B e C pelos respectivos algarismos que compõem o número de versão do kernel que você deseja desinstalar.
Restou alguma dúvida? Publique um comentário neste tópico. :D
Notas de rodapé:
¹ Por kernel estável da série 4.6.X entenda isto: qualquer kernel do repositório Mainline (http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D) cuja numeração de versão inicie com 4.6 e não possua o texto rc (abreviação de release candidate ou "candidato ao lançamento", que significa que o kernel não é estável mas está em fase final de testes para o próximo lançamento). De acordo com o repositório Mainline, os kernels estáveis da versão 4.6 são estes: 4.6.7, 4.6.6, 4.6.5, 4.6.4, 4.6.3-yakkety, 4.6.2-yakkety, 4.6.1-yakkety e 4.6-yakkety.
² Um supercomando é uma concatenação (combinação) de vários comandos do shell em uma única linha de comando. Embora sejam "compridos", os supercomandos têm a vantagem de fazer "tudo de uma vez", deste modo economizando a execução de comandos individualmente, ao longo de diversas etapas que eventualmente podem acabar sendo cansativas. Um supercomando também é útil para automatizar algumas tarefas, e esse é o caso do supercomando utilizado neste tutorial: ele automaticamente identifica a arquitetura do seu sistema operacional e o tipo de kernel padrão em uso pelo seu sistema para, a partir daí, definir qual deverá ser o tipo e a arquitetura do kernel a ser obtido e instalado. ;)
-
Grande mestre Sucupira!
Obrigado pelo tutorial!
-
Seu sistema está congelando e travando tanto que você mal consegue chegar à interface gráfica, muito menos ler e executar todas as etapas do tutorial acima?
Palma, palma: não criemos cânico. É como diria a propaganda: Existem mil maneiras de se preparar Neston. No mundo Linux as coisas não são assim tão diferentes: há diferentes maneiras de se contornar esse problema. Uma delas consiste em temporariamente ativar a opção nomodeset, dentro do arquivo de configuração do GRUB (o gerenciador de boot do Linux), de modo que o seu Linux inicialize o kernel sem KMS. Isso impedirá que o bug do kernel seja "executado". O desempenho gráfico ficará péssimo, mas você conseguirá usar seu Linux e aplicar as instruções do tutorial. ;)
Eis o passo-a-passo para contornar temporariamente o problema dos travamentos que lhe impedem o acesso ao seu sistema:
i) Desligue seu computador.
ii) Ligue-o novamente e então pressione a tecla Esc (Escape) para fazer o menu do GRUB aparecer.
iii) Pressione a tecla E para entrar no editor dinâmico do GRUB.
iv) Use as teclas de seta direcional para deslocar o ponteiro do editor até onde se lê splash $vt_handoff e daí insira o texto nomodeset entre aquelas duas palavras, de modo que no fim das contas o texto fique assim (observe que há um espaço entre cada par de palavras):
splash nomodeset $vt_handoff
v) Pressione a tecla F10 (ou a combinação de teclas Ctrl X) para inicializar o Linux com essa alteração que você fez.
Pronto! O Linux será inicializado com o KMS desativado. KMS significa Kernel Mode Setting, que significa algo como "modo de configuração definido pelo kernel". O KMS vem ativado por padrão, e, quando ativado, faz com que o kernel automaticamente detecte os dispositivos presentes no computador e inicialize os módulos que contenham os drivers respectivamente necessários. Ao instruir o GRUB a inicializar o kernel do Linux com a opção nomodeset, você desabilita o KMS e deste modo instrui o kernel a não inicializar o driver amdgpu/radeon, daí o kernel passa a usar um driver VGA padrão que é tão, tãããão limitado que não executará nenhuma instrução capaz de ocasionar o "congelamento" do sistema.
Agora que o seu sistema está estável, siga as instruções do tutorial (http://ubuntuforum-br.org/index.php/topic,120620.msg662196.html#msg662196) para verificar qual é a arquitetura do seu sistema (32 bits ou 64 bits), o tipo de kernel (genérico ou de baixa latência), baixar (fazer download) dos três pacotes .DEB do kernel sugerido pelo tutorial e instalar esses pacotes. Quando você reiniciar o computador, a opção nomodeset será perdida e o novo kernel será automaticamente inicializado com o KMS ativado. Como nesse novo kernel o KMS não dá problema com o driver amdgpu/radeon, seu sistema ficará estável e você poderá usufruir dos recursos 2D e 3D da sua GPU AMD. :)
-
Grande mestre Sucupira!
Obrigado pelo tutorial!
De nada. Espero que seja útil a muitos usuários *Ubuntu. :)
-
Olá! Esta é minha primeira publicação neste fórum!
Eu tenho um notebook da Dell, um inspiron 5548 i7 (5ªg), 16GB, AMD R7 M265 + Intel HD Graphics 5500). E tenho vários problemas ao utilizar linux nele.
Eu estou utilizando linux mint 17.3 atualmente, apenas instalei e saí usando. Percebi que estou usando o driver open source, até aí tudo bem. Pois eu não jogo e não faço nenhuma tarefa graficamente pesada no ambiente Linux Mint 17.3, mas fico chateado ao rolar por uma página com muitas imagens no google chrome e a rolagem ficar travada. Mas tudo bem...
Esta semana, baixei e instalei o linux mint 18, Com o linux mint 18, eu constatei que ao abaixar a tampa do notebook, e depois eu tentar abrir a tampa o computador liga e trava na tela de digitar a minha senha. Dei uma pesquisada na internet, inclusive nos comentários da página do mint 18, e parece que o problema está relacionado com a placa gráfica amd.
1 - Será que se eu instalar o linux mint 18, e instalar esse kernel mais novo, meu problema vai se resolver?
2 - Se eu continuar no mint 17.3, o que é melhor? Deixar o driver como está, ou selecionar o fglrx? (Eu percebo que ao escolher fgrlx, não muda muita coisa no google chrome, e se prestar muita atenção a tela fica com uns pontilhados estranhos no explorador de arquivos)
Obrigado desde já :)
-
Olá! Esta é minha primeira publicação neste fórum!
Eu tenho um notebook da Dell, um inspiron 5548 i7 (5ªg), 16GB, AMD R7 M265 + Intel HD Graphics 5500). E tenho vários problemas ao utilizar linux nele.
Eu estou utilizando linux mint 17.3 atualmente, apenas instalei e saí usando. Percebi que estou usando o driver open source, até aí tudo bem. Pois eu não jogo e não faço nenhuma tarefa graficamente pesada no ambiente Linux Mint 17.3, mas fico chateado ao rolar por uma página com muitas imagens no google chrome e a rolagem ficar travada. Mas tudo bem...
Esta semana, baixei e instalei o linux mint 18, Com o linux mint 18, eu constatei que ao abaixar a tampa do notebook, e depois eu tentar abrir a tampa o computador liga e trava na tela de digitar a minha senha. Dei uma pesquisada na internet, inclusive nos comentários da página do mint 18, e parece que o problema está relacionado com a placa gráfica amd.
1 - Será que se eu instalar o linux mint 18, e instalar esse kernel mais novo, meu problema vai se resolver?
2 - Se eu continuar no mint 17.3, o que é melhor? Deixar o driver como está, ou selecionar o fglrx? (Eu percebo que ao escolher fgrlx, não muda muita coisa no google chrome, e se prestar muita atenção a tela fica com uns pontilhados estranhos no explorador de arquivos)
Obrigado desde já :)
Oi, Murilo. Meu notebook é exatamente o mesmo que o seu.
Este fórum é do Ubuntu, por isto provavelmente a maioria dos usuários usa Ubuntu. Deve haver alguns usuários de Mint no meio, mas acredito que eles sejam minoria: eu mesmo uso o XUbuntu 16.04 e o tutorial aí em cima eu fiz voltado para os usuários de *Ubuntu (Ubuntu, XUbuntu, KUbuntu etc.). Por conta disso, eu não sei lhe dizer como será o comportamento do Mint. Mas, pelo (pouco) que sei a respeito do Mint, ele é baseado no Ubuntu, então o kernel dele deve ser o mesmo do Ubuntu. Se for isso mesmo, instale o kernel acima indicado no tutorial e então reinicie o computador. Se o Mint de fato usa os kernels do Ubuntu, então esse kernel que você instalar entrará em ação e eliminará o bug que provoca travamentos na sua GPU AMD.
Eu não sei qual é a versão do kernel que o Mint 17.3 utiliza, mas se ele funciona com o driver proprietário fglrx então ele tem um desempenho 3D ligeiramente melhor que os drivers amdgpu/radeon, porém nos processamentos "leves" (2D) ele tem desempenho pior. Ali no tutorial mesmo eu cito um teste de desempenho que constatou que a última versão do Ubuntu (14.04) cujo kernel ainda era compatível com o driver fglrx está com um desempenho geral (principalmente em gráficos 2D) inferior ao do Ubuntu 16.04 com drivers amdgpu/radeon. Então, seguindo essa lógica, e considerando que você não usa o computador para jogos 3D pesados, eu não vejo vantagem em você usar o Mint 17.3 com driver fglrx - um driver que a AMD inclusive já anunciou que não vai mais desenvolver (está atualmente obsoleto).
Partindo da premissa de que o Mint usa o kernel do Ubuntu, eu instalaria o Mint 18 e em seguida me basearia no tutorial para instalar o kernel acima indicado. Creio que isso resolverá seu problema e deixará seu computador bem atualizado.
Se não fizer questão de usar o Mint, eu instalaria o XUbuntu 16.04 de 64 bits (http://torrent.ubuntu.com/xubuntu/releases/xenial/release/desktop/xubuntu-16.04.1-desktop-amd64.iso.torrent) e em seguida atualizaria o kernel, como explicado no tutorial acima. O XUbuntu é excelente e extremamente leve, seu notebook vai ficar com um desempenho ótimo.
-
Muito Obrigado .
Tenho um notebook Dell com Placa amd , estava travando muito e a performa do sistema muita lento.
Depois do Tutorial a performa mudou da água para vinho.
Venho aqui para agradecer e parabenizar pelo ótimo tutorial .
Grato.
Papagaio que acompanha João-de-Barro se enrola
Vira ajudante de pedreiro.
-
Muito Obrigado .
Tenho um notebook Dell com Placa amd , estava travando muito e a performa do sistema muita lento.
Depois do Tutorial a performa mudou da água para vinho.
Venho aqui para agradecer e parabenizar pelo ótimo tutorial .
Grato.
Papagaio que acompanha João-de-Barro se enrola
Vira ajudante de pedreiro.
Que satisfação saber que o tutorial está livrando os linuxistas dessa dor de cabeça com dispositivos da AMD. Bacana. :D
-
Alguém já conseguiu fazer funcionar o amdgpu-pro no Ubuntu 16.10?
Consegui resolver o problema de instalação substituindo a linha 69 do amdgpu-pro-install por essa echo ${dir}${etc}${dir}${sourceparts}/amdgpu-pro.liste criando o diretório "sourceparts" dentro do diretório "etc" manualmente antes de rodar a instalação
Agora quando reinicio tenho problemas. O driver não é reconhecido corretamente... acho que é por causa do kernel 4.8, pois quando eu inicio com o Kernel 4.4 ele funciona.
Não seria um problema ficar usando esse Kernel, mas com ele meu adaptador wireless não funciona, kkkkkkkkkkk
Tô pensando em fazer downgrade para o 4.7 pra ver se funciona...
Alguém já testou com o 16.10?
-
Alguém já conseguiu fazer funcionar o amdgpu-pro no Ubuntu 16.10?
Consegui resolver o problema de instalação substituindo a linha 69 do amdgpu-pro-install por essa echo ${dir}${etc}${dir}${sourceparts}/amdgpu-pro.liste criando o diretório "sourceparts" dentro do diretório "etc" manualmente antes de rodar a instalação
Agora quando reinicio tenho problemas. O driver não é reconhecido corretamente... acho que é por causa do kernel 4.8, pois quando eu inicio com o Kernel 4.4 ele funciona.
Não seria um problema ficar usando esse Kernel, mas com ele meu adaptador wireless não funciona, kkkkkkkkkkk
Tô pensando em fazer downgrade para o 4.7 pra ver se funciona...
Alguém já testou com o 16.10?
Nunca instalei o 16.10, mas testei o kernel 4.8 no 16.04 e deu uns problemas de driver, por isto no tutorial estou mantendo a sugestão de usar o kernel que está funcionando direitinho com os drivers (inclusive o amdgpu e o radeon). Como você está no 16.10 e tendo problema com o kernel 4.8, acho que é uma boa testar o kernel indicado no tutorial.
-
Alguém já conseguiu fazer funcionar o amdgpu-pro no Ubuntu 16.10?
Consegui resolver o problema de instalação substituindo a linha 69 do amdgpu-pro-install por essa echo ${dir}${etc}${dir}${sourceparts}/amdgpu-pro.liste criando o diretório "sourceparts" dentro do diretório "etc" manualmente antes de rodar a instalação
Agora quando reinicio tenho problemas. O driver não é reconhecido corretamente... acho que é por causa do kernel 4.8, pois quando eu inicio com o Kernel 4.4 ele funciona.
Não seria um problema ficar usando esse Kernel, mas com ele meu adaptador wireless não funciona, kkkkkkkkkkk
Tô pensando em fazer downgrade para o 4.7 pra ver se funciona...
Alguém já testou com o 16.10?
Nunca instalei o 16.10, mas testei o kernel 4.8 no 16.04 e deu uns problemas de driver, por isto no tutorial estou mantendo a sugestão de usar o kernel 4.7.4, que está funcionando direitinho com os drivers (inclusive o amdgpu e o radeon). Como você está no 16.10 e tendo problema com o kernel 4.8, acho que é uma boa testar o kernel 4.7.4.
Não rapaz, acho que você não me entendeu.
Creio que você fez esse tutorial baseado no uso do driver open source.
Eu estou usando o driver proprietário. AMDGPU-PRO
Como você falou a respeito do funcionamento do driver AMDGPU open com Kernel 4.8, eu resolvi ampliar a questão para o driver proprietário, pois o problema existe com ele também, sacou? Se não eu teria que abrir outro tópico e isso seria redundante. Creio que dá pra lidar com os dois problemas aqui.
Eu vou testar um path para o amdgpu-pro que encontrei, mas só vai funcionar com o Kernel 4.6.7.
Assim que eu testar, postarei o resultado.
Abraços
Obs.: usar o driver open não me interessa no momento pela falta de suporte ao Vulkan
-
Não funciona
É Downgrade pro 16.04 pra poder usar o Vulkan... e só com Kernel 4.4 o AMDGPU-PRO funcionou aqui.
Depois quando eu estiver com mais tempo, tento novamente no Ubuntu 16.10
-
Não funciona
É Downgrade pro 16.04 pra poder usar o Vulkan... e só com Kernel 4.4 o AMDGPU-PRO funcionou aqui.
Depois quando eu estiver com mais tempo, tento novamente no Ubuntu 16.10
Realmente eu não havia reparado que você estava se referindo ao amdgpu proprietário (http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-GPU-PRO-Linux-Beta-Driver%E2%80%93Release-Notes.aspx). É, não testei esse driver. A lógica do tutorial foi realmente a de instalar um kernel estável mais recente para que o driver amdgpu open-source funcionasse. Como no seu caso o dispositivo precisa do amdgpu-pro, realmente o negócio é usar um kernel compatível (que, pelo que você relatou, é só o 4.4). :(
-
Muito obrigado, mestre Sucupira, a ajuda valeu mesmo!!!!! acabei de reiniciar e está tudo BEM!!! Dá gosto de usar!!!! Valeu!!!!
-
Muito obrigado, mestre Sucupira, a ajuda valeu mesmo!!!!! acabei de reiniciar e está tudo BEM!!! Dá gosto de usar!!!! Valeu!!!!
Tudo de volta à normalidade? Assim que é bom, rs. De nada. Missão cumprida. :) Feliz 2017. ;D
-
Sou meio novo no Linux e estou com esse problema que você relatou. Meu notebook é exatamente igual ao seu, mas estou usando o Ubuntu Studio (com kernel 4.4.0-31-lowlatency). Você pode me ajudar!?
-
Sou meio novo no Linux e estou com esse problema que você relatou. Meu notebook é exatamente igual ao seu, mas estou usando o Ubuntu Studio (com kernel 4.4.0-31-lowlatency). Você pode me ajudar!?
Oi, Allan, qual o problema que está ocorrendo?
Bom, vou me adiantar à sua resposta, pois talvez o que eu suspeito que seja a sua dúvida seja realmente a sua dúvida: você está receoso porque meu tutorial diz para instalar o kernel generic, porém o Ubuntu Studio que você está usando veio com o kernel lowlatency? Se a sua dúvida for mesmo essa, no seu caso é recomendável usar mesmo o kernel lowlatency.
Caso o seu sistema seja de 64 bits, os três pacotes que você precisa baixar e instalar são estes:
- linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb)
- linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb)
- linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb)
Caso seu sistema seja de 32 bits, os três pacotes que você precisa baixar e instalar são estes:
- linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb)
- linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb)
- linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb)
-
Sou meio novo no Linux e estou com esse problema que você relatou. Meu notebook é exatamente igual ao seu, mas estou usando o Ubuntu Studio (com kernel 4.4.0-31-lowlatency). Você pode me ajudar!?
Oi, Allan, qual o problema que está ocorrendo?
Bom, vou me adiantar à sua resposta, pois talvez o que eu suspeito que seja a sua dúvida seja realmente a sua dúvida: você está receoso porque meu tutorial diz para instalar o kernel generic, porém o Ubuntu Studio que você está usando veio com o kernel lowlatency? Se a sua dúvida for mesmo essa, no seu caso é recomendável usar mesmo o kernel lowlatency.
Caso o seu sistema seja de 64 bits, os três pacotes que você precisa baixar e instalar são estes:
- linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb)
- linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb)
- linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb)
Caso seu sistema seja de 32 bits, os três pacotes que você precisa baixar e instalar são estes:
- linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb)
- linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb)
- linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb)
Era esse mesmo o problema!!! Funcionou bem (aparentemente)! Vou continuar testando! Muito obrigado!
-
Sou meio novo no Linux e estou com esse problema que você relatou. Meu notebook é exatamente igual ao seu, mas estou usando o Ubuntu Studio (com kernel 4.4.0-31-lowlatency). Você pode me ajudar!?
Oi, Allan, qual o problema que está ocorrendo?
Bom, vou me adiantar à sua resposta, pois talvez o que eu suspeito que seja a sua dúvida seja realmente a sua dúvida: você está receoso porque meu tutorial diz para instalar o kernel generic, porém o Ubuntu Studio que você está usando veio com o kernel lowlatency? Se a sua dúvida for mesmo essa, no seu caso é recomendável usar mesmo o kernel lowlatency.
Caso o seu sistema seja de 64 bits, os três pacotes que você precisa baixar e instalar são estes:
- linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb)
- linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb)
- linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_amd64.deb)
Caso seu sistema seja de 32 bits, os três pacotes que você precisa baixar e instalar são estes:
- linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704_4.7.4-040704.201609150330_all.deb)
- linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-headers-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb)
- linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.4/linux-image-4.7.4-040704-lowlatency_4.7.4-040704.201609150330_i386.deb)
Era esse mesmo o problema!!! Funcionou bem (aparentemente)! Vou continuar testando! Muito obrigado!
Bacana. ;) De nada. :D
-
Era esse mesmo o problema!!! Funcionou bem (aparentemente)! Vou continuar testando! Muito obrigado!
Allan, percebi que o tutorial estava desatualizado: estou há cerca de 2 meses testando o kernel estável 4.7.10 e não tenho tido problema nenhum. Enfim: aproveitei para atualizar o tutorial com os links para download e instalação do kernel estável versão 4.7.10. Também incluí no tutorial os links necessários aos usuários que utilizam kernel de baixa latência, como é o seu caso. :)
PS: sempre que eu me enveredo por um kernel estável mais recente e constato que, mesmo após algumas semanas de uso, esse kernel mais novo não está dando problema, eu volto aqui e atualizo o tutorial.
-
Obrigado! Já estava desistindo de usar Ubuntu no Inspiron-5548 8)
-
Obrigado! Já estava desistindo de usar Ubuntu no Inspiron-5548 8)
De nada, rs. ;D
-
Primeiramente eu preciso te agradecer, já estava morrendo de raiva. Eu tinha instalado o Ubuntu Mate 16.04 no meu notebook Asus. Adorei o Mate, mas o note travava direto. Achei que era culpa do Mate. Formatei o HD e instalei o Ubuntu. Continuou travando feio. Ontem eu criei coragem e segui suas dicas, ficou show de bola!. Muito obrigado mesmo.
Agora vem a dúvida: tenho num outro pc com o debian 8.7 e ele também está congelando de vez em quando. A sua dica de atualização do Kernel dá certo no debian?
Ao digitar o comando uname -ir eu obtenho:
3.16.0-4-686-pae unknown
Ele é genérico ou lowlatency?
Grande abraço.
-
Primeiramente eu preciso te agradecer, já estava morrendo de raiva. Eu tinha instalado o Ubuntu Mate 16.04 no meu notebook Asus. Adorei o Mate, mas o note travava direto. Achei que era culpa do Mate. Formatei o HD e instalei o Ubuntu. Continuou travando feio. Ontem eu criei coragem e segui suas dicas, ficou show de bola!. Muito obrigado mesmo.
Agora vem a dúvida: tenho num outro pc com o debian 8.7 e ele também está congelando de vez em quando. A sua dica de atualização do Kernel dá certo no debian?
Ao digitar o comando uname -ir eu obtenho:
3.16.0-4-686-pae unknown
Ele é genérico ou lowlatency?
Grande abraço.
Oi, de nada. :)
Olha, eu troquei o Debian pelo Ubuntu há mais de dez anos, portanto o que eu sabia de Debian hoje em dia pode não corresponder mais à realidade. Enfim: não garanto que os comandos que vou postar aqui funcionarão no seu Debian atual.
Bom, vamos lá: primeiramente, percebi que o kernel do seu Debian é PAE. Um kernel PAE só deve ser usado em computador que tenha processador de 32 bits e mais de 4 GB de RAM, pois a finalidade do kernel PAE é justamente tentar fazer com que o sistema operacional (que terá de ser de 32 bits) consiga gerenciar mais de 4 GB de RAM (algo que no mundo Windows de 32 bits não ocorre). Em outras palavras: o kernel PAE é um kernel de 32 bits que é usado para "emular" um sistema de 64 bits em um computador de 32 bits. Digo: em tese, somente sistemas de 64 bits conseguem gerenciar mais de 4 GB de RAM, porém com um kernel PAE o Linux de 32 bits consegue gerenciar mais de 4 GB de RAM ( um kernel PAE permite que um sistema operacional Linux de 32 bits gerencie até 64 GB de RAM).
Seu computador usa processador de 32 bits (portanto está com Debian de 32 bits) e, além disso, tem mais de 4 GB de RAM? Se seu computador atende as duas condições, então está correto ele estar com um kernel PAE. No entanto, caso seu computador não atenda a ao menos uma das duas condições, o kernel não deverá ser PAE. Digo: se o processador for de 64 bits, ou caso seu computador tenha 4 GB de RAM ou menos, substitua o kernel PAE por um que não seja PAE. Explicando melhor: caso o seu computador possua processador de 32 bits e 4 GB (ou menos) de RAM, instale um kernel de 32 bits que não seja PAE. E, caso seu computador tenha processador de 64 bits (neste caso pouco importa a quantidade de RAM), instale um kernel de 64 bits.
Para verificar se o processador do seu computador é de 32 bits ou de 64 bits, execute este comando, no terminal:
lscpu
Caso o resultado mostre algo assim (destaquei em azul as partes que interessam):
Arquitetura: x86_64
Modo(s) operacional da CPU:32-bit, 64-bit
...então o processador do seu computador é mesmo de 64 bits.
Caso apareça algo como "x86_32" ou somente "32-bit" lá em "Modo(s) operacional da CPU:", então o processador realmente é de 32 bits.
Seu Debian talvez não tenha o comando lscpu. Em tal caso, execute este outro comando:
cat /proc/cpuinfo |grep -i 'core id'...e verifique o maior número de id (os números poderão se repetir, no resultado, mas o que importa é que você veja qual dos números é o maior). Se no resultado do comando o maior número de "core id" for maior que 0 (zero), como p.ex. 1, 2, 3..., então seu computador possui processador de 64 bits. Mas caso o "core id" seja somente 0 (zero), então seu computador possui processador de 32 bits.
Pelo menos na época em que eu usava o Debian, os kernels por padrão eram "generic": para obter um kernel 'lowlatency" era necessário baixar o código fonte (source) do kernel e então construir os pacotes DEB dele usando uma linha de comando assim:
make -j4 deb-pkg LOCALVERSION=-lowlatency KDEB_PKGVERSION=$(make kernelversion)-1
Exemplo de comandos que poderiam ser usados para construir um kernel de 64 bits (amd64), versão 4.2:
1. Baixar os pacotes necessários para construir o kernel:
sudo apt-get install build-essential fakeroot build-dep linux libncurses5-dev libncursesw5-dev linux-source-4.2 -y2. Descompactar o código fonte do kernel 4.2:
tar -xaf /usr/src/linux-source-4.2.tar.xz3. Acessar a pasta dentro da qual o código fonte foi descompactado, e daí criar dentro dela o arquivo oculto .config, contendo uma cópia das configurações de inicialização do kernel atualmente em uso no sistema do seu computador:
cd /usr/src/linux-source-4.2 ; cp /boot/config-`uname -r` .config4. Inicialize a interface de préconfiguração do código fonte que será compilado:
make menuconfig5. Dentro da interface do menuconfig, habilite a opção preempt e também habilite timers 1000Hz
6. Execute este comando para compilar o código fonte construindo os pacotes DEB:
make -j4 deb-pkg LOCALVERSION=-lowlatency KDEB_PKGVERSION=$(make kernelversion)-17. "Subir" 1 nível de diretório e então instalar os pacotes DEB:
cd .. ; dpkg -i linux-*.deb8. Atualizar o GRUB e reiniciar o sistema operacional:
sudo update-grub ; sudo telinit 6
Repetindo: não garanto que esse procedimento funcione, mas era assim que era feito, antigamente (há mais de 1 década).
Para usar um kernel mais novo, eu no seu lugar instalaria o Debian stretch (Debian 9), que de acordo com esta página (https://packages.debian.org/stretch/kernel/) utiliza o kernerl versão 4.9.0. Grave um Live CD do Debian stretch num DVD (ou num pendrive, usando o programa UNetBootIn (https://unetbootin.github.io/)) e teste esse Live CD no seu computador, para ver como esse kernel se comporta com o hardware desse seu computador. Se tudo funcionar bem, aí você migra para o Debian stretch. Embora seja uma versão "testing", o stretch atualmente está em estado "frozen", o que significa que ele já está praticamente estável (após cerca de 3 anos de desenvolvimento... Ufaaaaaaaa...). ;D
Alternativamente, você pode instalar o Ubuntu nesse outro computador que está com Debian. Uma das razões por que cansei do Debian é que os desenvolvedores são tão "neuróticos" com estabilidade que muitos drivers e kernels de versão mais recente não ficam disponíveis na versão stable / estável. Daí ou você instala uma versão "testing" do Debian, ou então vai para uma distro mais flexível como é o caso da Ubuntu.
Caso queira usar uma versão "peso leve" do Ubuntu, instale o XUbuntu (http://xubuntu.org/) 16.04. É excelente, eu recomendo bastante.
Há tutoriais na Internet dizendo para instalar o kernel do Ubuntu no Debian, porém isso não deve ser feito, já que na prática você estaria transformando seu Debian em um Ubuntu, além de correr o risco de "quebrar" sua distro (ou parte dela), em razão de alguns patches e módulos do kernel Debian poderem não funcionar no kernel Ubuntu.
-
O repositório jessie-backports também tem o Kernel 4.9, assim não precisa atualizar para a versão testing. Basta adicionar a linha (por exemplo) deb http://ftp.br.debian.org/debian/ jessie-backports main no sources.list e instalar o kernel correspondente: linux-image-4.9.0-0.bpo.1-686-pae ou linux-image-4.9.0-0.bpo.1-686. Agora, se for mudar para 64 bits é melhor reinstalar/formatar.
-
O repositório jessie-backports também tem o Kernel 4.9, assim não precisa atualizar para a versão testing. Basta adicionar a linha (por exemplo) deb http://ftp.br.debian.org/debian/ jessie-backports main no sources.list e instalar o kernel correspondente: linux-image-4.9.0-0.bpo.1-686-pae ou linux-image-4.9.0-0.bpo.1-686. Agora, se for mudar para 64 bits é melhor reinstalar/formatar.
Valeu, Anderson, dei uma espiada em https://packages.debian.org/jessie-backports/kernel/ e você tem toda razão, o kernel 4.9 foi "backportado" para o Jessie. Obrigado por essa informação. :)
-
Bom, vamos lá: primeiramente, percebi que o kernel do seu Debian é PAE. Um kernel PAE só deve ser usado em computador que tenha processador de 32 bits e mais de 4 GB de RAM, pois a finalidade do kernel PAE é justamente tentar fazer com que o sistema operacional (que terá de ser de 32 bits) consiga gerenciar mais de 4 GB de RAM (algo que no mundo Windows de 32 bits não ocorre).
Deixe-me explicar melhor: estou usando uma distribuição chamada Emmabuntüs, baseada no Debian 8.5 XFCE (voltado para máquinas antigas). Eu tinha um Ubuntu 16.04 instalado aqui antes, mas o HD deu pau e aí eu pequei o HD que estava com esse sistema, o Emmabuntüs, num Semiprom que tinha apenas 1Gb de memória e coloquei no Dual Core, 1,6 GHz com com 2Gb de memória e funcionou! Nunca vi isso: o sistema está funcionando redondo. Ele tinha travado uma ou duas vezes, mas não travou mais. Ele roda como se tivesse sido instalado nele próprio. Acho que não vou mexer, aquela máxima, "time que está ganhando a gente não mexe", ainda mais que uso ele para trabalhar. :)
De qualquer forma, a sua dica foi muito útil para o meu notebook. Obrigado mais uma vez.
-
Boa tarde, senhores.
Gostaria de uma ajuda. Em junho de 2015, adquiri o notebook Dell Inspiron 5548 com Ubuntu 14.04 LTS (de fábrica), placa gráfica intel/amd radeon r7 m265... nunca havia dado problemas, mas desde dezembro de 2016 começaram os travamentos... não sei se houve atualização de kernel, xorg etc que possa ter iniciado estes travamentos... pensei q fosse hardware, mas li em alguns lugares falando de driver...
O estranho é que este travamento só acontece quando a placa selecionada no Catalyst é a Intel e não a AMD. Noto também que quando seleciono a placa AMD, a temperatura da CPU aumenta, enquanto ao utilizar a Intel, não há grande mudanças.
Desde já agradeço.
-
Boa tarde, senhores.
Gostaria de uma ajuda. Em junho de 2015, adquiri o notebook Dell Inspiron 5548 com Ubuntu 14.04 LTS (de fábrica), placa gráfica intel/amd radeon r7 m265... nunca havia dado problemas, mas desde dezembro de 2016 começaram os travamentos... não sei se houve atualização de kernel, xorg etc que possa ter iniciado estes travamentos... pensei q fosse hardware, mas li em alguns lugares falando de driver...
O estranho é que este travamento só acontece quando a placa selecionada no Catalyst é a Intel e não a AMD. Noto também que quando seleciono a placa AMD, a temperatura da CPU aumenta, enquanto ao utilizar a Intel, não há grande mudanças.
Desde já agradeço.
Atualmente, você tem duas opções:
1) Instalar o *Ubuntu 16.04 "Xenial Xerus" e atualizar o kernel para a versão 4.7.10, como atualmente explicado neste tutorial; ou
2) Instalar o *Ubuntu 16.10 "Yakkety Yak", que já vem com um kernel mais recente (versão 4.8, se não me engano).
Parece que a AMD está desenvolvendo a próxima versão do driver proprietário fglrx, mas no seu Ubuntu 14.04 não há suporte nem para o próximo fglrx nem para o driver open source. Se os travamentos estão ocorrendo, você realmente precisa atualizar esse sistema aí.
-
Deixe-me explicar melhor: estou usando uma distribuição chamada Emmabuntüs, baseada no Debian 8.5 XFCE (voltado para máquinas antigas). Eu tinha um Ubuntu 16.04 instalado aqui antes, mas o HD deu pau e aí eu pequei o HD que estava com esse sistema, o Emmabuntüs, num Semiprom que tinha apenas 1Gb de memória e coloquei no Dual Core, 1,6 GHz com com 2Gb de memória e funcionou! Nunca vi isso: o sistema está funcionando redondo. Ele tinha travado uma ou duas vezes, mas não travou mais. Ele roda como se tivesse sido instalado nele próprio. Acho que não vou mexer, aquela máxima, "time que está ganhando a gente não mexe", ainda mais que uso ele para trabalhar. :)
De qualquer forma, a sua dica foi muito útil para o meu notebook. Obrigado mais uma vez.
Bacana. :) De nada.
-
Pessoal,
Eu estava com os mesmos problemas relatados pelos colegas anteriormente aqui no fórum.
Acontecia com muita frequência de fechar a tampa do notebook e depois quando eu abria a tela não ligava mais e eu tinha que reiniciar tudo a força.
Aparentemente este problema foi resolvido com a mudança do kernel, como "tutoriado" aqui.
Agora, com outros problemas não vi tanta melhora.
Explicando:
Trabalho usando dois monitores, o do próprio PC e um acessório ligado por conexão vga. Quando só o do PC está ligado funciona até bem, quando o acessório está ligado trava um pouco, e quando os dois estão ligados trava muito.
Percebo os problemas de diversas maneiras, no movimento do cursor do mouse, rolando uma página de fotos da web, abrindo fotos do PC com o visualizador de imagens, abrindo fotos com o GIMP (trava muito esse), até mesmo rolando páginas de um PDF.
Só pra esclarecer, estou me referindo como travar, mas por vezes isso é uma lentidão na resposta.
Gostaria então de saber se isso é problema com o driver da placa de vídeo e se tem como solucionar.
___________________________________
Meu notebook é um Dell inspiron 5448, com processador i5, 4 gb de ram e uma placa de vídeo AMD radeon m265.
Estou usando o Xubuntu 16.04 e acabei de atualizar o kernel pra versão 4.7.10
Agradeço qualquer ajuda
-
Pessoal,
Eu estava com os mesmos problemas relatados pelos colegas anteriormente aqui no fórum.
Acontecia com muita frequência de fechar a tampa do notebook e depois quando eu abria a tela não ligava mais e eu tinha que reiniciar tudo a força.
Aparentemente este problema foi resolvido com a mudança do kernel, como "tutoriado" aqui.
Agora, com outros problemas não vi tanta melhora.
Explicando:
Trabalho usando dois monitores, o do próprio PC e um acessório ligado por conexão vga. Quando só o do PC está ligado funciona até bem, quando o acessório está ligado trava um pouco, e quando os dois estão ligados trava muito.
Percebo os problemas de diversas maneiras, no movimento do cursor do mouse, rolando uma página de fotos da web, abrindo fotos do PC com o visualizador de imagens, abrindo fotos com o GIMP (trava muito esse), até mesmo rolando páginas de um PDF.
Só pra esclarecer, estou me referindo como travar, mas por vezes isso é uma lentidão na resposta.
Gostaria então de saber se isso é problema com o driver da placa de vídeo e se tem como solucionar.
___________________________________
Meu notebook é um Dell inspiron 5448, com processador i5, 4 gb de ram e uma placa de vídeo AMD radeon m265.
Estou usando o Xubuntu 16.04 e acabei de atualizar o kernel pra versão 4.7.10
Agradeço qualquer ajuda
Embora meu notebook seja exatamente o mesmo que o seu, eu não tenho um monitor externo para poder simular o problema que você está vivenciando. De qualquer modo, existem algumas possibilidades para o porquê de isso estar ocorrendo, entre elas:
1) Limitação do driver de vídeo.
2) Excesso de monitores virtuais.
3) Má configuração do servidor Xorg.
Não há muito o que se possa fazer a respeito de 1, exceto talvez atualizar o *Ubuntu para a última versão disponível (17.04) caso ela funcione com novas versões dos drivers de vídeo i915 e amdgpu-pro. Como eu uso XUbuntu 16.04 e não li nada a respeito da versão 17.04, estou completamente "por fora" das novidades trazidas pela versão 17.04, por isto vou seguir para a hipótese 2 e sugerir que você reduza a quantidade de monitores virtuais para algo entre 4 e 2 (caso você esteja com mais de 4 monitores virtuais ativados), pois quando você conecta um monitor externo ao computador o servidor Xorg do seu sistema Linux cria, no monitor externo, a mesma quantidade de monitores virtuais que existem no monitor do seu computador, o que significa que se p.ex. houver 8 monitores virtuais, então quando você conectar o monitor externo seu sistema passará a operar com 16 monitores virtuais, e isso requer bastante poder de processamento gráfico, além de poder "amplificar" um eventual problema de baixo desempenho porventura causado por algum dos drivers de vídeo (item 1).
Se após você reduzir a quantidade de monitores virtuais e reiniciar o computador a lentidão persistir, reduza a quantidade de monitores virtuais para 2 e reinicie novamente o computador.
Caso o problema persista, talvez a hipótese 3 seja a causa. Uma solução que funciona em alguns casos dessa hipótese (não tenho como garantir que funcionará no seu caso) consiste em seguir os seguintes passos:
i) Primeiramente, verifique se você tem o GEdit instalado e, em caso negativo, instale-o com este comando:
sudo apt-get install gedit -y
ii) Em seguida, acesse a pasta /etc/X11/xorg.conf.d/ ou então crie-a, caso ela não exista. Um comando que você pode executar no terminal para fazer isso é este:
if [ ! -d /etc/X11/xorg.conf.d ]; then sudo mkdir /etc/X11/xorg.conf.d; fi
iii) Uma vez que você tenha o editor de textos GEdit instalado e a pasta /etc/X11/xorg.conf.d exista, verifique se dentro de /etc/X11/xorg.conf.d/ existe algum arquivo cujo nome termine com intel.conf. Em caso afirmativo (se o arquivo existir), esse arquivo deverá ser aberto para edição. Em caso negativo (se o arquivo não existir), ele deverá ser criado com o nome padrão 20-intel.conf. Para fazer essa verificação e já abrir (ou criar e em seguida abrir) o arquivo para edição, execute o seguinte supercomando, no terminal do shell:
if [ -f /etc/X11/xorg.conf.d/20-intel.conf ]; then sudo gedit /etc/X11/xorg.conf.d/20-intel.conf; elif [ $(sudo updatedb ; locate -i intel.conf |grep /etc/X11/xorg.conf.d |head -1) = $() ]; then sudo gedit /etc/X11/xorg.conf.d/20-intel.conf; else sudo gedit $(sudo updatedb ; locate -i intel.conf |grep /etc/X11/xorg.conf.d |head -1); fi
iv) Uma vez que o arquivo *-intel.conf esteja aberto no editor GEdit, proceda como segue:
iv-i) Caso o arquivo já possua algum código, adicione o seguinte código antes (acima) da linha EndSection: Option "VSync" "false":
Section "Device"
Identifier "Intel"
Driver "intel"
Option "VSync" "false"
EndSectioniv-ii) Caso o arquivo não possua nenhum código (esteja em branco), ou ainda caso a linha EndSection: Option "VSync" "false" não exista dentro do arquivo que já contém algum código, vá até o topo (início) do arquivo e adicione o código mostrado em iv-i.
v) Salve o arquivo (vá em Arquivo e clique em Salvar, ou então use a combinação de teclas Ctrl S), em seguida feche o GEdit e reinicie o computador.
vi) Teste se o problema com o monitor externo continua ocorrendo. Caso o problema persista, execute novamente o supercomando do item iii (para voltar ao arquivo que você havia editado), então adicione as seguintes linhas de código ao início (topo) do arquivo:
Option"TripleBuffer" "True"
Option"BackingStore" "True"
Option "PixmapCacheSize" "300000"
Option "OnDemandVBlankInterrupts" "True"
Option "InitialPixmapPlacement" "2"
Option "GlyphCache" "1"
...e daí execute novamente as ações do item v.
Se nada disso resolver, não sei como ajudar. :P
-
Placa mãe Intel onboard HD2500
Xubuntu 16.04.03
Kernell atual : 4.10.0-38-generic
Não consegui mudar o kernell , mesmo seguindo o tutorial por completo , incluindo a desabilitação do KMS na tela de boot do Grubs . A instalação dos pacotes Debs aparentemente ocorre normal , mas quando reinicio e digito : uname -ir , o kernell não mudou .
Tentei com outras distros como o xubuntu 17 e o Ubuntu Mate , mas sem sucesso também .
Meu problema está descrito https://ubuntuforum-br.org/index.php/topic,122321.0.html (https://ubuntuforum-br.org/index.php/topic,122321.0.html) , porém até agora não encontrei uma solução para o meu caso .
-
Placa mãe Intel onboard HD2500
Xubuntu 16.04.03
Kernell atual : 4.10.0-38-generic
Não consegui mudar o kernell , mesmo seguindo o tutorial por completo , incluindo a desabilitação do KMS na tela de boot do Grubs . A instalação dos pacotes Debs aparentemente ocorre normal , mas quando reinicio e digito : uname -ir , o kernell não mudou .
Tentei com outras distros como o xubuntu 17 e o Ubuntu Mate , mas sem sucesso também .
Meu problema está descrito https://ubuntuforum-br.org/index.php/topic,122321.0.html (https://ubuntuforum-br.org/index.php/topic,122321.0.html) , porém até agora não encontrei uma solução para o meu caso .
Se o kernel 4.7.10 foi instalado corretamente, ele pode ser inicializado. Provavelmente, o que está ocorrendo é que o GRUB está, por padrão, automaticamente inicializando (boot) o kernel mais recente disponível, que no seu caso é o kernel versão 4.10.0.
Eu fiz o tutorial deste tópico numa ocasião em que o kernel 4.7.10 era bem mais novo que os kernels que estavam vindo nas distribuições *Ubuntu. Atualmente, porém, as distribuições mais novas estão vindo com kernels das séries 4.9 e 4.10 ou mais recentes (no momento em que estou publicando esta mensagem, a mais recente versão estável do kernel Linux é da série 4.13). Como da instalação de um kernel mais novo na distribuição *Ubuntu resulta o GRUB sendo configurado para, por padrão, executar esse kernel mais novo, se o kernel da sua distribuição for de uma versão anterior à 4.7.10, ao instalar o kernel 4.7.10 o seu sistema passará a executar o kernel 4.7.10. Mas, como você está usando uma distribuição que já está com kernel mais recente que o 4.7.10, o GRUB não está inicializando o kernel 4.7.10, mas sim dando preferência ao kernel mais recente que se encontra instalado.
Há como configurar o GRUB para, por padrão, inicializar outro kernel, como p.ex. o 4.7.10. No entanto, como não sabemos se esse kernel 4.7.10 vai lhe atender, o ideal, num primeiro momento, é apenas inicializar o sistema com o kernel 4.7.10 (sem defini-lo como padrão) e usar o computador com esse kernel em execução, para verificar se de fato o kernel resolve o problema que você está vivenciando.
Para isso, é necessário editar o arquivo de configuração do GRUB. Você tem o gedit (GNOME Edit) instalado? Caso não tenha, execute este comando no terminal do shell do Linux, para instalar o gedit:
sudo apt-get install gedit -y
Uma vez que o gedit esteja instalado, execute o comando abaixo para fazer o gedit abrir o arquivo de configuração do GRUB para edição:
sudo gedit /etc/default/grub
Modifique o teor do arquivo grub, de modo que ele tenha/passe a ter as 4 linhas de código abaixo, exatamente como mostradas:
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
O parâmetro GRUB_DEFAULT serve para informar ao GRUB qual opção de inicialização deverá ser usada. O argumento (valor) padrão desse parâmetro é 0. Essa opção é modificada para instruir o GRUB a p.ex. inicializar outro kernel, por padrão. Mas no momento nós não vamos mexer nisso.
Os dois parâmetros seguintes precisam ser desabilitados (aquele caractere # no início de cada linha desabilita as duas linhas e seus parâmetros). Isso evita que o GRUB esconda o menu dele. Consequentemente, quando você reiniciar o computador o menu do GRUB aparecerá, para você poder escolher qual kernel quer inicializar.
O parâmetro GRUB_TIMEOUT serve para definir por quantos segundos o menu do GRUB deverá ficar visível para você escolher o que deseja inicializar. Se você não selecionar uma das opções disponíveis no menu, após N segundos o GRUB selecionará a opção padrão definida em GRUB_DEFAULT. Como no código acima o argumento do parâmetro GRUB_TIMEOUT é 10, o menu aparecerá para você durante 10 segundos: após isso, o GRUB automaticamente inicializará o kernel padrão do seu sistema.
Após efetuar as alterações acima, salve o arquivo e feche o gedit. Agora de volta ao terminal do shell, execute o comando abaixo para que as modificações que você fez sejam aplicadas ao GRUB:
sudo update-grub
Reinicie o computador. Quando o menu do GRUB aparecer, use as teclas direcionais ("seta pra cima" ⬆ e "seta pra baixo" ⬇) para selecionar o kernel 4.7.10 (deverá ser uma opção como p.ex. Ubuntu, com o Linux 4.7.10-040710-generic) e então pressione a tecla Enter para confirmar. Após isso, o Linux será inicializado com o kernel 4.7.10. Faça os testes que estiver querendo fazer e verifique se deu certo.
Doravante, sempre que você instalar outros kernels e reiniciar o computador, o menu do GRUB aparecerá e lhe dará 10 segundos para que você possa selecionar uma opção de boot / inicialização.
Caso esteja com o sistema em execução e queira saber quais são todas as opções que o menu do GRUB atualmente possui, retorne ao terminal do shell, digite o comando grub-set-default e então pressione a tecla TAB (https://www.informationq.com/wp-content/uploads/2013/10/Tab-Key.jpg) três vezes.
No meu computador, por exemplo, as opções que aparecem são estas:
Opções avançadas para Ubuntu
System setup
Ubuntu
Ubuntu, com o Linux 4.7.10-040710-generic
Ubuntu, com o Linux 4.7.1-040701-generic
Ubuntu, com o Linux 4.7.2-040702-generic
Ubuntu, com o Linux 4.7.4-040704-generic
Ubuntu, with Linux 4.7.10-040710-generic (recovery mode)
Ubuntu, with Linux 4.7.10-040710-generic (upstart)
Ubuntu, with Linux 4.7.1-040701-generic (recovery mode)
Ubuntu, with Linux 4.7.1-040701-generic (upstart)
Ubuntu, with Linux 4.7.2-040702-generic (recovery mode)
Ubuntu, with Linux 4.7.2-040702-generic (upstart)
Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)
Ubuntu, with Linux 4.7.4-040704-generic (upstart)...em que as três primeiras opções, de cima para baixo, são as que aparecem para mim, no menu do GRUB. E, quando eu estou no menu do GRUB e seleciono Opções avançadas para Ubuntu, surge um submenu que começa com Ubuntu, com o Linux 4.7.10-040710-generic e termina com Ubuntu, with Linux 4.7.4-040704-generic (upstart). No caso, o primeiro item desse submenu (intitulado Ubuntu, com o Linux 4.7.10-040710-generic) é o que possui ID = 0. Portanto, como o GRUB do meu sistema Linux está configurado com GRUB_DEFAULT=0, toda vez em que eu ligo ou reinicio o computador o GRUB automaticamente seleciona a opção zero (ID = 0) por padrão (default), e, consequentemente, inicializa o kernel 4.7.10-040710-generic em "modo normal", que é o modo multiusuário. ;) Os outros modos de inicialização de um mesmo kernel são "recovery mode", que serve para fazer o kernel inicializar o Linux em modo de recuperação (que é um modo monousuário: somente a conta root estará ativa), e o modo "upstart", em que o kernel utiliza o daemon ("serviço") upstart no lugar do padrão, que é o daemon init.
-
Placa mãe Intel onboard HD2500
Xubuntu 16.04.03
Kernell atual : 4.10.0-38-generic
Não consegui mudar o kernell , mesmo seguindo o tutorial por completo , incluindo a desabilitação do KMS na tela de boot do Grubs . A instalação dos pacotes Debs aparentemente ocorre normal , mas quando reinicio e digito : uname -ir , o kernell não mudou .
Tentei com outras distros como o xubuntu 17 e o Ubuntu Mate , mas sem sucesso também .
Meu problema está descrito https://ubuntuforum-br.org/index.php/topic,122321.0.html (https://ubuntuforum-br.org/index.php/topic,122321.0.html) , porém até agora não encontrei uma solução para o meu caso .
Doravante, sempre que você instalar outros kernels e reiniciar o computador, o menu do GRUB aparecerá e lhe dará 10 segundos para que você possa selecionar uma opção de boot / inicialização.
Caso esteja com o sistema em execução e queira saber quais são todas as opções que o menu do GRUB atualmente possui, retorne ao terminal do shell, digite o comando grub-set-default e então pressione a tecla TAB (https://www.informationq.com/wp-content/uploads/2013/10/Tab-Key.jpg) três vezes.
No meu computador, por exemplo, as opções que aparecem são estas:
Opções avançadas para Ubuntu
System setup
Ubuntu
Ubuntu, com o Linux 4.7.10-040710-generic
Ubuntu, com o Linux 4.7.1-040701-generic
Ubuntu, com o Linux 4.7.2-040702-generic
Ubuntu, com o Linux 4.7.4-040704-generic
Ubuntu, with Linux 4.7.10-040710-generic (recovery mode)
Ubuntu, with Linux 4.7.10-040710-generic (upstart)
Ubuntu, with Linux 4.7.1-040701-generic (recovery mode)
Ubuntu, with Linux 4.7.1-040701-generic (upstart)
Ubuntu, with Linux 4.7.2-040702-generic (recovery mode)
Ubuntu, with Linux 4.7.2-040702-generic (upstart)
Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)
Ubuntu, with Linux 4.7.4-040704-generic (upstart)...em que as três primeiras opções, de cima para baixo, são as que aparecem para mim, no menu do GRUB. E, quando eu estou no menu do GRUB e seleciono Opções avançadas para Ubuntu, surge um submenu que começa com Ubuntu, com o Linux 4.7.10-040710-generic e termina com Ubuntu, with Linux 4.7.4-040704-generic (upstart). No caso, o primeiro item desse submenu (intitulado Ubuntu, com o Linux 4.7.10-040710-generic) é o que possui ID = 0. Portanto, como o GRUB do meu sistema Linux está configurado com GRUB_DEFAULT=0, toda vez em que eu ligo ou reinicio o computador o GRUB automaticamente seleciona a opção zero (ID = 0) por padrão (default), e, consequentemente, inicializa o kernel 4.7.10-040710-generic em "modo normal", que é o modo multiusuário. ;) Os outros modos de inicialização de um mesmo kernel são "recovery mode", que serve para fazer o kernel inicializar o Linux em modo de recuperação (que é um modo monousuário: somente a conta root estará ativa), e o modo "upstart", em que o kernel utiliza o daemon ("serviço") upstart no lugar do padrão, que é o daemon init.
Obrigado pela aula e pelas informações !
Nem me ocorreu de ter pensado em entrar nas opções avançadas do xubuntu na tela do
Grubs ! Estava tudo lá certinho , desde o começo ! :)
Mas em relação aos Kernels antigos , pelo que vi , esse 4.7.10 já é ultrapassado e pode ter algum problema
em relação á alguma brecha de segurança ?
Ainda vou testar , pra ver como vai se portar . Mas acredito que o problema não é de Hardware , pois
eu uso o Windows7 também no mesmo pc e nunca deu esse tipo de problema . Só a placa mãe que é meio antiga "2011/2012" .
-
Obrigado pela aula e pelas informações !
Nem me ocorreu de ter pensado em entrar nas opções avançadas do xubuntu na tela do
Grubs ! Estava tudo lá certinho , desde o começo ! :)
Mas em relação aos Kernels antigos , pelo que vi , esse 4.7.10 já é ultrapassado e pode ter algum problema
em relação á alguma brecha de segurança ?
Ainda vou testar , pra ver como vai se portar . Mas acredito que o problema não é de Hardware , pois
eu uso o Windows7 também no mesmo pc e nunca deu esse tipo de problema . Só a placa mãe que é meio antiga "2011/2012" .
De nada. ;)
Eu uso o XUbuntu 16.04, que é uma versão LTS (Long Term Support => Suporte de Longo Termo). No caso, o suporte é de 5 anos. Como o XUbuntu 16.04 é de abril de 2016, o suporte dele vai até abril de 2021. A versão 16.04 é denominada Xenial Xerus (ou simplesmente xenial) e os kernels da versão xenial são os kernels da série 4.4, conforme ilustrado aqui (https://wiki.ubuntu.com/Kernel/Support#Ubuntu_Kernel_Release_Schedule). No suporte denominado LTS está incluída a garantia de atualização do kernel, o que significa que todas as correções importantes que forem efetuadas nos kernels mais novos serão "backportadas" para o kernel versão 4.4 do XUbuntu 16.04, durante esse período de 5 anos de suporte. Digo: se, por exemplo, o kernel 4.10 corrigir um bug que existia no kernel 4.4.9, essa correção do kernel 4.10 será aplicada no kernel 4.4.9 e então será lançada a versão 4.4.10 (o kernel 4.4.9 continuará com o bug, porém uma versão do kernel 4.4.9 sem o bug será lançada com o número de série/versão 4.4.10).
Você pode ver a lista de kernels da série 4.4 neste link (http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=M). Ao abrir esse link, procure pela palavra xenial que você verá uma extensa lista de kernels que começa com o kernel 4.4.9-xenial e termina com o kernel 4.4.95, lançado em 27/10/2017. Observe que, decorrido 1 ano e meio do lançamento do *Ubuntu 16.04, o kernel 4.4 já passou por 86 atualizações (já foram lançadas 86 novas versões, dentro da série 4.4). Isso ocorre porque correções presentes em kernels mais novos estão sendo "backportadas", ou seja, aplicadas em kernels mais antigos, para beneficiar esses kernels.
Claro: no Xubuntu 16.04.1 o kernel não deixa de ser sempre o 4.4 (a menos que você manualmente instale um kernel de uma série mais nova). Como consta aqui (https://wiki.ubuntu.com/Kernel/Support#A16.04.x_Ubuntu_Kernel_Support), se você instalou o XUbuntu 16.04.0 ou 16.04.1, então o kernel que veio instalado nele é da série 4.4, mas se você instalou o XUbuntu 16.04.2 então o kernel que veio instalado nele é da série 4.8, ao passo que na versão 16.04.3 o kernel usado será da mesma série em uso no *Ubuntu 17.04, na versão 16.04.4 o kernel será da série do *Ubuntu 17.10, e na versão 16.04.5 o kernel será da mesma série que a usada no *Ubuntu 18.04.
O que eu quero dizer com tudo isso é que, mesmo que você esteja usando um kernel 4.4, ele está sendo atualizado de tempos em tempos, pois sua distribuição versão 16.04 é LTS, tem suporte até o ano 2021. O que muda é que se você estiver com um kernel como p.ex. da série 4.10 então o kernel não apenas terá as correções mais novas (que foram "backportadas" para kernels mais antigos, como p.ex. os da série 4.4), mas também o kernel 4.10 terá todas as melhorias de código que foram implementadas para esse kernel poder funcionar com drivers mais novos, executar novas funções etc. Isso significa que embora não haja um problema crítico ou risco/perigo em usar um kernel 4.4 apenas por ser um kernel 4.4 (já que ele ainda está dentro do período LTS dele, e portanto está recebendo as correções que são "backportadas" dos kernels mais novos para os mais antigos), ao usar um kernel posterior ao 4.4 você estará usando um kernel que contém novos recursos, e isso pode ser bom (ou pode ser ruim, pois novos recursos podem trazer também novos bugs).
Então, no fim das contas, acredito que se o kernel que veio com sua distribuição é posterior ao da série 4.7 mas está dando algum problema em seu computador, é uma boa você testar o kernel 4.7. Às vezes, fazer uma "regression" (adotar um kernel de série ou versão anterior à que está sendo usada pela sua distribuição) pode livrá-lo de algum bug sem necessariamente subtrair algum recurso, ou então subtraia um recurso de que você no entanto não necessita, pois está disponível no kernel mais novo porém seu computador não necessita desse novo recurso presente no kernel mais novo.
Como é muito complicado saber detalhadamente as diferenças entre os kernels (cada kernel tem literalmente milhões - cerca de 15 milhões de - linhas de código, então imagine comparar os códigos de 2 kernels...), a maneira mais prática de saber qual kernel lhe atenderá melhor é instalar uma versão de kernel imediatamente mais nova que a disponível em sua distribuição. Caso ela não dê certo, instale uma versão imediatamente posterior à mais recente que você instalou no sistema, e então adote-a como padrão caso ela funcione como esperado ou então descarte-a caso contrário (e, neste caso, repita o procedimento de instalar um kernel de uma versão imediatamente mais nova, até eventualmente chegar a um kernel mais novo que efetivamente funcione com seu computador). É tentativa e erro. E, contanto que se trate de kernel estável de versão LTS que ainda está sendo suportada (como é o caso das versões 16.04 e 17.04, atualmente: as versões lançadas em outubro, que são as que terminam com .10, não são LTS: têm suporte de apenas 9 meses: tempo suficiente apenas para fazer um filho, rs ;D), não há por que se preocupar com falhas de segurança, por exemplo, pois falhas de segurança encontradas em kernels mais novos são "backportadas" para todos os kernels que sejam afetados pela tal falha e ainda se encontrem dentro do ciclo de vida LTS deles. ;)
Eu não sei qual versão do XUbuntu exatamente você instalou aí (16.04.0, 16.04.1, 16.4.2, 16.04.3 etc.), mas olhe lá o gráfico que lhe enviei, para saber qual a versão padrão de kernel que veio na sua distribuição (caso você não saiba e não consiga ver isso no sistema porque já desinstalou os kernels originais), e daí vá testando kernels mais novos. Se porventura os kernels mais novos não resolverem seu problema e você chegar à última (mais recente) versão de kernel disponível sem conseguir se livrar do problema que esteja afetando seu sistema, aí inicie a "regression", ou seja, comece a testar kernels de versões anteriores à versão do kernel que veio instalado por padrão, na sua distribuição Linux.
-
Eu não sei qual versão do XUbuntu exatamente você instalou aí (16.04.0, 16.04.1, 16.4.2, 16.04.3 etc.), mas olhe lá o gráfico que lhe enviei, para saber qual a versão padrão de kernel que veio na sua distribuição (caso você não saiba e não consiga ver isso no sistema porque já desinstalou os kernels originais), e daí vá testando kernels mais novos. Se porventura os kernels mais novos não resolverem seu problema e você chegar à última (mais recente) versão de kernel disponível sem conseguir se livrar do problema que esteja afetando seu sistema, aí inicie a "regression", ou seja, comece a testar kernels de versões anteriores à versão do kernel que veio instalado por padrão, na sua distribuição Linux.
Valeu ! Estou usando há quase uma semana sem problemas . Ás vezes acontece um leve travamento quando estou com muitas janelas do navegador abertos . Mas dura apenas 1 segundos só no Navegador . Mas travar , rebootar ou sair e voltar de uma sessão , nunca mais aconteceu !
Só tenho uma dúvida pois quando entro em opções avançadas no Grubs e clico na opção 4.7.10 , aparece uma mensagem do tipo "Failed to find cpu0 device node" durante o boot Isso é normal ?
A versão do Kernel original que veio no Xubuntu 16.04 é a 4.10.38
-
Valeu ! Estou usando há quase uma semana sem problemas . Ás vezes acontece um leve travamento quando estou com muitas janelas do navegador abertos . Mas dura apenas 1 segundos só no Navegador . Mas travar , rebootar ou sair e voltar de uma sessão , nunca mais aconteceu !
Só tenho uma dúvida pois quando entro em opções avançadas no Grubs e clico na opção 4.7.10 , aparece uma mensagem do tipo "Failed to find cpu0 device node" durante o boot Isso é normal ?
A versão do Kernel original que veio no Xubuntu 16.04 é a 4.10.38
De nada. :)
Quanto ao erro Failed to find cpu0 device node, na verdade não é um problema: isso é apenas uma mensagem de alerta de uma das camadas internas do kernel. Tendo em vista que os kernels de arquitetura i686 possuem o parâmetro CONFIG_OF habilitado (para o kernel ser capaz de detectar árvores de dispositivos dentro do computador) mas o software do circuito do seu computador não possui tal árvore, surge essa mensagem de erro (o kernel não encontra a árvore e aí emite a mensagem de alerta). Enfim: essa mensagem é inofensiva, pois não há nada de errado: embora o kernel seja capaz de funcionar com computadores que informam a árvore de dispositivos, o kernel não precisa dessa árvore para poder funcionar (tanto que está funcionando normalmente, no seu computador). ;)
Quanto aos travamentos (que na verdade não são travamentos em si: apenas quedas de desempenho) que ocorrem com navegadores web e outros aplicativos, isso em parte está relacionado aos próprios aplicativos e às bibliotecas que utilizam (demandam mais recursos que o computador é capaz de fornecer no momento), e em outra parte deve-se a limitações de desempenho do próprio driver amdgpu/radeon durante o processamento de gráficos 3D. Não é um problema, apenas uma limitação de desempenho do seu computador com esses aplicativos, e também uma limitação de implementação tanto dos aplicativos quanto do driver gráfico. A causa dos reais travamentos (kernel panics) foi eliminada, e é por isso que o sistema não está mais congelando (a ponto de você ter de desligar o computador "no dedo"): isso não vai mais acontecer. :D
-
Olá! belo tutorial!
Eu consegui baixar e instalar tudo. O problema foi na hora de testar e aparecia o kernel 4.10.
Mesmo assim, depois eu consegui ver as engrenagens rodando. nao demorou muito, o computador travou e teve que rolar um dedoff. :(
o que pode ser? refiz os passos 3 vzs e deu o mesmo resultado.
-
Olá! belo tutorial!
Eu consegui baixar e instalar tudo. O problema foi na hora de testar e aparecia o kernel 4.10.
Mesmo assim, depois eu consegui ver as engrenagens rodando. nao demorou muito, o computador travou e teve que rolar um dedoff. :(
o que pode ser? refiz os passos 3 vzs e deu o mesmo resultado.
Oi, tthanny. Obrigado pelo elogio ao tutorial. :)
Seu caso parece ser o mesmo relatado pelo usuário marcos90. Consequentemente, recomendo seguir as dicas que publiquei na resposta 33 (https://ubuntuforum-br.org/index.php/topic,120620.msg672814.html#msg672814). :)
-
Galera, segui os tutoriais indicados (o primeiro e o da resposta 33 q contém a atualização do kernel 4.10.0) e ainda não consegui solucionar o problema de travamento do meu pc... :(
Sou marinheira de primeira viagem com o Linux e to tentando me entender com esse sistema, sendo muito persistente pra não desistir dele e voltar pro windows. Então, conto com ajuda de vcs pra me da um apoio rs.
Tentei fazer os últimos passos (da resp 33) umas 3 vezes. Na primeira instalei o gedit, porém não consegui fazer o gedit abrir o arquivo de configuração do GRUB para edição (aparece a msg de "comando não encontrado", sendo que digitei tudo certinho!)
Nas outras vezes que tentei refazer os passos, a mesma mensagem se repete e não consigo dar boot na minha máquina com opção de escolha entre o kernel 4.10.0 e o 4.7.10 e o travamento persiste (não consigo abrir o mozila pra copiar as msg que aparece pq é a partir disso q ele trava).
Por favor me ajudem, pq depois disso ainda tenho que resolver o problema do wireless que não ta sendo reconhecido e fico com uma dificuldade imensa de usar esse PC!!
-
Galera, segui os tutoriais indicados (o primeiro e o da resposta 33 q contém a atualização do kernel 4.10.0) e ainda não consegui solucionar o problema de travamento do meu pc... :(
Oi, Izabela. A provável razão disso é que seu sistema ainda está usando o kernel versão 4.10 ou outro que não seja o 4.7. Você chegou a executar o comando uname -r para ver qual kernel está em execução? Se a resposta desse comando não iniciar por 4.7.10, seu sistema Linux continua, por padrão, executando um kernel de uma versão mais recente que a 4.7.10, sendo essa a mais provável razão para os problemas de travamento.
No entanto, caso o comando uname -r informe que o kernel 4.7.10 está em execução, então o problema é outro, provavelmente não está relacionado à GPU da AMD.
Sou marinheira de primeira viagem com o Linux e to tentando me entender com esse sistema, sendo muito persistente pra não desistir dele e voltar pro windows. Então, conto com ajuda de vcs pra me da um apoio rs.
Este (http://g1.globo.com/jornal-nacional/noticia/2017/05/ataque-hacker-atingiu-computadores-em-quase-100-paises-na-sexta.html) é um exemplo de problema bem maior que esse do kernel, que você poderia ter caso ainda usasse Windows. ;D
Tentei fazer os últimos passos (da resp 33) umas 3 vezes. Na primeira instalei o gedit, porém não consegui fazer o gedit abrir o arquivo de configuração do GRUB para edição (aparece a msg de "comando não encontrado", sendo que digitei tudo certinho!)
Se o sistema respondeu que o comando não foi encontrado, então ou (1) você cometeu um erro de digitação ou então (2) o GEdit não foi instalado.
Sugestão: use o ponteiro do mouse (ou do touchpad ou clickpad do notebook, caso esteja em um notebook e o notebook esteja sem mouse) para selecionar o código do primeiro comando mostrado lá na resposta 33 (https://ubuntuforum-br.org/index.php/topic,120620.msg672814.html#msg672814) (comando de instalação do GEdit); em seguida, clique com o botão direito sobre esse código selecionado e, no menu que surgir, selecione a opção "Copiar"; em seguida, abra uma janela do emulador de terminal, clique sobre ela com o botão direito e, no menu que surgir, selecione a opção "Colar". Deste modo, você se certifica de que o comando foi corretamente copiado da página e colado no terminal do shell. Certifique-se de que não haja nenhum espaço em branco no início do comando. E observe que deve haver um (mas somente um) espaço em branco entre as palavras sudo e apt-get, assim como também deve haver um (mas somente um) espaço em branco entre as palavras apt-get e install, entre install e gedit, e entre gedit e -y.
Após colar o comando no emulador de terminal do shell Linux e se certificar de que o comando foi colado direitinho, pressione a tecla Enter para que o comando seja executado. Ele pedirá sua senha: digite a senha que você usa para efetuar login na interface gráfica e então pressione a tecla Enter para confirmar. Se durante a digitação da senha (antes de confirmar a senha com Enter) você cometer algum erro de digitação da senha, use a combinação de teclas Ctrl U: isso fará com que o campo senha seja "esvaziado". Após usar a combinação de teclas Ctrl U, digite novamente a sua senha e então pressione a tecla Enter.
Em seguida, repita o procedimento acima (de "copiar e colar" o comando e então executá-lo com a tecla Enter) para o segundo comando (o que usa o GEdit para editar o arquivo de configuração do GRUB), certificando-se de que haja um (mas somente um) espaço em branco entre as palavras sudo e gedit, idem entre as palavras gedit e /etc/default/grub
Nas outras vezes que tentei refazer os passos, a mesma mensagem se repete e não consigo dar boot na minha máquina com opção de escolha entre o kernel 4.10.0 e o 4.7.10 e o travamento persiste (não consigo abrir o mozila pra copiar as msg que aparece pq é a partir disso q ele trava).
Se o sistema não estiver usando o kernel 4.7.10 (ou se estiver mas o problema não for relacionado à GPU AMD), o problema vai continuar ocorrendo. Mas, pelo que você está relatando, o mais provável é que o kernel 4.7.10 esteja instalado mas não esteja em execução.
Caso você continue tendo problemas ao tentar instalar o GEdit e usá-lo para editar o arquivo de configuração do GRUB, faça o seguinte: reinicie o computador e, assim que ele for iniciar o boot do Linux (o que ocorre logo após a tela inicial da BIOS do computador), pressione a tecla Esc (Escape) algumas vezes. Isso fará o menu do GRUB aparecer. Se não funcionar é porque você demorou demais para pressionar a tecla Esc: em tal caso, reinicie novamente o computador e pressione a tecla Esc / Escape um pouco antes do momento em que você a havia pressionado. Em algum momento você vai conseguir pressioná-la no momento ideal para acionar o menu do GRUB.
Quando conseguir acessar o menu do GRUB, use as "setas" (teclas direcionais) "para cima" e "para baixo" para selecionar Opções avançadas para Ubuntu, daí pressione a tecla Enter, selecione a opção Ubuntu, com o Linux 4.7.10-040710-generic e então pressione novamente a tecla Enter. Isso fará o GRUB inicializar o sistema Linux com kernel 4.7.10. Use o comando uname -r para se certificar de que o sistema do seu computador está usando o kernel 4.7.10 e então fique algumas horas usando-o com o kernel 4.7.10, para ver se o sistema vai "travar" ou não. ;)
-
Para desfazer, basta um comando como o abaixo?
sudo apt-get remove linux-headers-4.7.* linux-image-4.7.*; update-grub
-
Para desfazer, basta um comando como o abaixo?
sudo apt-get remove linux-headers-4.7.* linux-image-4.7.*; update-grub
Este comando é suficiente:
sudo apt-get remove linux-*4.7.10* -y
:)
-
Agradecida pelo esclarecimento Sampayu!
Meu erro era a digitação dos comandos mesmo (não tava colocando o espaço no comando sudo gedit), já q não estava conseguindo acessar a internet pra copiar esses comandos.
Pois bem, consegui fazer as edições e tal, mas na hora q reinicio e aparece o menu do GRUB o meu teclado não funciona e não da pra escolher a forma de iniciação :(
(mas não desanimei do Linux pq já me convenci que os problemas do windows são bem maiores q esse hahaha)
Como acredito que o problema esteja relacionado ao uso do kernel 4.10, gostaria de deixar o 4.7.10 como padrão para que este seja iniciado automaticamente.
As opções que aparecem no meu pc são essas:
Opções avançadas para Ubuntu
Ubuntu
Ubuntu, com Linux 4.10.0-28-generic
Ubuntu, com Linux 4.10.0-40-generic
Ubuntu, com Linux 4.10.0-42-generic
Ubuntu, com Linux 4.7.10-040710-generic
Ubuntu, with Linux 4.10.0-28-generic (recovery mode)
Ubuntu, with Linux 4.10.0-40-generic (recovery mode)
Ubuntu, with Linux 4.10.0-42-generic (recovery mode)
Ubuntu, with Linux 4.7.10-040710-generic (recovery mode)
Como devo editar o GRUB_DEFAULT=0 ??
-
Agradecida pelo esclarecimento Sampayu!
(...)
Como devo editar o GRUB_DEFAULT=0 ??
Definir o kernel padrão do sistema é uma tarefa um pouco mais complicada, mas nada impossível.
Quando você instala um kernel cuja versão é mais recente que a versão do kernel padrão do seu sistema, é fácil: em tal caso, o GRUB automaticamente faz com que esse kernel mais novo que você instalou passe a ser o kernel padrão do sistema...
...porém, quando você instala um kernel de versão anterior à do kernel padrão do seu sistema, o GRUB continua usando o kernel mais recente como padrão do sistema. Por isto, em tal caso é necessário informar manualmente ao GRUB que o kernel mais antigo que você instalou é que tem de ser considerado o kernel padrão. E, para fazer isso, é antes necessário descobrir, dentro dos menus e das opções dos menus de boot (inicialização) que o GRUB cria para os kernels, qual é a localização desse kernel mais antigo que você instalou e que deseja definir como padrão do sistema. :o
PRIMEIRO PASSO
Bom, o primeiro passo consiste em executar este comando, no terminal do shell do Linux:
cat /boot/grub/grub.cfg |grep menuentry |gedit -
...ou, se você estiver sem interface gráfica, alternativamente execute este comando:
cat /boot/grub/grub.cfg |grep menuentry |nano -
Obs.: se você não tiver o gedit instalado, instale-o com o comando sudo apt-get install gedit -y e depois execute lá o primeiro comando. Mas, se você não estiver executando a interface gráfica, execute o segundo comando, pois o nano é um editor de textos que "roda" diretamente no shell (editor de textos que é executado em "modo texto"), não precisa de interface gráfica. Dentro do terminal do shell, caso seu sistema esteja conectado à Internet basta executar sudo apt-get install nano -y que o nano será instalado.
Qualquer um dos dois comandos acima irá extrair, de dentro do arquivo de configuração do GRUB do seu sistema Linux, uma cópia dos trechos que citam quais são os menus e as opções de menu de boot (inicialização). Por exemplo, no meu sistema o resultado do comando é este:
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
menuentry_id_option=""
export menuentry_id_option
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
submenu 'Opções avançadas para Ubuntu' $menuentry_id_option 'gnulinux-advanced-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, com o Linux 4.7.10-040710-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.10-040710-generic-advanced-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.10-040710-generic (upstart)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.10-040710-generic-init-upstart-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.10-040710-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.10-040710-generic-recovery-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, com o Linux 4.7.4-040704-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.4-040704-generic-advanced-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.4-040704-generic (upstart)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.4-040704-generic-init-upstart-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.4-040704-generic-recovery-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, com o Linux 4.7.2-040702-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.2-040702-generic-advanced-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.2-040702-generic (upstart)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.2-040702-generic-init-upstart-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.2-040702-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.2-040702-generic-recovery-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, com o Linux 4.7.1-040701-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.1-040701-generic-advanced-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.1-040701-generic (upstart)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.1-040701-generic-init-upstart-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'Ubuntu, with Linux 4.7.1-040701-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.7.1-040701-generic-recovery-59917d29-3e78-4cc5-8e87-1aa2c6c2175e' {
menuentry 'System setup' $menuentry_id_option 'uefi-firmware' {
Aquele código menuentry 'Ubuntu' significa que o GRUB do meu Linux tem um menu padrão intitulado "Ubuntu". Além disso, aquele código submenu 'Opções avançadas para Ubuntu' significa que o GRUB do meu Linux tem um menu secundário intitulado "Opções avançadas para Ubuntu".
Dentro do menu secundário "Opções avançadas para Ubuntu" existem 12 opções: a 1ª delas é 'Ubuntu, com o Linux 4.7.10-040710-generic', que executa o kernel "4.7.10-040710-generic", e a última delas (12ª opção) é 'Ubuntu, with Linux 4.7.1-040701-generic (recovery mode)', que executa o kernel 4.7.1-040701-generic em modo de recuperação ("recovery mode").
No GRUB, a contagem dos menus e das opções de menu inicia em zero, assim: 0, 1, 2, 3... Então, no caso do meu sistema, aquele código 'Ubuntu' corresponde ao menu 0 (menu zero) e aquele código 'Opções avançadas para Ubuntu' corresponde ao menu 1. O mesmo vale para as opções que estão lá dentro do "menu 1": o código 'Ubuntu, com o Linux 4.7.10-040710-generic' corresponde à opção 0 e o código 'Ubuntu, with Linux 4.7.1-040701-generic (recovery mode)' corresponde à opção 11.
Digamos, por exemplo, que eu queira inicializar o kernel 4.7.4-040704-generic em modo de recuperação ("recovery mode"). Observe que, no meu caso, esse item é o sexto da lista do segundo menu. Como no GRUB a contagem inicia em zero, o menu em questão é o menu 1 (segundo menu) e a opção dentro dessa lista do menu 1 é a opção 5 (o sexto código da lista de opções, código esse denominado 'Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)').
Vou repetir aqui o resultado lá do primeiro comando, mas desta vez com a numeração dos menus e das opções dentro dos menus, para facilitar a compreensão:
- Menu 0: 'Ubuntu'
- Menu 1: 'Opções avançadas para Ubuntu'
-- Opção 0: 'Ubuntu, com o Linux 4.7.10-040710-generic'
-- Opção 1: 'Ubuntu, with Linux 4.7.10-040710-generic (upstart)'
-- Opção 2: 'Ubuntu, with Linux 4.7.10-040710-generic (recovery mode)'
-- Opção 3: 'Ubuntu, com o Linux 4.7.4-040704-generic'
-- Opção 4: 'Ubuntu, with Linux 4.7.4-040704-generic (upstart)'
-- Opção 5: 'Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)'
-- Opção 6: 'Ubuntu, com o Linux 4.7.2-040702-generic'
-- Opção 7: 'Ubuntu, with Linux 4.7.2-040702-generic (upstart)'
-- Opção 8: 'Ubuntu, with Linux 4.7.2-040702-generic (recovery mode)'
-- Opção 9: 'Ubuntu, com o Linux 4.7.1-040701-generic'
-- Opção 10: 'Ubuntu, with Linux 4.7.1-040701-generic (upstart)'
-- Opção 11: 'Ubuntu, with Linux 4.7.1-040701-generic (recovery mode)'
- Menu 2: 'System setup'
Portanto, se eu quiser que o GRUB por padrão execute a opção 'Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)' do exemplo acima, eu tenho de informar ao GRUB que essa opção está no menu 1 e que, dentro desse menu 1, essa opção é a opção 5. O código que representa essa informação é este, que utiliza a posição ordinal do menu e a posição ordinal da opção dele (lembrando que a contagem das posições ordinais inicia em zero):
'1>5'
...ou então este outro código (dá na mesma), que utiliza o nome do menu e o nome da opção que está dentro desse menu:
'Opções avançadas para Ubuntu>Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)'
Bom, agora como fazemos para passar essa informação para o GRUB? É simples... ;D
SEGUNDO PASSO
Anote os números ordinais (ou os respectivos nomes) do menu e da opção que você deseja que passe a ser o padrão do GRUB. Em seguida, retorne ao terminal do shell do Linux e execute este comando, que usará o gedit para editar o arquivo de configuração do GRUB:
sudo gedit /etc/default/grub
...daí vá até lá na linha onde se lê:
GRUB_DEFAULT=0
...e substitua o valor 0 (ou qualquer outro que esteja constando ali depois do sinal de igualdade) pelo valor desejado. No caso do exemplo acima, para se selecionar o menu 1 e a opção 5 desse menu 1 o código, em modo ordinal, deverá ficar assim:
GRUB_DEFAULT='1>5'
...e, para se usar o nome do menu e o nome da opção desse menu (ao invés de se usar as posições ordinais deles), o código deverá ficar assim:
GRUB_DEFAULT='Opções avançadas para Ubuntu>Ubuntu, with Linux 4.7.4-040704-generic (recovery mode)'
Obs.: caso você esteja no modo sem interface gráfica, use o nano para editar o arquivo de configuração do GRUB:
sudo nano /etc/default/grub
Após modificar o valor do parâmetro GRUB_DEFAULT, salve o arquivo e então feche o editor de textos.
Obs.: no gedit, o comando de teclado para salvar as alterações efetuadas no arquivo é a combinação de teclas Ctrl S e o comando de teclado para fechar o gedit é a combinação de teclas Alt F4. Já no nano, a combinação de teclas para salvar as alterações é Ctrl O e a combinação de teclas para fechar o nano é Ctrl X.
TERCEIRO PASSO
Agora que você está de volta ao terminal, execute este comando para que as modificações efetuadas no arquivo de configuração do GRUB sejam gravadas dentro do GRUB:
sudo update-grub
Se você fez tudo certo até aqui, reinicie o computador:
sudo telinit 6
...que ele passará a, por padrão, inicializar ("boot") o kernel que você definiu lá em GRUB_DEFAULT. ;)
-
Mais uma vez muito agradecida pelos tutoriais!
Consegui padronizar o kernel para o 4.7.10, mas infelizmente estava errada quanto às soluções dos meus problemas :'(
Estou tentando reutilizar um computador bem antigo com memória de 1 Gb e processador AMD XP-M 2800 (só isso q sei sobre ele). E ele sempre trava quando tento usar algum navegador de internet (Firefox, chromium e midori). Como posso configura-lo pra poder utiliza-lo minimamente (acessar páginas de internet como youtube e tudo mais)?
Agradeço uma indicação de post que direcione melhor a solução destes problemas. Abraços!
-
Mais uma vez muito agradecida pelos tutoriais!
Consegui padronizar o kernel para o 4.7.10, mas infelizmente estava errada quanto às soluções dos meus problemas :'(
Estou tentando reutilizar um computador bem antigo com memória de 1 Gb e processador AMD XP-M 2800 (só isso q sei sobre ele). E ele sempre trava quando tento usar algum navegador de internet (Firefox, chromium e midori). Como posso configura-lo pra poder utiliza-lo minimamente (acessar páginas de internet como youtube e tudo mais)?
Agradeço uma indicação de post que direcione melhor a solução destes problemas. Abraços!
De nada, Izabela. :D Que pena que o problema não é o kernel: isso seria mais fácil de se resolver. Mas, pelo visto, no seu caso o problema é que o computador é muito antigo e muito limitado, em termos de desempenho de hardware. No caso, o que você precisa é de uma distribuição Linux que seja lightweight ("peso leve"). Inclusive, como o processador AMD XP-M 2800 é de apenas 32 bits, você tem de instalar um Linux que use kernel de 32 bits (instalar um kernel de 64 bits não servirá para nada).
A propósito: qual distribuição *Ubuntu você está usando? Ubuntu (https://www.ubuntu.com)? KUbuntu (https://kubuntu.org)? XUbuntu (https://xubuntu.org)? LUbuntu (https://lubuntu.net/)?
Existem muitas distribuições lightweight por aí, mas elas geralmente são mais complicadas de instalar e de usar e, além disso, possuem menos recursos e menos aplicativos que as distribuições *Ubuntu. Na lista acima, eu propositalmente pus as versões do *Ubuntu em ordem crescente de "leveza", da esquerda para a direita, ou seja: Ubuntu é a distribuição que mais demanda recursos de hardware (é a versão mais "pesada" do sistema), KUbuntu requer um pouco menos de desempenho do computador, XUbuntu requer menos ainda, e LUbuntu requer ainda menos.
Caso você esteja usando Ubuntu, minha sugestão é que experimente pegar o ISO de instalação do XUbuntu 16.04.3 de 32 bits (http://www.mirrorservice.org/sites/cdimage.ubuntu.com/cdimage/xubuntu/releases/16.04/release/xubuntu-16.04.3-desktop-i386.iso) e então instalá-lo nesse seu computador velho, para ver como fica o desempenho. Eu nem vou dizer pra você testar a versão KUbuntu porque ela é praticamente tão "pesada" quanto a Ubuntu e o seu computador é limitado demais (1 GB de RAM e processador AMD 32 bits de 2.1GHz com barramento de 266MHz, como é o caso do AMD XP-M 2800, é um desempenho baixíssimo. Muito limitado mesmo). Se o seu computador antigo funcionar com um desempenho melhor e não travar mais, que ótimo. Mas, caso o computador continue travando, então experimente pegar o ISO de instalação do LUbuntu 16.04.3 de 32 bits (http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04.3-desktop-i386.iso) e instalá-lo nesse seu computador velho. Se der certo, que ótimo.
Se nem mesmo a versão LUbuntu ("Light Ubuntu") não ficar leve o bastante com seu velho computador, experimente o Puppy Linux (http://puppylinux.org). Mas se seu computador travar mesmo com o LUbuntu, é possível que esse computador esteja com algum defeito no hardware...
Eu nunca usei Puppy Linux, mas certa vez testei-o via VirtualBox (máquina virtual) e achei interessante. Caso você chegue ao ponto de testar todas as versões da distribuição *Ubuntu e nenhuma atender suas necessidades, minha sugestão é que você instale o Puppy Linux, para ver se dá certo, e, se não der, que você procure um fórum de discussão ou artigo a respeito de distribuições Linux leves, pois em tais lugares na web você encontrará opiniões a respeito das melhores distribuições Linux "peso leve" da atualidade. Como este fórum aqui é a respeito do Ubuntu e suas outras versões (KUbuntu, XUbuntu etc.), você não vai encontrar nada muito específico e detalhado a respeito de outras distribuições Linux e de distribuições Linux "peso leve".
Boa sorte! Espero que o XUbuntu ou pelo menos o LUbuntu consiga atender você. ;)
-
@Sampayu,
Parabéns pelo excelente tutorial.
-
@Sampayu,
Parabéns pelo excelente tutorial.
Obrigado. :)
-
(sou iniciante no Linux)
Boa noite,
Dia (28/12/17) ganhei um computador: Dell Inspiron 15, série 5000; CORE i5 7ª Ger.; Memória 8GB; Disco 1TB.
O problema é que ao ligar o aparelho aparece a tela inicial onde coloco a senha, mas após isso a tela fica preta e não sai mais disso.
Descobri que o Ubuntu é o 16.04 e o uname-ir é 4.4.0-104 -generic x86_64 (64Bits).
Me recordo que o aparelho veio com Ubuntu 14.04...
Li este tópico: https://ubuntuforum-br.org/index.php/topic,120620.0.html
Mas, tem uma discussão sobre "Open Source" e "Privado", e parece que no privado não é recomendado atualizar o Kernel..
Estou confusa.
-
(sou iniciante no Linux)
Boa noite,
Dia (28/12/17) ganhei um computador: Dell Inspiron 15, série 5000; CORE i5 7ª Ger.; Memória 8GB; Disco 1TB.
O problema é que ao ligar o aparelho aparece a tela inicial onde coloco a senha, mas após isso a tela fica preta e não sai mais disso.
Descobri que o Ubuntu é o 16.04 e o uname-ir é 4.4.0-104 -generic x86_64 (64Bits).
Me recordo que o aparelho veio com Ubuntu 14.04...
Li este tópico: https://ubuntuforum-br.org/index.php/topic,120620.0.html
Mas, tem uma discussão sobre "Open Source" e "Privado", e parece que no privado não é recomendado atualizar o Kernel..
Estou confusa.
Ok, vamos por partes. ;)
1) Elaborei o tutorial (https://ubuntuforum-br.org/index.php?topic=120620.msg662196) para ajudar os proprietários de computadores híbridos em que ao menos uma das GPU é da marca AMD. Digo: caso seu computador não possua nenhuma GPU da marca AMD, dificilmente a substituição do kernel resolverá o problema. Caso resolva, será por coincidência: será porque por acaso o problema que você está vivenciando também é causado pelo kernel e o kernel substituto coincidentemente está livre desse problema.
2) As especificações que você forneceu são insuficientes para se saber exatamente qual notebook você possui. Isso ocorre porque existem diversos modelos de notebooks Dell Inspiron 15 da série 5000 que são vendidos com o Ubuntu Linux pré-instalado. Os Dell Inspiron 15 da série 5000 atualmente não possuem GPU da AMD, portanto é provável que o culpado pelo problema que você está vivenciando não seja o kernel. Além disso, atualmente nenhum dos notebooks Dell Inspiron 15 da série 5000 vem com o Ubuntu 14.04: você citou que o seu notebook foi fornecido com o Ubuntu 14.04, mas isso não faz sentido porque você afirmou que recebeu seu notebook em 28/12/2017, embora o Ubuntu 16.04 tenha se tornado padrão, nos notebooks Dell Inspiron com Linux, desde meados de maio de 2016. Enfim: se seu notebook é novo (posterior a maio de 2016) e é um Dell Inspiron 15 da série 5000, então ele tem de ter vindo com o Ubuntu 16.04 pré-instalado, não pode ter vindo com o Ubuntu 14.04.
3) O que você escreveu a respeito de "open source" e "privado" refere-se aos diferentes drivers para as GPU da AMD funcionarem no Linux: o driver "privado" é o que foi desenvolvido pela própria fabricante AMD, para fazer as GPU AMD funcionarem no Linux. Esse driver "privado" (proprietário) não funciona no Ubuntu 16.04 (somente no Ubuntu 14.04, embora o Ubuntu 14.04 esteja obsoleto). Já o driver "open source" não foi desenvolvido pela AMD mas sim pela comunidade Linux. Esse driver "open source" (código aberto) é o que já vem, por padrão, no Ubuntu 16.04, porém o Ubuntu 16.04 vinha (não vem mais) com kernel versão 4.4, que dá problema com esse driver "open source". Eu escrevi "vinha" porque, conforme consta no calendário do suporte do kernel do Ubuntu 16.04 (https://wiki.ubuntu.com/Kernel/Support?action=AttachFile&do=get&target=16.04.x+Ubuntu+Kernel+Support+Schedule.svg), desde agosto/2017 o Ubuntu 16.04 está sendo distribuído na versão 16.04.3, que vem com kernel versão 4.10. Enfim: se o seu sistema está lhe informando que o kernel do seu Linux é versão 4.4 e o problema for o kernel, a atualização do kernel (ou a instalação da versão mais nova do Ubuntu 16.04) poderá resolver o problema.
Feitas essas considerações preliminares, minha sugestão é que você primeiro desabilite o KMS, tal como foi explicado aqui (https://ubuntuforum-br.org/index.php?topic=120620.msg662202#msg662202), e então verifique se, com o KMS desabilitado, você consegue efetuar login. Se você conseguir se conectar com sua senha, então pelo visto seu notebook possui uma GPU da AMD e o problema realmente é o kernel do seu Linux. Neste caso, aproveite que você está acessando o sistema com o KMS desabilitado e então execute lá o passo-a-passo do tutorial, para substituir o kernel versão 4.4 por um da versão estável que não possui o bug que está causando o problema no seu notebook.
Se mesmo com o KMS desabilitado você não conseguir efetuar login, então provavelmente seu notebook não possui uma GPU da AMD e o problema do login não está relacionado com o kernel mas sim com algum problema na configuração da sua conta de usuário. Neste segundo caso, será necessário criar uma segunda conta de usuário, para verificar se essa segunda conta funciona normalmente. Mas só vamos fazer isso se realmente for necessário: por gentileza, realize o procedimento de desabilitação do KMS e veja se assim você consegue efetuar login. Caso consiga efetuar login, instale o outro kernel, tal qual explicado lá no tutorial, e depois informe aqui se a substituição do kernel resolveu o problema.
Caso desabilitar o KMS não seja suficiente para você conseguir efetuar login, informe isso aqui para que eu possa então explicar como criar uma nova conta de usuário sem você precisar de interface gráfica pra fazer isso. Se antes de criar uma nova conta de usuário você quiser tentar corrigir a instalação dos pacotes do sistema (só para se certificar de que realmente os pacotes estão íntegros e instalados e configurados corretamente), então reinicie o notebook e, quando chegar à tela de login, use a combinação de teclas Ctrl Alt F1 para ir para o terminal virtual 1 (modo texto), daí digite seu nome de usuária e pressione a tecla Enter, em seguida digite sua senha e pressione a tecla Enter. O sistema efetuará login no ambiente do shell (ambiente em que o sistema operacional Linux é executado em modo texto, ou seja, sem interface gráfica). Após efetuar login, execute este comando para se tornar superusuária:
sudo su
...e forneça sua senha e confirme com Enter, quando o comando acima solicitar.
Caso queira confirmar que o comando acima funcionou, execute este outro comando:
whoami
Se o resultado desse comando for root (que é o nome do "usuário raiz" do sistema Linux), então você de fato estará conectada ao sistema Linux como superusuária.
Uma vez que esteja conectada como superusuária, execute o supercomando abaixo (esse supercomando requer acesso à Internet, mas acredito que seu notebook ainda esteja se conectando automaticamente à Internet, já que no seu relato não consta nada relativo a alguma impossibilidade de acesso a redes TCP/IP):
apt-get clean ; apt-get autoremove -y ; dpkg --configure -a ; apt-get update ; apt-get check ; apt-get install unity ubuntu-desktop --reinstall -y ; apt-get dist-upgrade -y ; apt-get autoremove -y ; apt-get clean ; telinit 6
Após o sistema reiniciar, verifique se o problema foi resolvido. Se foi, que ótimo, isso significará que ou a desabilitação temporária do KMS e substituição do kernel resolveu o problema, ou então significará que o problema foi resolvido pela reconfiguração de todos os pacotes instalados no sistema operacional e reinstalação + reconfiguração do DE (ambiente de desktop) do Ubuntu (estou presumindo que você está usando o Ubuntu, que por padrão utiliza o DE denominado Unity).
O Linux é um sistema maravilhoso, mas não é perfeito: ele tem problemas, como qualquer sistema operacional tem. Apesar disso, o esforço para "consertar" o Linux vale a pena: uma vez que esteja instalado, configurado e funcional, você provavelmente nunca mais vai querer voltar para o Ruindows. :P
Caso as dicas acima para resolver o problema não tenham funcionado, o próximo passo será mesmo tentar resolver o problema criando uma nova conta de usuária para você.
Se em algum momento você porventura desistir dos procedimentos acima relatados e decidir instalar uma versão mais nova do Ubuntu 16.04, recomendo bastante instalar o XUbuntu 16.04.3 de 64 bits (http://mirror.us.leaseweb.net/ubuntu-cdimage/xubuntu/releases/16.04/release/xubuntu-16.04.3-desktop-amd64.iso), já que ele vem com kernel versão 4.10 e utiliza a interface XFCE (https://xfce.org), que é mais leve, mais rápida, mais estável etc. que a interface do Ubuntu. Eu uso XUbuntu desde 2009 e não sinto saudade nenhuma da interface Unity do Ubuntu. :P O link que disponibilizei ali é para download de um arquivo ISO que pode ser gravado em um DVD para instalação do XUbuntu 16.04.3 de 64 bits.
-
:( Olá bom dia, fui instruído a acionar este tópico para o meu problema com imagem no sistema Youtube, ocorre que qdo eu abro uma tela do youtube que a transmissão esta sendo feita "ao vivo" simplesmente não aparece a imagem e sim uma informação com o problema do HTML5 ou então a tela fica preta e não roda. O Kernel que estou usando é o 4.10.0-28 - generic - Ubuntu 16.04.03 LTS. Computador Inspiron 1545 64bits, Intel Core @ Dua CPU T6600 2.20GHz x2, placa gráfica Mobile Intel GM45 Express Chipset.
Obs.: Qdo eu instalei o sistema Ubuntu 17.10 não havia este problema, funcionava eu tive que voltar para o 16.04, em virtude de não conseguir acessar o sistema Warsan do banco do Brasil, sendo que neste 16.04.03, funciona perfeitamente.
Desde já agradeço pela ajuda.
-
:( Olá bom dia, fui instruído a acionar este tópico para o meu problema com imagem no sistema Youtube, ocorre que qdo eu abro uma tela do youtube que a transmissão esta sendo feita "ao vivo" simplesmente não aparece a imagem e sim uma informação com o problema do HTML5 ou então a tela fica preta e não roda. O Kernel que estou usando é o 4.10.0-28 - generic - Ubuntu 16.04.03 LTS. Computador Inspiron 1545 64bits, Intel Core @ Dua CPU T6600 2.20GHz x2, placa gráfica Mobile Intel GM45 Express Chipset.
Obs.: Qdo eu instalei o sistema Ubuntu 17.10 não havia este problema, funcionava eu tive que voltar para o 16.04, em virtude de não conseguir acessar o sistema Warsan do banco do Brasil, sendo que neste 16.04.03, funciona perfeitamente.
Desde já agradeço pela ajuda.
Oi, bom dia. :)
Ok, vamos por partes: como você ainda não trocou o kernel, peço que primeiro troque o kernel, conforme explicado lá no tutorial (https://ubuntuforum-br.org/index.php?topic=120620.0).
Pra você não se perder, a sequência que você precisa seguir é a seguinte:
1) Primeiro você formata a máquina e instala o Ubuntu 16.04.3, conforme havíamos conversado. Essa etapa você pelo visto já executou.
2) Após a instalação do Ubuntu 16.04.3 estar concluída, o segundo passo que precisa ser executado é a substituição do kernel, tal qual explicado lá no tutorial (https://ubuntuforum-br.org/index.php?topic=120620.0).
3) Somente após o Ubuntu 16.04.3 estar instalado e o kernel substituto estar instalado e configurado para iniciar como kernel padrão (conforme explicado neste post (https://ubuntuforum-br.org/index.php/topic,120620.msg673811.html#msg673811), desinstale completamente seus navegadores e então instale os navegadores Mozilla Firefox, o Opera Browser e Google Chrome. Para saber como executar a desinstalação completa e depois a reinstalação desses navegadores, siga os procedimentos deste post (https://ubuntuforum-br.org/index.php?topic=121558.msg673986#msg673986).
4) Após os três navegadores estarem instalados, verifique se o problema com HTML5 ocorre nos três navegadores ou em apenas um deles e informe aqui se algum dos navegadores está funcionando corretamente com transmissão ao vivo no YouTube.
Não apenas o Linux, mas todos os navegadores e sistemas operacionais estão passando por uma fase de mudanças: o Flash está sendo gradualmente substituído pelo HTML5. Por causa disso, às vezes um navegador tem plugin Flash (para poder reproduzir vídeos em Flash) mas o website só disponibiliza o vídeo por intermédio de HTML5. Às vezes é o contrário: o vídeo está disponível em formato Flash mas o seu navegador não tem mais suporte ao plugin Flash, seu navegador só consegue executar vídeo via HTML5. Pior: seu navegador pode informar que executa Flash, mas na prática não executar (isso tem ocorrido comigo lá no website do Banco do Brasil, tanto para o navegador Opera quanto para o Chrome: esses dois navegadores possuem um menu de configuração do Flash, mas mesmo com o Flash habilitado a página de acesso ao banco não funciona para acesso com Warsaw, porque a página requer Flash e o Flash não funciona, nesses navegadores. O Mozilla Firefox é o único navegador que continua, no momento, executando o Flash corretamente).
Aguardo você executar os procedimentos na sequência indicada acima e então reportar aqui se conseguiu substituir o kernel e tornar esse kernel substituto o padrão do seu sistema, e também informar aqui se algum dos três navegadores (re)instalados está conseguindo executar os vídeos ao vivo do YouTube.
A vantagem de instalar três navegadores é que isso aumenta as chances de pelo menos 1 deles funcionar no website do banco do Brasil e ao menos 1 deles funcionar com transmissão de vídeos ao vivo do YouTube etc. Enfim: o problema de HTML5 que um navegador apresente talvez não ocorra em outro navegador, assim como o problema de Flash que um navegador apresente talvez não ocorra em outro navegador. ;)
-
:-\ Olá, boa tarde Sampayu, agradeço desde já pelas dicas, mas vamos lá quanto aos resultados após todo o passo a passo:
- BB abre no Firefox, mas não abre os vídeos ao vivo, continua com o problema do HTML5
- O Chromo abre os vídeos ao vivo, mas solicita a instalação do sistema warsan do banco do brasil, pergunto devo fazer o processo? ou haverá conflito do Firefox?
- O Opera não faz nada sem vídeo e solicita a instalação do modulo warsan.
Se houver chance de acertar o Firefox será uma maravilha, sendo que caso eu possa realizar o processo de instalação do modulo nele sem que haja conflito, ficará mais interessante manter o Firefox e o Chromo.
Fico no aguardo,
abs
-
:-\ Olá, boa tarde Sampayu, agradeço desde já pelas dicas, mas vamos lá quanto aos resultados após todo o passo a passo:
- BB abre no Firefox, mas não abre os vídeos ao vivo, continua com o problema do HTML5
- O Chromo abre os vídeos ao vivo, mas solicita a instalação do sistema warsan do banco do brasil, pergunto devo fazer o processo? ou haverá conflito do Firefox?
- O Opera não faz nada sem vídeo e solicita a instalação do modulo warsan.
Se houver chance de acertar o Firefox será uma maravilha, sendo que caso eu possa realizar o processo de instalação do modulo nele sem que haja conflito, ficará mais interessante manter o Firefox e o Chromo.
Fico no aguardo,
abs
Então... Atualmente você alcançou a mesma situação que eu: Firefox para poder acessar o BB com Warsaw, Chrome para vídeos no YouTube (mas não funciona com BB / Warsaw), e Opera não funciona no BB/Warsaw mas comigo tem funcionado no YouTube.
* Em relação ao Firefox: é só esse navegador mesmo que você vai usar para acessar o BB. Pelo menos enquanto o BB não surge com uma versão do Warsaw que não dependa de Flash. Para melhorar o desempenho do Firefox com vídeos no YouTube, execute os procedimentos deste tutorial de instalação manual do Adobe Flash (https://ubuntuforum-br.org/index.php?topic=121250.0) e reporte lá no tópico do tutorial caso o Firefox continue não executando vídeos do YouTube mesmo após a instalação manual do Adobe Flash.
* Em relação ao Chrome: você não vai conseguir acessar o BB com o Chrome, pois o Chrome não suporta mais Flash (somente HTML5, no lugar do Flash). Como o website do BB requer Flash, não vai rolar... Pelo menos não até o BB surgir com uma nova versão do Warsaw que não dependa do Flash. Enfim: use Chrome para outras coisas, mas não para acessar o BB.
* Em relação ao Opera: mesmo problema do Chrome, ou seja, não funciona com Flash (embora o menu de configuração do Opera informe que há suporte para Flash... Não está funcionando). Portanto, você não vai conseguir acessar o BB com o Opera. Mas é recomendável deixar o Opera instalado porque de tempos em tempos o Opera é instalado com algum recurso bacana que amplia o funcionamento dele. Na época em que instalei o Warsaw o Opera era o navegador que melhor funcionava com o BB / Warsaw e também com Flash e HTML5 do YouTube, então veja como são as coisas: o Opera atualmente é o menos compatível, mas já foi o mais compatível e ninguém garante que o Opera não voltará a ser o mais compatível, daqui a uns tempos. Não dói nada deixar o Opera instalado, só por garantia. ;) Ainda no Opera, não se esqueça de acessar o endereço opera://settings/#plugins, clicar no item Sites (no painel esquerdo) e certificar-se de que lá na opção Flash a caixa Perguntar antes de permitir a execução do Flash nos sites (recomendado) esteja marcada.
-
:-[ No passo 5 não criou a pasta vide mensagem no terminal: ( impossível criar o diretório )
5. Crie a pasta do plugin flash NPAPI da Adobe.
Execute o comando abaixo, dentro do terminal do shell, para que o diretório do plugin seja criado:
Código: [Selecionar]
usr/lib64/kde4/kcm_adobe_flash_player.so
license.pdf
luciene@Inspiron-1545:/tmp$ sudo mkdir /usr/lib/adobe-flashplugin
mkdir: é impossível criar o diretório “/usr/lib/adobe-flashplugin”: Arquivo existe
luciene@Inspiron-1545:/tmp$ sudo mkdir /usr/lib/adobe-flashplugin
mkdir: é impossível criar o diretório “/usr/lib/adobe-flashplugin”: Arquivo existe
luciene@Inspiron-1545:/tmp$
-
:-[ No passo 5 não criou a pasta vide mensagem no terminal: ( impossível criar o diretório )
5. Crie a pasta do plugin flash NPAPI da Adobe.
Execute o comando abaixo, dentro do terminal do shell, para que o diretório do plugin seja criado:
Código: [Selecionar]
usr/lib64/kde4/kcm_adobe_flash_player.so
license.pdf
luciene@Inspiron-1545:/tmp$ sudo mkdir /usr/lib/adobe-flashplugin
mkdir: é impossível criar o diretório “/usr/lib/adobe-flashplugin”: Arquivo existe
luciene@Inspiron-1545:/tmp$ sudo mkdir /usr/lib/adobe-flashplugin
mkdir: é impossível criar o diretório “/usr/lib/adobe-flashplugin”: Arquivo existe
luciene@Inspiron-1545:/tmp$
Substitua o comando do item 5 por este:
if [ -d /usr/lib/adobe-flashplugin ]; then sudo rm -r /usr/lib/adobe-flashplugin; fi ; sudo mkdir /usr/lib/adobe-flashplugin
Já atualizei o tutorial com esse comando aí. ;)
-
:-[ Olá, mas dando continuidade ao assunto, não funcionou, veja imagem abaixo do terminal:
usr/lib64/kde4/
usr/lib64/kde4/kcm_adobe_flash_player.so
license.pdf
luciene@Inspiron-1545:/tmp$ if [ -d /usr/lib/adobe-flashplugin ]; then sudo rm -r /usr/lib/adobe-flashplugin; fi ; sudo mkdir /usr/lib/adobe-flashplugin
luciene@Inspiron-1545:/tmp$ sudo cp -f libflashplayer.so /usr/lib/adobe-flashplugin/
luciene@Inspiron-1545:/tmp$ sudo ln -sf /usr/lib/adobe-flashplugin/libflashplayer.so /usr/lib/flashplugin-installer/libflashplayer.so
ln: falhou ao criar link simbólico '/usr/lib/flashplugin-installer/libflashplayer.so': Arquivo ou diretório não encontrado
luciene@Inspiron-1545:/tmp$
-
:-[ Olá, mas dando continuidade ao assunto, não funcionou, veja imagem abaixo do terminal:
usr/lib64/kde4/
usr/lib64/kde4/kcm_adobe_flash_player.so
license.pdf
luciene@Inspiron-1545:/tmp$ if [ -d /usr/lib/adobe-flashplugin ]; then sudo rm -r /usr/lib/adobe-flashplugin; fi ; sudo mkdir /usr/lib/adobe-flashplugin
luciene@Inspiron-1545:/tmp$ sudo cp -f libflashplayer.so /usr/lib/adobe-flashplugin/
luciene@Inspiron-1545:/tmp$ sudo ln -sf /usr/lib/adobe-flashplugin/libflashplayer.so /usr/lib/flashplugin-installer/libflashplayer.so
ln: falhou ao criar link simbólico '/usr/lib/flashplugin-installer/libflashplayer.so': Arquivo ou diretório não encontrado
luciene@Inspiron-1545:/tmp$
Esse erro é normal: significa que você não tem o instalador automatizado instalado, o que inclusive significa que é melhor você desinstalar essa instalação manual e então instalar o instalador automatizado, já que pelo visto você não chegou a testá-lo.
Para excluir essa instalação manual aí e instalar o instalador automatizado do Adobe Flash, execute este supercomando (um supercomando é uma combinação de vários comandos):
sudo rm -r /usr/lib/adobe-flashplugin /usr/lib/flashplugin-installer/libflashplayer.so /usr/bin/flash-player-properties /usr/lib/kde4/kcm_adobe_flash_player.so /usr/lib64/kde4/kcm_adobe_flash_player.so /usr/share/applications/flash-player-properties.desktop /usr/share/kde4/services/kcm_adobe_flash_player.desktop /usr/share/pixmaps/flash-player-properties.png ; cd /usr/share/icons/hicolor ; sudo find . -name "flash-player-properties.png" -delete ; sudo apt-get update ; sudo apt-get check ; sudo apt-get install adobe-flashplugin -y ; sudo apt-get dist-upgrade -y ; sudo apt-get autoremove -y ; sudo apt-get clean
O supercomando acima é quilométrico, mas ele vai resolver tudo "numa tacada só".
Para colocar esse supercomando aí no terminal do shell, basta usar o ponteiro do mouse / touchpad para selecionar o supercomando acima, em seguida copiar o supercomando acima e, ainda usando o ponteiro do mouse / touchpad, colar esse supercomando na janela do terminal e pressionar a tecla Enter para executar o supercomando.
-
:'( Olá Sampayu, lamento informar de que não funcionou, ou seja, a tela do youtube para transmissões ao vivo continua com o problema.
Minha curiosidade é por que no ubuntu 17.10 funcionava?
Desde já obrigado por toda a atenção, acho que + lá para frente deverá haver uma solução.
abs
-
:'( Olá Sampayu, lamento informar de que não funcionou, ou seja, a tela do youtube para transmissões ao vivo continua com o problema.
Minha curiosidade é por que no ubuntu 17.10 funcionava?
Desde já obrigado por toda a atenção, acho que + lá para frente deverá haver uma solução.
abs
Você está usando kernel versão 4.7.10? No kernel 4.7.10 o driver gráfico open-source da AMD funciona normalmente e o Flash carrega normalmente. Acabei de acessar o YouTube e assistir um vídeo ao vivo nos três navegadores (Firefox, Opera e Chrome) sem problema nenhum. Você já experimentou assistir outros vídeos ao vivo e nenhum deles funcionou? Qual é o navegador que está (ou quais navegadores que estão) dando problema?
Você está tentando assistir vídeo ao vivo ou transmitir vídeo ao vivo?
-
Prezado Sampayu, na resposta 59 eu menciono qual é o Kernel ( 4.10.0-28 - generic )
Lembro que após o processo anterior que realizamos, não consegui mais acessar o banco do brasil pelo Firefox, muito menos pelo Chromo, apesar de tentar reinstalar o warsan diversas vezes e tendo limpado o que era possível.
Obs.: Já tentamos instalar a versão que vc menciona e não conseguimos, posso tentar novamente....
-
Olá, Sampayu
Dando prosseguimento para mudança do Kernel, seguindo o passo a passo existente, o mesmo retornou com a seguinte configuração:
luciene@Inspiron-1545:~$ uname -r
4.13.0-26-generic
luciene@Inspiron-1545:~$
ou seja, passou do 10 para o 13???
-
:D Olá, bom dia Sampayu,
Bom desde já agradeço pela ajuda em acessar o banco do Brasil e ter o Youtube na transmissões ao vivo funcionando.
Detalhe, não posso afirmar, mas após habilitar os codecs, o sistema através do Firefox passou acessar até com a nova versão do Kernel, veja o Kernel que estou utilizando: 4.13.0-26-generic
, não só o Firefox, mas o Chromo também, inclusive abri três telas no Youtube, transmissões ao vivo ao mesmo tempo, e funcionou perfeitamente.
Acredito que possa ser utilizado como fonte de informação para todos aqueles que possam estar tendo problemas com o processador AMD e placa gráfica igual a minha que citei acima.
Um grande abraço
-
:D Olá, bom dia Sampayu,
Bom desde já agradeço pela ajuda em acessar o banco do Brasil e ter o Youtube na transmissões ao vivo funcionando.
Detalhe, não posso afirmar, mas após habilitar os codecs, o sistema através do Firefox passou acessar até com a nova versão do Kernel, veja o Kernel que estou utilizando: 4.13.0-26-generic
, não só o Firefox, mas o Chromo também, inclusive abri três telas no Youtube, transmissões ao vivo ao mesmo tempo, e funcionou perfeitamente.
Acredito que possa ser utilizado como fonte de informação para todos aqueles que possam estar tendo problemas com o processador AMD e placa gráfica igual a minha que citei acima.
Um grande abraço
Esqueci de mencionar que no caso do navegador Choromo há necessidade de sempre habilitar o Flash o tempo todo.
-
:D Olá, bom dia Sampayu,
Bom desde já agradeço pela ajuda em acessar o banco do Brasil e ter o Youtube na transmissões ao vivo funcionando.
Detalhe, não posso afirmar, mas após habilitar os codecs, o sistema através do Firefox passou acessar até com a nova versão do Kernel, veja o Kernel que estou utilizando: 4.13.0-26-generic
, não só o Firefox, mas o Chromo também, inclusive abri três telas no Youtube, transmissões ao vivo ao mesmo tempo, e funcionou perfeitamente.
Acredito que possa ser utilizado como fonte de informação para todos aqueles que possam estar tendo problemas com o processador AMD e placa gráfica igual a minha que citei acima.
Um grande abraço
Olá.
De nada. :)
A instalação dos codecs não tem relação com a instalação e versão do kernel (e vice-versa). O que ocorre é que o kernel 4.13 que você está usando não tem o bug citado no tópico deste tutorial. Os codecs servem apenas para habilitar recursos multimídia, como por exemplo a execução de faixas de áudio MP3, de faixas de vídeo AVI, de faixas audiovisuais (áudio + vídeo) WEBM do YouTube etc. O fato de o sistema operacional ter os codecs instalados não faz o bug surgir no kernel ou ser eliminado do kernel: se o kernel tiver o bug, seu sistema irá "travar"/"congelar" independentemente de os codecs estarem ou não instalados. E, se o kernel não tiver o bug, seu sistema não irá "travar"/"congelar", independentemente de os codecs estarem ou não instalados...
...mas seu comentário foi importante porque acabou me lembrando de que eu precisava atualizar o tutorial. Agora o tutorial explica como instalar a versão 4.14.14 do kernel Linux, que também não tem o bug e é mais recente que a sua versão 4.13 e também mais recente (mais novo) que a versão 4.7.10 que eu vinha utilizando. :D
-
Testei o kernel 4.14.14 e pelo menos na minha maquina não deu certo , travou e reiniciou a sessão .
Dos Kernels que testei até o momento :
- 4.8.17
- 4.9.78
- 4.10.17
- 4.13.16
- 4.14.14
somente o 4.8.17 rodou bem , apesar de ter travado umas duas vezes durante quase 1 mês de uso intensivo . Já o bom e velho 4.7.10 rodou sem problemas . Realmente é uma pena isso ! Pois quando estou usando as versões mais novas como as 4.14.14 , noto uma diferença de performance , as páginas carregam mais rapidamente , tudo parece mais "suave" . Mas aí , acontece o travamento e adeus sessão ::) ! Pelo menos vou ficando com o 4.8.17 que por enquanto está dando para usar de boa no dia a dia . :)
-
Testei o kernel 4.14.14 e pelo menos na minha maquina não deu certo , travou e reiniciou a sessão .
Dos Kernels que testei até o momento :
- 4.8.17
- 4.9.78
- 4.10.17
- 4.13.16
- 4.14.14
somente o 4.8.17 rodou bem , apesar de ter travado umas duas vezes durante quase 1 mês de uso intensivo . Já o bom e velho 4.7.10 rodou sem problemas . Realmente é uma pena isso ! Pois quando estou usando as versões mais novas como as 4.14.14 , noto uma diferença de performance , as páginas carregam mais rapidamente , tudo parece mais "suave" . Mas aí , acontece o travamento e adeus sessão ::) ! Pelo menos vou ficando com o 4.8.17 que por enquanto está dando para usar de boa no dia a dia . :)
Oi, Marcos, obrigado por reportar isso. :) Interessante saber disso, pois como até o momento eu não tive problema com o kernel 4.14.14 eu estava com a impressão de que ele estava 100% livre do bug. Mas, agora que você publicou seu relato, pelo visto a ausência de travamentos depende da configuração do hardware do computador em que o kernel está sendo executado.
Pelo visto, fiz bem em deixar no tutorial o supercomando para quem preferir instalar o bom e velho kernel versão 4.7.10. No meu notebook (Dell Inspiron 5548) até agora (1 mês e meio de uso) não tive problemas com o kernel 4.14.14, mas se ele em algum momento acarretar congelamento do sistema e eu constatar que o culpado pelo congelamento é o kernel 4.14.14, retorno ao kernel 4.7.10 e reporto isso no tutorial. Se eu ficar sabendo de alguma versão de kernel posterior à 4.7.10 em que o bug foi corrigido, também reporto por aqui. Abraço.
-
Testei o kernel 4.14.14 e pelo menos na minha maquina não deu certo , travou e reiniciou a sessão .
Dos Kernels que testei até o momento :
- 4.8.17
- 4.9.78
- 4.10.17
- 4.13.16
- 4.14.14
somente o 4.8.17 rodou bem , apesar de ter travado umas duas vezes durante quase 1 mês de uso intensivo . Já o bom e velho 4.7.10 rodou sem problemas . Realmente é uma pena isso ! Pois quando estou usando as versões mais novas como as 4.14.14 , noto uma diferença de performance , as páginas carregam mais rapidamente , tudo parece mais "suave" . Mas aí , acontece o travamento e adeus sessão ::) ! Pelo menos vou ficando com o 4.8.17 que por enquanto está dando para usar de boa no dia a dia . :)
Embora meu notebook não esteja travando com o kernel 4.14.14, recentemente descobri que o kernel 4.14.14 estava "reclamando" que a versão de firmware¹ da CPU Intel é antiga. Eu vi isso nos logs do sistema. Se quiser testar para ver se o kernel que você está usando também está "reclamando" da versão de firmware da CPU Intel do seu computador, execute este comando, no terminal do shell, imediatamente após ligar o computador e efetuar login no sistema:
dmesg |grep -i microcode
Se o comando acima fizer aparecer na tela uma mensagem do tipo [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later),² instale o pacote que atualiza o microcode da Intel. O comando é este:
sudo apt-get install intel-microcode iucode-tool -y ; sudo telinit 6
Não é possível modificar permanentemente o firmware de uma CPU (um processador): diferentemente de um BIOS, que pode ser substituído, o firmware de um processador não pode. A solução, portanto, consiste em instruir o sistema operacional a inicializar um firmware alternativo (mais novo) toda vez em que o sistema operacional estiver sendo inicializado (boot). Portanto, a instalação dos pacotes acima não atualizará o firmware que está dentro do processador, mas fará com que a cada boot (inicialização) do Linux um firmware alternativo (armazenado no disco rígido ou unidade de estado sólido do seu computador) seja carregado (inicializado) no lugar do firmware padrão que está embutido no processador.
Após você executar o comando acima e o computador reiniciar, execute novamente o comando dmesg |grep -i microcode. Caso o comando lhe mostre estas mensagens:²
microcode: microcode updated early to revision 0x25, date = 2017-01-27
microcode: sig=0x306d4, pf=0x40, revision=0x25
microcode: Microcode Update Driver: v2.2.
...então um microcode mais novo (uma versão alternativa e mais recente do firmware do processador do seu computador) está presente na unidade de armazenamento na qual o sistema operacional Linux está instalado, e esse microcode está sendo corretamente inicializado pelo sistema operacional Linux, durante o "boot".
...mas se o comando acima continuar lhe retornando a mesma mensagem de erro, experimente instalar também o pacote para microcode da AMD:
sudo apt-get install amd64-microcode -y ; sudo telinit 6
Após o microcode estar atualizado, você pode de repente instalar um kernel mais novo, como por exemplo o da versão 4.14.14, e verificar se o congelamento / travamento do sistema ocorre. Eu não sei se os congelamentos que estão ocorrendo no sistema operacional do seu computador estão sendo causados por algum conflito da versão do microcode do processador com a versão do driver de vídeo, mas não custa atualizar o microcode (mal não vai fazer: o pior que pode acontecer é não mudar nada) e testar se essa atualização melhora alguma coisa no funcionamento do processador e no comportamento do kernel em relação ao processador e à GPU que porventura esteja embutida no processador.
Notas de rodapé
¹ Um firmware é um pequeno programa que fica gravado no chip de um dispositivo eletrônico. O firmware facilita a interação de um ser humano (ou de outro programa) com o dispositivo no qual o firmware está instalado. O BIOS do computador, por exemplo, é um firmware: ele é um programa que permite que você configure o comportamento dos chips que se encontram na placa-mãe do computador.
² Algumas informações nas mensagens podem ser diferentes. No caso do meu computador, por exemplo, o comando informa que a versão do microcode precisa ser 0x25 ou posterior (o código hexadecimal 0x25 corresponde ao número decimal 37, portanto a versão 0x25 é a versão 37). A mensagem seguinte mostra "date = 2017-01-27", o que significa que em 27/01/2017 eu atualizei o microcode do processador. Caso você atualize o microcode em outro dia, a data mostrada ali evidentemente será a desse outro dia em que você atualizou o microcode.
-
Não apareceu nenhuma mensagem de bug. A única diferença que reparei foi que o driver do 4.8.17 parece ser mais antigo que o do 4.14.14 .
Kernell 4.8.17
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[ 1.436515] microcode: sig=0x306a9, pf=0x2, revision=0x10
[ 1.436545] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>
Kernell 4.14.14
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[ 1.454860] microcode: sig=0x306a9, pf=0x2, revision=0x10
[ 1.454896] microcode: Microcode Update Driver: v2.2.
-
Não apareceu nenhuma mensagem de bug. A única diferença que reparei foi que o driver do 4.8.17 parece ser mais antigo que o do 4.14.14 .
Kernell 4.8.17
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[ 1.436515] microcode: sig=0x306a9, pf=0x2, revision=0x10
[ 1.436545] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>
Kernell 4.14.14
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[ 1.454860] microcode: sig=0x306a9, pf=0x2, revision=0x10
[ 1.454896] microcode: Microcode Update Driver: v2.2.
Que bom que não apareceu mensagem de bug: sinal de que o kernel está sendo inicializado com um microcode adequado para o processador. :D O único lado negativo disso é que, se o microcode está atualizado, então os travamentos que você está eventualmente vivenciando não estão sendo provocados por causa da versão de microcode em uso para o processador, portanto o "culpado" pelo travamento é outro.
As diferenças de versão são normais: entre as versões de microcode disponíveis no sistema, cada kernel inicializa a versão mais adequada para que a interação dele (kernel) com o processador seja a melhor possível. O microcode é executado durante cada boot (inicialização do sistema operacional), então se você inicializar o sistema com uma versão de kernel diferente pode mesmo acontecer de outra versão de microcode ser inicializada junto com esse outro kernel.
-
Fiz um teste usando o Kernel 14.14 Lowlatency e surpreendentemente funcionou bem durante 2 dias , mas travou como antes :'( . Então mudei para o Kernel 13.16 Lowlatency e estou usando durante 3 dias sem problemas até agora . Lembrando que quando testei o Kernel 13.16 Generic , o travamento acontecia em questão de minutos ou horas após instalado . Será que tem algo a ver ? Teoricamente meu processador é fraco ( Celeron G1610 Dual Core ) . Sei que ainda é muito cedo para dar uma opinião formada sobre os travamentos . mas postei só pra deixar o relato .
EDITADO : Atualizando , não deu certo :'( , no quarto dia começou a travar e reiniciar a sessão , igual das outras vezes . Tentei com o v4.14.17 mas deu a mesma coisa inclusive travou em menos de 10 minutos quando ia abrir um arquivo no gerenciador Thunar . :'( . Estou voltando para o Kernel 4.8.17 .
Inclusive acho que podem apagar esta mensagem , já que não acrescentou nada ao tópico .
-
Fiz um teste usando o Kernel 14.14 Lowlatency e surpreendentemente funcionou bem durante 2 dias , mas travou como antes :'( . Então mudei para o Kernel 13.16 Lowlatency e estou usando durante 3 dias sem problemas até agora . Lembrando que quando testei o Kernel 13.16 Generic , o travamento acontecia em questão de minutos ou horas após instalado . Será que tem algo a ver ? Teoricamente meu processador é fraco ( Celeron G1610 Dual Core ) . Sei que ainda é muito cedo para dar uma opinião formada sobre os travamentos . mas postei só pra deixar o relato .
EDITADO : Atualizando , não deu certo :'( , no quarto dia começou a travar e reiniciar a sessão , igual das outras vezes . Tentei com o v4.14.17 mas deu a mesma coisa inclusive travou em menos de 10 minutos quando ia abrir um arquivo no gerenciador Thunar . :'( . Estou voltando para o Kernel 4.8.17 .
Inclusive acho que podem apagar esta mensagem , já que não acrescentou nada ao tópico .
Oi. :D
Eu ia comentar um pouco a respeito do kernel de baixa latência, mas daí me lembrei deste vídeo (https://www.youtube.com/watch?v=Fqf4WozCUlM) do Dionatan (blog "Diolinux") que explica superbem o que é kernel, latência e kernel low latency. Enfim: o vídeo é bem didático. Recomendo.
Em síntese: não vejo vantagem em você utilizar um kernel de baixa latência, a menos que você trabalhe com produção profissional de conteúdo audiovisual (filmes com áudio). O fato de o kernel ser de baixa latência não vai eliminar o bug, já que o problema de atraso na criação do ponteiro (razão do kernel panic) continuará presente.
-
Surgiu uma dúvida aqui . Quando o Ubuntu 16.04 foi lançado , o Kernel era 4.4.x ou 4.5.x . Quem usava sem problemas desde aquela época , ainda está usando o Kernel 4.4.x até os dias de hoje ? Pergunto isso , pois queria testar essas versões mais antigas do que a 4.7.10 .
Quando baixei o Xubuntu 16.04 Xenial e instalei , acho que foi em novembro de 2017 , não lembro qual o kernel original que veio com ele .
-
Surgiu uma dúvida aqui . Quando o Ubuntu 16.04 foi lançado , o Kernel era 4.4.x ou 4.5.x . Quem usava sem problemas desde aquela época , ainda está usando o Kernel 4.4.x até os dias de hoje ? Pergunto isso , pois queria testar essas versões mais antigas do que a 4.7.10 .
Quando baixei o Xubuntu 16.04 Xenial e instalei , acho que foi em novembro de 2017 , não lembro qual o kernel original que veio com ele .
De acordo com o cronograma do Ubuntu 16.04 (https://wiki.ubuntu.com/Kernel/Support?action=AttachFile&do=view&target=16.04.x+Ubuntu+Kernel+Support+Schedule.svg), a versão do kernel é fornecida assim:
- Ubuntu versão 16.04 (lançado em abril de 2016): kernel versão 4.4
- Ubuntu versão 16.04.1 (lançado em julho de 2016): kernel versão 4.4
- Ubuntu versão 16.04.2 (lançado em fevereiro de 2017): kernel versão 4.8
- Ubuntu versão 16.04.3 (lançado em agosto de 2017): kernel versão 4.10
- Ubuntu versão 16.04.4 (lançado em fevereiro de 2018): kernel versão 4.13
- Ubuntu versão 16.04.5 (lançado em agosto de 2018): kernel versão 4.15
Portanto, se p.ex. uma pessoa instalar o Ubuntu 16.04.1 o que essa pessoa vai ver é um sistema com kernel versão 4.4. Mas se essa pessoa executar um comando de atualização como sudo apt-get dist-upgrade -y ou então executar o update manager (gerenciador de atualizações) do Ubuntu e aceitar a sugestão de atualizar o kernel, então a versão do kernel será atualizada para a versão mais recente disponível de acordo com aquele cronograma (embora, por garantia, as versões anteriores do kernel sejam mantidas disponíveis no sistema).
Enfim: como normalmente as pessoas atualizam o sistema regularmente (seja via interface gráfica, seja via terminal), o mais provável é que atualmente a maioria das pessoas esteja realmente usando o kernel mais recente. Mas nada impede você de instalar um kernel mais antigo e em seguida selecionar manualmente esse kernel mais antigo (por intermédio do menu do GRUB, caso queira usar o kernel temporariamente, ou via configurações do GRUB, caso queira tornar permanente a inicialização desse kernel mais antigo). Outra maneira (mais radical) consiste em baixar o arquivo ISO de instalação de uma versão anterior do Ubuntu e então instalá-la. Exemplos de arquivos ISO "antigos" da versão 16.04:
- Ubuntu 16.04 Desktop de 64 bits (http://old-releases.ubuntu.com/releases/16.04.2/ubuntu-16.04-desktop-amd64.iso)
- Ubuntu 16.04.1 Desktop de 64 bits (http://old-releases.ubuntu.com/releases/16.04.2/ubuntu-16.04.1-desktop-amd64.iso)
- Ubuntu 16.04.2 Desktop de 64 bits (http://old-releases.ubuntu.com/releases/16.04.2/ubuntu-16.04.2-desktop-amd64.iso)
Lista completa: http://old-releases.ubuntu.com/releases/16.04.1/
Claro: a pessoa que instalar uma versão anterior à do Ubuntu 16.04.X atual deverá ter o cuidado de não atualizar os pacotes do kernel, caso contrário o kernel dessa versão mais antiga acabará sendo atualizado.