Sampayu

De nada. O commit bom é bem simples, apenas reativa o gerenciamento de energia do driver para dispositivos gráficos AMD. Acredito que não quebrará nada.

Olá, @Marcos FRM e quem mais esteja interessado neste assunto: concluí o RCB (reverse commit bisect). Surpreendentemente (digo: ao contrário do que eu imaginava), o primeiro commit a remover o bug não está na versão 4.6-rc1 do kernel, mas sim na 4.6-rc4. Trata-se do commit e9bef455af8eb0e837e179aab8988ae2649fd8d3: Revert "drm/amdgpu: disable runtime pm on PX laptops without dGPU power control" - This reverts commit bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1. Anexei um arquivo PDF contendo a tabela de commits e compilações que executei. Por causa da "surpresa" ao constatar que o kernel 4.6-rc1 também tinha o bug, tive de executar várias outras compilações. No total, foram 26 - daí a minha demora em voltar aqui. Meu report completo encontra-se disponível aqui (em inglês). Após isso, meu bug report no Launchpad passou a receber prioridade alta. Resta saber quanto tempo demorarão para aplicar a correção downstream (que é quando você pega uma correção presente numa versão mais recente e a aplica a versões mais antigas: no caso, nos kernels 4.4.X e 4.5.X). rcb.pdf

Obrigado.

Sobre o kenerl estável 4.7.2: fiz uns testes e ele realmente não tem o bug. Por isto, atualizei o tutorial. Sobre o bisect, estou fazendo aos poucos, desde a versão 4.5 do kernel até a versão 4.6-rc1: são mais de 6 mil commits, a compilação é demorada e eu tenho de testar uma por uma. Graças a técnica de bisect, não terei de testar os mais de 6 mil commits (imagine ter de compilar e testar kernel mais de 6 mil vezes...), mas mesmo com a técnica de bisect serão pelo menos 12 (provavelmente 13 ou 14) compilações diferentes que eu terei de testar até chegar ao commit responsável pela remoção do bug. No momento, estou compilando o 8º teste. Do teste 1 ao 7 o bug está presente, então, como já é de se esperar, o bug provavelmente foi removido numa versão do kernel 4.5 muito próxima à da compilação do "novo" kernel 4.6-rc1. Quando eu chegar a um resultado eu publico, aqui.

@AmarildoJr Mmmm, interessantes essas informações a respeito do kernel 4.9. Não sabia desse esforço em darem suporte a essas placas GCN. No meu cotidiano eu raramente testo kernels e módulos, geralmente só quando me deparo com um bug: aí eu saio à caça do problema. É por isso que acabo não ficando sabendo dessas atividades que estão em andamento. Também por isso (por não ser um hábito eu ver a última versão do kernel estável e logo atualizá-la), já há alguns dias eu não olhava as pastas em kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D. Mas agora fui lá e vi que foram criadas as pastas dos kernels 4.7 (4.7.0), 4.7.1 e 4.7.2. É impressionante como avança rápido o desenvolvimento do kernel do Linux! Dá até pena de comparar com o Windows. Melhor não comparar, hehe... Por outro lado, isso me deixa um pouco "perdido", pois fico sem saber qual kernel sugerir aos usuários: enquanto estou testando um, pode ser que outro mais recente surja e esteja igualmente livre do bug. Meu tutorial ficou obsoleto muito rapidamente, rs. De qualquer modo, seguindo a lógica de sempre se preferir o kernel stable ante o release candidate, o mais lógico me parece ser recomendar aos usuários a instalação da última versão do 4.7 mesmo. Como lá em kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D eu vi as pastas 4.7, 4.7.1 e 4.7.2 (e em www.kernel.org consta que a última versão estável é a 4.7.2), pelo visto o melhor a fazer é eu testar o kernel 4.7.2, daí se nada de anormal ocorrer durante alguns dias, atualizo o tutorial. Você pelo visto é entusiasta do desenvolvimento do kernel. Obrigado por me avisar a respeito dessas versões mais recentes do kernel.

Eu testei 4.6-rc1, o 4.6-rc5 e o 4.6-rc7. Como estou usando o kernel 4.6-rc1 há cerca de 1 mês e não tive problema nenhum, é a versão em que atualmente confio mais, o que não significa que os posteriores darão problema. Mas esses kernels passam por muitas alterações e eu não sei como eles irão se comportar nos computadores dos outros, no longo prazo. Enfim: escolhi o 4.6-rc1 para fazer o tutorial mais por ser o que estou usando mesmo, por ser o que eu posso confirmar que se encontra realmente bem estável. Quem quiser usar um kernel mais recente, eu sugeriria usar o 4.6-rc7, que foi um que usei por pouco mais de 2 dias contínuos (deixei o notebook ligado mais de 48h consecutivas, executando diversas tarefas) e não deu problema. Eu também cheguei a instalar e testar o 4.8-rc1, e ele também funcionou, porém quando eu o desinstalei ocorreu um problema estranho no meu GRUB e também no módulo amdgpu: tive de reinstalar ambos. Não entendi por que isso ocorreu, mas me deu um trabalhinho para recuperar e conseguir voltar a usar meu 4.6-rc1. São essas coisas esquisitas e inesperadas que me deixam com receio de recomendar a instalação do kernel mais novo: à medida que os kernels vão sendo atualizados e novas versões vão surgindo, bugs vão sendo eliminados deles porém outros bugs vão surgindo. Como o 4.6-rc1 é o que estou usando no dia-a-dia e já constatei que está realmente estável, acabei achando melhor recomendar esse com o qual sinto mais segurança. De qualquer modo, acredito que o tutorial esteja intuitivo o suficiente para que os usuários mais avançados consigam usar a lógica do tutorial para instalar alguma versão mais recente, se quiser. Nos fóruns em língua inglesa há alguns usuários indicando a instalação do 4.6-rc7. Após fazer o RCB posso de repente instalar o 4.6-rc7 e testar por uns dias. Se o kernel se mostrar estável, aí atualizo o tutorial. O importante é livrar os usuários do bug (independentemente da versão de kernel que se instale): quando eu ainda não sabia desse bug, estava já ficando desesperado, porque o computador "congelava" toda hora e com isso me obrigava a ficar desligando o computador "no dedo", o que é péssimo e pode inclusive danificar algum componente eletrônico. Se eu testar o 4.6-rc7 (ou se alguém que tenha computador com GPU AMD decidir instalar o 4.6-rc7 e testar) por alguns dias, e após isso ficar constatado que o 4.6-rc7 não apenas está livre do bug como também está estável (aparentemente não possui nenhum bug novo que impeça o uso regular do computador), atualizo o tutorial. Mas vamos por partes, rs: ainda tenho de arrumar tempo pra fazer o RCB. Será uma ajuda bem-vinda se algum usuário de GPU AMD decidir testar o kernel 4.6-rc7 e puder confirmar que ele também está bem estável.

O Christopher M. Penalver (Launchpad) pediu para eu realizar um reverse commit bisect (RCB), que é um processo que possibilita investigar qual foi o bad commit que causou o bug no kernel. Se eu fizer isso e encontrar o último commit ruim e o primeiro commit bom, ele vai investigar o diff desses commits para verificar quais as mudanças realizadas no código que resultaram na eliminação do bug. Deste modo, teoricamente ele conseguirá identificar qual é o bug e daí aplicar o patch downstream, ou seja, corrigir todos os kernels 4.4 e 4.5... ...mas ele me pediu isso no dia 28/08 e eu ainda não tive tempo de parar para fazer o RCB. Tenho pouco tempo livre, e fazer RCB é trabalhoso e demorado. Pretendo fazer, para que corrijam os kernels, mas veja que estamos já entrando em setembro, daqui a pouco chega outubro e o *Ubuntu 16.10 será lançado. Enfim: a minha sugestão é que quem estiver com esse problema não fique aguardando um eventual kernel 4.4 corrigido. O mais prático, fácil e cômodo de se fazer é seguir o que expliquei lá no tutorial mesmo: baixar os pacotes do kernel 4.6-rc1 e instalá-los. Assim é bem mais cômodo e deixa o computador funcional.

Bacana, obrigado. Vou ficar mais ligado nesses tópicos Linux que surgem por aqui.

Fiz um tutorial explicando como resolver esse problema: http://ubuntuforum-br.org/index.php/topic,120620.0.html (o uso do kernel 4.6-rc1 é preferível, por ser atualmente mais estável, por isso no tutorial eu ensino a instalação do kernel 4.6-rc1)

Somente agora vi este tópico, há tempos não contribuo por aqui. Resolvi efetuar login e comentar que meu notebook é o mesmo que o seu: um notebook Dell Inspiron 5548. Ele vem com gráfico híbrido: uma GPU (unidade de processamento gráfico) Intel Broadwell-U integrada (embutida na CPU) e também uma GPU AMD/ATI Topaz XT (modelo Radeon R7 M260/M265). Alguns kernels do Linux dão problema com computadores que têm gráficos híbridos, não lidam direito com dois drivers de vídeo simultâneos (esses drivers são módulos do kernel, daí a importância de o kernel ser capaz de lidar com tais drivers). Quando eu ainda usava o XUbuntu 14.04, o driver gráfico da Intel (esse módulo chama-se i915) funcionava perfeitamente com os kernels versão 3.X, porém o gráfico proprietário da AMD (um módulo denominado fglrx), embora funcionasse muito melhor que o driver AMD de código aberto (módulo amdgpu), era bastante chato de instalar: um verdadeiro parto! Mas funcionava muito bem. Porém, com o advento do *Ubuntu (Ubuntu, XUbuntu, KUbuntu etc.) versão 16.04 (que vem com kernel versão 4.4.X) as coisas mudaram: a AMD desistiu de continuar desenvolvendo o driver fglrx e, por isto, a partir do 16.04 o kernel vem por padrão com o módulo amdgpu, que, diga-se de passagem, já melhorou bastante, está mais bem construído. Quanto ao módulo i915, ele continua sendo o padrão para as GPU da Intel, nos *Ubuntu 16.04, e está funcionando sem problemas. Essas travamentos, porém, ocorreram no meu laptop, e estão ocorrendo no seu provavelmente pelo mesmo motivo: um bad commit (algum código malfeito) inserido nos kernels 4.4.X causou um problema de funcionamento com o módulo amdgpu. Há diversas reclamações como a sua, Internet afora, e alguns relatórios de bug já foram abertos (eu mesmo abri um lá no Launchpad). Embora você não tenha fornecido praticamente informação nenhuma relativa ao problema que está ocorrendo com seu laptop, muito provavelmente o problema é o mesmo que estava ocorrendo no meu notebook: congelamentos, mensagens de "kernel panic" com erro do tipo "NULL pointer dereference" etc. Uma forma simples de provocar o congelamento é executar este comando: DRI_PRIME=1 glxgears Se o comando acima fizer seu computador travar/congelar, é pane de interação entre o módulo amdgpu e o kernel do Linux. Embora o bug no kernel ainda não tenha sido identificado, eu consegui descobrir que o bug acompanhou os kernels do Linux versões 4.4.X e 4.5.X, mas a partir da versão 4.6-rc1 (que é a compilação 4.6.0-040600rc1-generic) o bug foi removido por um "commit benéfico". Eu recentemente publiquei um comentário-tutorial lá no Viva o Linux (vide o comentário nº 6), explicando como instalar a versão 4.6-rc7 do kernel. Essa versão não tem o bug e funciona perfeitamente bem com o módulo amdgpu, inclusive em computadores híbridos (gráficos Intel + AMD). O arquivo PDF anexo é o comentário-tutorial que publiquei lá. Resolvi salvá-lo aqui em PDF porque se o autor daquele tópico resolver excluir o tópico, meu comentário-tutorial será excluído junto, e daí todas as explicações que postei lá serão perdidas. O PDF anexo é uma "cópia de segurança". Se quiser instalar a versão mais recente do kernel (que eu ainda não testei, mas, pelo que li nos logs da compilação, corrigiu ainda mais bugs relacionados à interação entre o kernel e o módulo amdgpu), basta usar estes três arquivos, quando for instalar o kernel (ao invés de baixar os três pacotes .DEB que eu informei no meu comentário-tutorial): 1 - http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1/linux-headers-4.8.0-040800rc1_4.8.0-040800rc1.201608072231_all.deb 2 - http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1/linux-headers-4.8.0-040800rc1-generic_4.8.0-040800rc1.201608072231_amd64.deb 3 - http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1/linux-image-4.8.0-040800rc1-generic_4.8.0-040800rc1.201608072231_amd64.deb É isso! tutorial_fix_kernel_amdgpu_ubuntu.pdf

Tive um problema similar com meu SSD Kingston V300 novinho em folha, quando fui instalá-lo no meu velho Macbook Pro 13" unibody mid-2009. Mas o SSD estranhamente funcionava bem quando eu o conectava a uma docking station ligada ao meu Macbook via porta USB. Após muito sofrimento com tentativas frustradas de instalar o OS X Snow Leopard, idem o Yosemite e o El Capitan, finalmente tive a "brilhante" ideia de levar à assistência técnica e pedir para trocarem o cabo SATA. Tadá! Era problema no cabo - não no SSD. Depois disso, nunca mais tive problemas com o SSD.

Obrigado, Fernando, pelo elogio. E valeu pela dica. Realmente, se a pessoa já dispuser das dependências corretas instaladas no sistema (apenas o arquivo de controle de dependências do pacote estiver errado), usar o dpkg com a opção --force-depends é uma solução bem prática.

O tutorial que aqui constava foi definitivamente movido para o fórum do Ubuntu, que é mais apropriado para este tema, e portanto será doravante mantido atualizado somente naquele fórum. Consequentemente, considero este tópico fechado, no fórum do Clube do Hardware.

Como eu havia comentado antes, tudo é relativo (e por isto é questionável/ponderável), inclusive sua última afirmação. Caso domine a língua inglesa, pode ler este breve artigo, que essencialmente mostra que o software GNU representa apenas 8% de uma distribuição Linux convencional e que dentro desse pequeno universo de 8% somente o gdb (GNU debugger) parece ainda não dispor de uma boa alternativa, no mundo do software: todas as demais peças de software GNU usadas nas distribuições GNU/Linux atualmente já podem ser substituídas por alternativas. Além disso, o que dá vida a um sistema é uma série de peças de software, inclusive uma infinidade de bibliotecas, e o fato é que menos de 2% das bibliotecas usadas em um sistema GNU/Linux tem origem no projeto GNU: todo o restante é oriundo de inúmeros outros projetos. Enfim: eu sei que, assim como qualquer kernel (de qualquer sistema), o kernel Linux sozinho não serve essencialmente para "nada" (embora ele tenha sido o ponto de partida para o desenvolvimento do sistema Android) e que as distribuições GNU/Linux historicamente têm usado software GNU, e que é por isto (aliás, eu diria que é mais pelas razões históricas do que pela "participação no sistema") que eu mesmo - que acompanho a "vida" do Linux desde que ele surgiu, em 1991 - costumo escrever "GNU/Linux". Mas, francamente, Alexandre: na minha opinião, isso é uma grande bobagem, porque é relativo (e, por isto, subjetivo), sabe? É muita picuinha para algo que não é exatamente relevante. Se você (por exemplo) considerar que o software GNU que vem na distribuição colabora com algumas das (não todas as) funções mais "essenciais" do sistema (embora o primeiro processo do kernel seja o init, que não é software GNU: foi desenvolvido na Bell Labs. Mas hoje em dia está sendo substituído pelo daemon systemd, que é da GNU), até que faz sentido escrever "GNU/Linux". Porém, se você observar o quão pequenos são aqueles 8% e considerar o fato de que praticamente todo o software GNU pode ser substituído por software não-GNU (o que significa que o Linux pode ser o que ele quiser, independentemente de existir ou não GNU), aí já surge um contra-argumento ao meu ver muitíssimo forte contra a grafia "GNU/Linux". Salvo nas ocasiões em que estou com preguiça de digitar, de maneira geral eu grafo "GNU/Linux" mesmo. Mas isso sou eu e apenas pelo fato de eu reconhecer (mais emocionalmente e por razões históricas do que racionalmente) a colaboração que várias peças de software livre da Free Software Foundation (FSF), criadas dentro do projeto GNU, tiveram para ajudar a fazer as distribuições Linux se popularizarem (na forma de sistemas GNU/Linux). Mas daí a transformar a grafia "GNU/Linux" em uma "regra" ou "obrigação" ética e ortográfica (como você fez quando quis me corrigir, no seu primeiro post), aí eu já acho inadequado, porque neste tema controverso não existe Verdade Absoluta: cabe a cada um decidir quais argumentos têm maior peso e daí escolher como irá se referir ao sistema. Em outras palavras: ao que me parece, o mais saudável é apresentar essas informações para as pessoas (como as do artigo que eu mencionei) e deixar a critério de cada pessoa a liberdade para decidir se a abreviatura GNU merece ou não fazer parte do nome do sistema (e se, caso mereça, vale a pena ficar se dando o trabalho de sempre digitar isso, hehe. Eu às vezes simplesmente não tenho paciência!). Caso queira dar continuidade a esta discussão, peço que crie um novo tópico em Geral, para que neste tópico aqui sejam incluídos somente posts referentes à instalação do java da Sun/Oracle. Ouquêi?

Haaa, então funcionou. Show de bola!

Hahaha, só você! Eu sei disso. Aliás, eu costumo escrever GNU/Linux mesmo, tanto que é assim que está grafado ao longo de todo o texto do tutorial (porque Linux é só o kernel, e a maior parte das aplicações e serviços em execução "em torno do kernel" são da FSF e/ou licenciadas sob os termos da licença GNU, blá blá blá...). Mas às vezes dá preguiça de escrever. É um porre ter que ficar digitando GNU/ toda vez que vou digitar a palavra "Linux". Apesar de eu achar mais justo usar a denominação GNU/Linux, essa é uma questão controversa. Há quem defenda que o sistema operacional é só o kernel mesmo, o núcleo dele, porque somente o kernel define a identidade do sistema: quando você acrescenta os programas, surge então o conceito de distribuição (kernel + programas, sendo que essa palavra "programas" ainda pode ser subdividida em programas que interagem mais estreitamente com o kernel, como os daemons, o init, o shell bash, e os programas de interface gráfica de usuário, como é o caso dos navegadores web, processadores de planilha eletrônica, aplicativos para assistir a vídeos de DVD, Blueray etc.). O VLC, por exemplo, foi desenvolvido no GNU/Linux, mas hoje em dia é usado também no Windows, então qual seria a identidade do VLC? E o mesmo pode ser dito a respeito de outras aplicações. Mas se o kernel do Linux for "portado" para dentro do Windows, essa nova "distribuição Windows" vai ter que mudar de nome, algo como "Microsoft Linux", porque o núcleo do sistema será Linux. Baseando-se na lógica supra, há quem defenda que o mais adequado é dar crédito à GNU exclusivamente no caso dos programas desenvolvidos dentro da comunidade FSF/GNU. Exemplos: GNU gcc (ao invés de somente gcc), GNU Emacs (ao invés de simplesmente Emacs), e assim por diante. Agora imagine o trabalho que dará escrever GNU gcc, GNU Emacs, Microsoft Windows (ao invés de simplesmente Windows), Apple OS X (ao invés de simplesmente OS X), VideoLAN VLC (ao invés de somente VLC), The Document Foundation LibreOffice (ao invés de simplesmente LibreOffice), e assim por diante... Para não fugir muito do tópico, "java" também é uma palavra que confunde, porque hoje em dia há máquinas virtuais java escritas por terceiros. Eu costumo escrever "Sun JRE", "Oracle JRE", "Sun/Oracle JRE" e outras variantes para me referir especificamente à versão do ambiente de execução Java que é desenvolvido pela Sun Microsystems e distribuído pela sua proprietária, a empresa Oracle, porque daí fica claro que a máquina virtual java é a que vem dentro desse JRE aí. E ainda assim essas não são denominações muito precisas, já que o OpenJDK, por exemplo, também é mantido pela Oracle (embora o JRE e o OpenJDK possuam códigos diferentes e o JRE não possa ser distribuído, ao passo que o OpenJDK pode e é por isto que ele passou a vir junto com algumas distribuições "GNU/Linux"). Há também o GIJ (ou "GNU GIJ", para ficar politicamente correto, rs), que eu nunca testei mas passou a vir nas distribuições Ubuntu. Mas ele é apenas um JIT (interpretador de códigos java binários). Uma JVM é mais do que isso, e um JRE é ainda mais. No projeto Wikimedia Commons há um diagrama que ilustra essa estrutura. PS: no caso de uma distribuição Linux repleta de programas, o nome "politicamente correto" da distribuição teria que ser algo como GNU/VideoLAN/The Document Foundation/.../The GNOME Foundation/Oracle/Linux. Mas este texto foi apenas para estimular uma reflexão a respeito da relatividade das coisas.

Olá. O tutorial foi elaborado para quem usa o JRE da Sun/Oracle no Ubuntu e outras distribuições baseadas no Debian, então para mim fica complicado elaborar uma solução exata para o seu caso, já que seu sistema é o Fedora, no qual nunca mexi e que não se baseia no Debian, e considerando-se ainda que, pelo visto, o java do seu sistema não é um JRE mas sim um JDK (kit de desenvolvimento java) de código livre denominado OpenJDK. Também não sei se o seu sistema adota o update-alternatives, que é o que possibilita possuir diferentes versões de um mesmo aplicativo (deferentes versões feitas por um mesmo desenvolvedor ou por vários, como é o caso do OpenJDK, do JRE fornecido pela Sun/Oracle etc.) e determinar, via update-alternatives, qual dessas versões você desejará utilizar por "padrão", no seu sistema. Apresentados esses "poréns", o que posso dizer para tentar lhe ajudar é que, diante das mensagens que você postou aqui, seu sistema está, por padrão, usando o java OpenJDK, e por isto evidentemente a página de testes do java que fica no website da Sun/Oracle não vai funcionar, pois aquela página de testes existe apenas para testar se o JRE da Sun/Oracle está instalado em seu sistema, não o OpenJDK. O OpenJDK também é mantido pela Sun/Oracle, mas o código dele é diferente do JRE não-livre. Embora recentemente o OpenJDK tenha passado nos testes de compatibilidade (o que em tese significaria que tudo o que o JRE da Sun/Oracle é capaz de executar o OpenJDK também é), o fato é que na prática os códigos dos dois são diferentes e não são 100% intercambiáveis, razão por que ainda há situações concretas nas quais somente com o Sun/Oracle JRE você consegue executar aplicações web escritas em java. Talvez isso mude, no futuro (a tendência tem sido essa), e daí um dia passemos todos a usar exclusivamente o OpenJDK, mas por ora esse dia ainda não chegou. Que o digam os websites dos bancos, como o do Brasil, ao qual eu só consigo ter acesso usando o Sun/Oracle JRE (embora já haja alguns relatos de OpenJDK funcionando em alguns bancos e navegadores, mas não é uma situação geral, que abranja todos os usuários, por isto a necessidade de manter este tutorial). Felizmente, embora o Fedora seja diferente do Ubuntu e das distribuições baseadas em Debian, ele ainda é um Linux, então comandos do shell funcionarão. Em termos práticos, se quiser tentar deixar o JRE como padrão, tente estas ações: No Chrome e no Chromium, vá em chrome://plugins e clique no botão "Desativar" para desabilitar o plugin java do OpenJDK. Para fazer isso no Opera, acesse about:plugins e clique no botão "Desabilitar" que estiver ao lado do java. Já no Firefox você deverá ir em Tools => Add-ons (Ferramentas => Complementos), em seguida selecionar a aba "Plugins", e daí, na linha do java, selecionar a opção "Desabilitar" ou "Never Activate" ("Nunca Ativar"). Feito isso, o próximo passo é instalar o JRE. Como o seu sistema é o Fedora, talvez ele trabalhe com pacotes RPM, mas este tutorial usa a instalação manual, por isto pegue o tarball mesmo (arquivo .tar.gz), como explicado na seção 1 do tutorial. Após executar o item 1.1 do tutorial, execute o item 1.2. Agora tente executar o item 1.3: se o seu sistema dispuser de update-alternatives, que bom. Se não dispuser, ignore o item 1.3 e vamos em frente, pois se o seu sistema não tem update-alternatives então tudo pode ser feito manualmente sem necessidade de configurar nenhum update-alternatives, e se o seu sistema tem update-alternatives então o comando do item 1.3 acabou de configurá-lo. Ao invés de executar o comando do item 1.4, execute o comando completo, que é /opt/java/jre/bin/java -version Se o comando informou que você está com a versão mais recente do java, então ok, o próximo passo agora é executar o item 1.5. Neste ponto, você terá que confirmar aí no seu sistema se as pastas dos seus navegadores são as mesmas que eu mostrei no item 1.5, já que no Fedora elas podem estar em locais diferentes. Após verificar qual é a pasta em que cada um dos seus navegadores está instalado, execute os comandos do item 1.5, só que evidentemente usando o caminho correto deles. O importante é criar a pasta plugins dentro da pasta de bibliotecas do seu navegador, caso essa pasta de plugins ainda não exista, para que o seu navegador reconheça os plugins que você colocar dentro dela. Execute o item 1.6. No item 1.7, você usará o comando ls para criar um link simbólico (um "atalho") dentro da pasta de plugins de cada um dos seus navegadores. Como no seu sistema essas pastas podem estar em locais diferentes dos indicados no item 1.5, substitua, em cada comando ls, o caminho da pasta de plugins do seu navegador pelo caminho correto aí do seu sistema. Se você não sabe onde ficam as pastas dos seus navegadores, terá que investigar: use o comando locate ou pergunte a outros usuários do Fedora, por exemplo. Eu aqui não tenho como reproduzir o seu contexto, embora acredite que, salvo o Chrome, seus demais navegadores estejam instalados em algum local dentro da pasta /usr. O resto é igual: esvaziar o cache dos navegadores, fechar os navegadores, em seguida reabri-los, acessar a página de testes da Sun/Oracle para verificar se agora o plugin do Sun/Oracle JRE é detectado etc. A intenção do roteiro acima foi "não destruir" o OpenJDK do seu sistema: o OpenJDK continuará instalado, mas será desabilitado dentro de cada um dos seus navegadores, para que em seguida o JRE da Sun/Oracle seja manualmente instalado e vinculado aos seus navegadores, que após isso passarão a reconhecer o plugin. Espero ter ajudado.

Haha, bacana, show de bola! Então mais um usuário com o problema do java resolvido, rs. É gratificante ler essas mensagens. Se quiser dizer a eles o que você fez, por mim tudo bem, já fiz o tutorial mesmo para que ficasse publicamente visível e pudesse ser usado por todos, inclusive o pessoal de suporte dos bancos. A intenção é mesmo atingir o maior número possível de pessoas, para reduzir a possibilidade de alguém ter dificuldades com o java no Linux e não conseguir resolvê-la.

Se você acessar /opt/java/jre/bin e em seguida executar somente jcontrol, isto a priori fará mesmo o painel de controle java ser executado. Porém, recentemente deparei-me com um usuário que possui um aplicativo de mesmo nome (jcontrol) no sistema dele e também no PATH do sistema, embora o aplicativo não tenha nada a ver com o painel de controle java. Por isto, onde quer que esse usuário estivesse (em qualquer caminho/pasta), o comando jcontrol sempre executava o outro programa, ao invés de executar o painel de controle java. A partir daí resolvi adotar uma postura um pouco mais neurótica, rs: colocando o ./ antes do jcontrol você força a execução do programa que está na pasta em que você atualmente se encontra. Quanto ao segundo problema, no momento estou achando muito esquisito e não consigo determinar o que possa estar causando isso, mas arrisco três hipóteses: [1] pode ainda haver "lixo" em seu sistema, [2] seu navegador pode estar desatualizado, [3] seu navegador pode estar identificando dois ou mais plugins java em seu sistema. Para resolver [1], instale um aplicativo denominado BleachBit e configure-o para excluir tudo quanto é cache: dos seus navegadores, de todos os JRE que ele identificar etc. Para resolver [2], dependendo do navegador que você esteja usando pode ser suficiente abrir o navegador, ir em "Sobre o <nome_do_navegador>" e verificar se o navegador busca automaticamente por atualizações. Se ele não fizer isso, anote a versão dele e em seguida acesse a página do desenvolvedor dele para ver qual é a mais recente versão estável disponível para o seu navegador. Para resolver [3], acesse about:plugins ou chrome://plugins no seu navegador, conforme o caso, e daí procure a palavra "java". Veja se não aparecem dois plugins java, ao invés de apenas um. Se, por exemplo, o arquivo libnpjp2.so estiver aparecendo duas vezes, uma em /opt/java/jre... e outra em um outro caminho, como por exemplo alguma subpasta de /usr, será necessário desinstalar esse outro JRE. Caso não consiga resolver o problema, no seu próximo post informe o navegador (e versão do navegador) que você está usando, se o seu sistema é de 64 ou 32 bits, e se você chegou a executar os comandos que constam na seção 4.1. Ainda: se estiver no Chrome, experimente executar o Chrome junto com --allow-outdated-plugins e veja se mesmo assim o problema ocorre. E, independentemente do navegador que esteja usando, experimente executar os comandos sudo mkdir -p /etc/.java/.systemPrefs e sudo chmod 755 -R /etc/.java. Caso esteja usando o Firefox, observe que eu incluí uma nota na seção 1.5 a respeito da pasta de plugins do Firefox ter sido recentemente renomeada para firefox-addons. Se o seu plugin ainda estiver dentro da pasta "firefox" (sem o "addons"), esse pode ser o problema.

Eu me lembro do André. Lamentei o falecimento dele, embora nunca o tenha conhecido pessoalmente. Pessoa bacana. Se há vida após a morte, desejo que nela ele esteja muito bem. Mas, para não sair do foco do tópico, aproveito para ratificar que existem tutoriais também sobre o OpenJDK e o GIJ, que passaram a vir junto com o Ubuntu, embora eu não aborde esses interpretadores no meu tutorial pelo fato de ele ser voltado exclusivamente ao que é fornecido pela Sun/Oracle.

Bacana. Eu não tenho o hábito de ficar criando tutoriais, mas este aqui eu acabei criando porque percebi que (na época) havia um monte de pessoas perdidas nas instalações do OpenJDK, tentando fazer o Java da Sun/Oracle funcionar, postando perguntas na internet a respeito do tema etc., e quase todos os tutoriais na época só diziam bobagens que não funcionavam (tanto que nenhum deles me ajudou e foi isto que me motivou a descobrir sozinho a solução para o problema e em seguida compartilhá-la com os demais linuxists). Algum tempo depois, surgiu o PPA do webupd8team e isso facilitou bastante a vida de muita gente (eu diria que da maioria dos usuários das distros que usam PPA). Mas, como sempre existem aqueles usuários que, assim como eu, gostam de saber o que estão fazendo e são meio neuróticos em relação à utilização de repositórios de terceiros, estou mantendo o tutorial atualizado. Também há os casos de quem não usa uma distro que use PPA, daí a instalação manual do Java pode ser o único método disponível. Felizmente, até hoje este tutorial tem tido uma boa taxa de visitação diária, então acredito que continue sendo útil a muitas pessoas. Enquanto a taxa de visitação diária continuar boa, continuarei atualizando o tutorial. PS: a quem porventura venha a ler este post, o WebUpd8 (acrônimo para "web update"), também conhecido como webupd8team ("time do web update"), website oficial http://www.webupd8.org, é um blog de Ubuntu e Linux que diariamente publica notícias, dicas e avaliações de aplicativos Linux. A equipe acompanha o desenvolvimento do Ubuntu e do GNOME. Particularmente, não gosto de usar o PPA deles para instalar o Java, mas esta é apenas a minha preferência: muitos usuários usam o PPA Java do WebUpd8 e elogiam a comodidade que há nisso. Para quem está com inglês em dia, a leitura diária do blog do WebUpd8 é recomendada. O endereço do PPA deles para a instalação do Sun/Oracle Java fica em https://launchpad.net/~webupd8team/+archive/java

Transcrição do texto que consta nas notas preliminares do meu tutorial: Em outras palavras: eu sei (e provavelmente a maioria dos que consultam este tutorial sabe) que existem diversos modos de se instalar o java, e a maior parte desses modos (se não todos) é mais simples e/ou mais prática e/ou mais cômoda. Esse aí mesmo, que consiste em usar o repositório do webupd8team, é um modo muito popular, devido à praticidade dele. Atualmente, o que não falta na internet é tutorial ensinando a instalar o java da Sun/Oracle a partir do repositório PPA que é mantido pela equipe conhecida como webupd8team. Mas o meu tutorial foi elaborado para suprir as necessidades dos demais, ou seja, daqueles que, por exemplo: Não confiam em instalar o java da Sun/Oracle a partir de repositórios de terceiros (como é o caso do repositório do webupd8team), porque têm receio de que esses terceiros estejam distribuindo arquivos que foram manipulados/modificados para (por exemplo) obter acesso indevido a informações do seu sistema. Por isto, preferem obter os arquivos do java diretamente no repositório oficial da Sun/Oracle. Por alguma razão não conseguiram fazer o java funcionar segundo outros métodos de instalação e, por isto, resolveram "apelar" para um método manual de instalação, que é o ensinado neste tutorial, porque métodos manuais geralmente reduzem a possibilidade de algo dar errado. Gostam de personalizar a instalação e entender o que estão fazendo.

Recentemente aconteceu de eu tentar instalar o pacote google-chrome-stable e não conseguir porque, de acordo com o que consta no pacote .deb, o pacote precisa de três bibliotecas e essas bibliotecas não podem ser instaladas em meu sistema. O problema é que isso é um bug do pacote .deb: as bibliotecas que ele diz que eu tenho que ter não têm que ser instaladas em meu sistema não, mas elas também não devem fazer parte dos pré-requisitos (dependências) do pacote .deb, pois as bibliotecas das quais o pacote necessita são outras três, não as que ele menciona. O erro, portanto, está nos nomes das bibliotecas das quais o pacote diz necessitar. Como um dia esse bug pode acontecer com (e afetar) você, fique sabendo que pode ter conserto: se você souber quais são os nomes corretos dos arquivos/dependências que você tem que ter no seu sistema, e se tais dependências estiverem instaladas no seu sistema (ou você souber como instalá-las), então tudo o que você precisa fazer, depois de estar com as dependências corretas instaladas em seu sistema, é editar o arquivo de controle de dependências que se encontra dentro do pacote .deb problemático. Mas como fazer para editar o arquivo de controle de dependências? Simples: siga o roteiro abaixo. Abra um editor de texto bem básico, como por exemplo o GEdit, o Mousepad ou o Leafpad, e cole este código dentro da janela dele: #!/bin/bashif [[ -z "$1" ]]; thenecho "Syntax: $0 debfile"exit 1fiDEBFILE="$1"TMPDIR=`mktemp -d /tmp/deb.XXXXXXXXXX` || exit 1OUTPUT=`basename "$DEBFILE" .deb`.editado.debif [[ -e "$OUTPUT" ]]; thenecho "$OUTPUT existe."rm -r "$TMPDIR"exit 1fidpkg-deb -x "$DEBFILE" "$TMPDIR"dpkg-deb --control "$DEBFILE" "$TMPDIR"/DEBIANif [[ ! -e "$TMPDIR"/DEBIAN/control ]]; thenecho DEBIAN/control non ecsiste! =Prm -r "$TMPDIR"exit 1fiCONTROL="$TMPDIR"/DEBIAN/controlMOD=`stat -c "%y" "$CONTROL"`gedit "$CONTROL"if [[ "$MOD" == `stat -c "%y" "$CONTROL"` ]]; thenecho Inalterado.elseecho Construindo novo pacote deb...dpkg -b "$TMPDIR" "$OUTPUT"firm -r "$TMPDIR" A palavra gedit que aparece no código do script pode ser modificada. Aquela linha de comando será usada para fazer o aplicativo GEdit abrir para edição o arquivo de controle de versões/dependências que se encontra dentro do pacote .deb. Se você não possui o GEdit instalado em seu sistema, instale-o executando este comando, no terminal: sudo apt-get install geditAlternativamente, você pode substituir a palavra gedit pelo nome do seu editor de textos padrão ou preferido. Exemplo: se você possui o Mousepad instalado no seu sistema (é o que eu uso, por exemplo), coloque a palavra mousepad no lugar da palavra gedit. Neste caso, o código do script ficará assim: mousepad "$CONTROL"Se o seu editor for o Leafpad, então o código do script ficará assim: leafpad "$CONTROL"Quer saber se você tem o GEdit instalado? Abra o terminal e execute este comando: gedit &Se o GEdit estiver instalado, uma janela dele surgirá na sua frente. O mesmo método funciona também com o Mousepad e com o Leafpad: mousepad & leafpad & Agora salve o arquivo onde você quiser e com o nome que você quiser. Ah: e não é preciso adicionar extensão nenhuma ao arquivo. Só para eu ter uma referência neste tutorial, vou supor que você salvou o arquivo com o nome edd (a palavra vem de editor de dependências) e que esse arquivo foi gravado dentro de ~/Downloads Nota: o símbolo ~ é um atalho que sempre aponta para a pasta pessoal do usuário que está logado no sistema. Se, por exemplo, a sua pasta pessoal for /home/fulano, então ~ é a mesma coisa que /home/fulano. Supondo que dentro da sua pasta pessoal exista uma pasta Downloads, o caminho ~/Downloads significa que você salvou o arquivo edd dentro da pasta Downloads que existe dentro da sua pasta pessoal. Outro exemplo: se a sua conta é cicrano e o seu sistema GNU/Linux cria as contas dos usuários dentro da pasta /home, então ~ é a mesma coisa que /home/cicrano e ~/Downloads é a mesma coisa que /home/cicrano/Downloads, entendeu? Agora que você criou o arquivo edd e o salvou dentro de ~/Downloads, é necessário tornar o arquivo executável, para que o seu sistema compreenda que ele é um script. Vamos lá. Abra o terminal do shell e execute este comando, para tornar o seu arquivo executável: sudo chmod +x ~/Downloads/edd...lembrando que se você não salvou o arquivo com o nome edd e/ou não o gravou dentro de ~/Downloads, então você precisa colocar os valores corretos no comando acima e em todos os outros comandos que eu vier a apresentar neste tutorial contendo referências ao edd e/ou ao caminho ~/Downloads. Fique esperto/a! Agora que o script é executável, faça download do pacote .deb que você deseja corrigir. Apenas para eu ter uma referência neste tutorial, vou supor que você está querendo corrigir o bug que aconteceu no pacote do Google Chrome. Mas lembre-se: o script serve para corrigir qualquer pacote .deb que internamente possua um arquivo de controle de dependências. Bem, supondo que você esteja querendo corrigir o bug do pacote do Google Chrome (que é para sistemas de 32 bits), você certamente acessou o website oficial do Google Chrome e fez download do pacote google-chrome-stable_current_i386.deb. Eu vou assumir que você salvou esse pacote .deb dentro de ~/Downloads, ok? Bem, continuando: se você havia tentado instalar esse pacote e acabou quebrando a instalação dele (o aplicativo não funciona mais), execute os comandos abaixo para desinstalar o aplicativo e limpar o repositório do APT. Mas lembre-se de executar todos os comandos na exata sequência em que aparecem, de cima para baixo e dentro de uma única janela do terminal: sudo apt-get remove google-chrome-stable sudo apt-get clean sudo apt-get autoremove Notas: se após a execução do autoremove o sistema perguntar se você deseja desinstalar alguma coisa, confirme. E, claro: se o pacote que você está manipulando não é o do Google Chrome, então substitua aquele google-chrome-stable pelo nome correto do pacote. Não sabe qual é o nome correto do pacote .deb? Neste caso, recomendo instalar o aplicativo Synaptic. Ele facilita bastante a pesquisa de nomes de pacotes .deb no seu repositório. Este é o comando para instalar o Synaptic: sudo apt-get install synapticDepois basta executar o Synaptic a partir do menu do seu GNU/Linux. Caso não encontre o Synaptic pelo menu da interface gráfica, abra uma nova janela do terminal e execute este comando: sudo synaptic Agora que o seu repositório local de pacotes está limpo (você já fechou o Synaptic e a janela do terminal), você precisa executar o seu script. Abra uma nova janela do terminal e execute estes comandos: cd ~/Downloads ./edd ./google-chrome-stable_current_i386.debNovamente: estou supondo que você salvou o script com o nome edd, dentro de ~/Downloads, e que você fez download do pacote google-chrome-stable_current_i386.deb também para dentro de ~/Downloads, portanto, neste exemplo fictício, tanto o script quanto o pacote .deb estão dentro de ~/Downloads O script vai extrair o conteúdo do pacote .deb e usar o seu editor de textos (aquele que você definiu no item 2) para carregar na sua frente uma janela contendo o código do arquivo de controle de dependências. Esse arquivo de controle nada mais é que um arquivo texto, portanto ele pode ser editado e salvo. Tudo o que você precisa fazer é corrigir os nomes e/ou as versões dos arquivos que são mencionados dentro do arquivo de controle, clicar no botão "Salvar" e então fechar a janela do editor de textos. Moleza, né? Assim que a janela do editor de textos for fechada, o script vai retomar a execução dele e começar a construir um novo pacote .deb, só que usando o arquivo de controle que foi modificado por você. O novo pacote será criado dentro do mesmo local em que o script foi executado. O nome desse novo pacote terminará com .editado.deb, para que você consiga distinguir o pacote original e o que foi editado por você. Vamos supor que o novo pacote se chame google-chrome-stable_current_i386.editado.deb e que ele foi criado dentro de ~/Downloads. Neste caso, volte ao terminal e execute os seguintes comandos, para instalá-lo: cd ~/Downloads sudo dpkg -i google-chrome-stable_current_i386.editado.deb Pronto! O novo pacote .deb foi criado e instalado! Notas: i) No caso do Google Chrome, pode acontecer de ele não executar porque a sandbox dele não foi corretamente configurada. Se isso ocorrer com você, execute estes comandos, no terminal: sudo chown root /opt/google/chrome/chrome-sandbox sudo chmod 4755 /opt/google/chrome/chrome-sandboxApós executar esses dois comandos, tente novamente executar o Google Chrome, porque agora vai funcionar. ii) Se você usar este tutorial com outro pacote .deb e ocorrer algum problema com a execução do aplicativo instalado a partir de um pacote editado, experimente desinstalar o pacote com estes comandos: sudo dpkg -r nome_do_pacote sudo apt-get clean apt-get purge apt-get autoremoveEm seguida, delete o pacote editado (final .editado.deb) e substitua os comandos do item 7 por estes: cd ~/Downloads sudo ./edd ./nome_do_pacote.editado.debO uso do sudo fará o script ser executado com perfil de superusuário, o que pode (ou não...) resolver alguns problemas de reconstrução do pacote. Se o novo pacote continuar dando problema, pode ser que você tenha feito alguma edição indevida no arquivo de controle de dependências, ou ainda que o pacote não possa ser corrigido apenas com uma modificação nas dependências dele. Neste caso, o problema pode ser mais complexo e por isto não será possível sanar o problema somente com o script deste tutorial. Neste caso, que tal colocar o seu gorrinho geek, desvendar o mistério e criar o seu próprio tutorial? É isso. PS: o código-fonte do script deste tutorial foi obtido aqui e adaptado.

1. Defina de volta a JVM que você instalou via repositório do webupd8team para ser a JVM padrão do sistema: sudo update-alternatives --set java /usr/lib/jvm/java-7-oracle/jre/bin/java 2. Remova o grupo do plugin java (não remova o plugin java) que foi criado pela instalação do metapacote do webupd8team: sudo update-alternatives --remove-all libnpjp2.so 3. Faça com que o Chrome e o Firefox apontem para o plugin da versão 7 (1.7.0_21) mas o Chromium aponte para o plugin da versão 6 (1.6.0_31): No Google Chrome: sudo ln -sf /usr/lib/jvm/java-7-oracle/jre/lib/i386/libnpjp2.so /opt/google/chrome/plugins/sunjava No Mozilla Firefox: sudo ln -sf /usr/lib/jvm/java-7-oracle/jre/lib/i386/libnpjp2.so /usr/lib/firefox/plugins/sunjava No Google Chromium: sudo ln -sf /opt/java/jre/lib/i386/libnpjp2.so /usr/lib/chromium-browser/plugins/sunjava 4. Verifique a versão das suas JVM: O comando java -version deverá retornar isto: java version "1.7.0_21" Java SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot Client VM (build 23.21-b01, mixed mode) O comando /opt/java/jre/bin/java -version deverá retornar isto: java version "1.6.0_31" Java SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot Client VM (build 20.6-b01, mixed mode, sharing) 5. Acesse a página de testes da Sun a partir de cada um dos seus navegadores. No Chrome e no Firefox deverá aparecer que você tem o plugin 7 (1.7.0_21), mas no Chromium deverá aparecer que você tem o plugin 6 (1.6.0_31). Pronto! Considerações finais: Se ocorrer de na página de testes da Sun o Chromium mostrar o plugin 1.7.0_21, é porque o Chromium detectou os dois plugins (6 e 7) e está usando apenas o mais recente, que é o 7. Neste caso, ainda dentro da janela do Chromium, acesse chrome://plugins e clique naquele link +Detalhes (para expandir os detalhes de cada plugin), daí encontre os dois plugins Java e clique no link Desativar que está logo abaixo de /usr/lib/jvm/java-7-oracle/jre/lib/i386/libnpjp2.so. Isto desativará o plugin 7 (somente dentro do Chromium). Reinicie o Chromium e teste novamente o funcionamento do plugin, lá na página de testes da Sun. Se o Chromium mostrar o plugin 6, agora dá para usar os navegadores Chrome e Firefox com o plugin 7 e o Chromium com o plugin 6.

Obrigado pelos comentários! Eu me esforço para ser didático e é muito gratificante quando recebo esse tipo de feedback positivo. Quanto às mensagens de alerta, se você estiver acessando um website confiável (como é o caso dos websites dos bancos e do website da própria Sun), pode ficar tranquilo e confirmar/autorizar/desbloquear/permitir a execução do plugin Sun Java.