Olá pirozzimorales,
Como o zekkerj disse, com toda razão, pode haver aí uma conjugação de kernel e acpi BIOS e que a melhor solução seja mesmo manter um kernel adequado, como mesmo já estava mencionado no item 6 do post #2.
Quando se faz uma atualização a manutenção da entrada de kernel anteriores é exatamente com essa finalidade, o que é uma grande e virtuosa característica do Linux, facultando essa possibilidade, inexistente no sistema operacional comercial, realçando a enorme flexibilidade da plataforma Linux, já que não é incomum ocorrem dificuldades na mudanças de kernel.
Existe um antigo adágio em informática que diz que atualização é trocar o bug velho pelo bug novo, o que não deixa de ser uma grande verdade, :-)
Isso é apenas inerente ao estado da arte em programação, em sistemas cada vez mais e mais complexos, em que as linhas de códigos são contadas já em vários e vários milhões, havendo notícia que já no Linux kernel versão 2.6.27, medido pelo git (um sistema de controle de atualizações), observava-se que ultrapassava 10.000.000 de linhas do código, e isso é apenas o kernel, sem contar bootloader, ambiente, etc, que aí vai para mais uns tantos milhões.
É necessário entender que essas pequenas e sucessivas modificações de kernel, com a inclusão dos novos patches, na verdade não introduzem novas características de aproveitamento do equipamento, apenas corrigem problemas constatados, os tais pequenos bugs, daí porque não faz sentido trocar um kernel que está funcionando por um outro se este vier a dar alguma espécie de problema.
Diferente, por exemplo, quando uma modificação de kernel é feita de forma substancial, para tornar funcional uma evolução do hardware. Exemplo clássico, quando se passou dos núcleos únicos de processadores Intel para núcleos múltiplos, aí sim, evidentemente, é necessário um novo kernel para quem tem um novo hardware, sem o que esse não trabalha, não é aproveitado, caso contrário, apenas não há a necessidade.
Bem, voltando a questão, seguindo a sempre excelente sugestão do zekkerj, podemos fazer algumas experiências alterando a command line do Grub, entretanto, antes, como já viemos até aqui, não custa tentar seguir a sugestão de script do desenvolvedor do Gshutdown e ver o que acontece.
Relendo o tópico, noto que lá no começo v. disse "pensando que fosse um problema do ambiente gráfico eu efetuei a remoção do mesmo (apg-get remove gdm)" e ainda "[...] no gdm-session-worker, por isso testei desinstalando o pacote", pois bem, a experiência teria maior validade com o sistema o mais original possível, uma vez que sucessivas alterações podem levar a equívocos de interpretação, assim, idealmente o seu sistema deveria estar como instalado sem modificações e atualizado para que tivesse maior expressão a experiência. No mínimo, reinstale o que v. tenha desinstalado de substancial no sistema.
Isso posto, vamos ao teste do script propriamente dito.
1) faça uma cópia do arquivo rc.local para efeitos de poder retornar com facilidade ao estado anterior, no caso de alguma dificuldade.
sudo cp /etc/rc.local /etc/rc.local.bak
portanto, rc.local.bak é sua cópia de segurança, qualquer coisa é só deletar o arquivo alterado e renomear rc.local.bak para rc.local que volta como estava antes.
2) abra o arquivo /etc/rc.local
sudo gedit /etc/rc.local
3) acrescente as linhas do script, tal e qual o autor o criou (copie e cole as 4 linhas lá existentes), notando que dentro do arquivo rc.local devem ficar antes da linha "exit 0", pois que essa linha é que obrigatoriamente deve encerrar o arquivo rc.local.
Nota: Ao fazer a colagem, posicione o mouse imediatamente após o último caracter do script e de um [Enter], é como se fosse acrescentar uma linha em branco em um documento texto qualquer, pois que isso registra um caracter não visível de final de carro [difícil explicar isso, já que essa expressão "final de carro" vem do tempo da datilografia, coisa tão antiga que muitos jovens aqui, nascidos na era dos computadores, certamente nem sabem o que é datilografia :-( ], o que no mais das vezes não é necessário, porém nunca se sabe (exemplo ao contrário, o fstab dava erro quando se fazia isso na última linha, ou seja, um bug, nem sei se isso lá já foi corrigido).
4) Certifique-se que o arquivo rc.local está setado com permissão para execução (por padrão é, mas por cautela não custa verificar).
Basta entrar, mesmo graficamente, de forma simples usuário, na Pasta Pessoal, Sistema de arquivos, etc, localizar o arquivo rc.local, clicar no botão direito do mouse, Propriedades, aba Permissões e verificar se está marcado "Permitir execução do arquivo como um programa".
Na remota possibilidade de que não esteja, entre pelo Terminal (Ctrl+Alt+T) e digite:
sudo chmod +x /etc/rc.local
Daí é salvar, sair e reiniciar o computador.
Reiniciado, tente novamente fazer o "Reiniciar", primeiramente usando a função normal do sistema (botão à direita do painel superior) e depois, caso ainda não funcione, adicionalmente, repetindo o procedimento de shutdown -r now do GShutdown, da forma como já vimos, e vamos ver o que acontece.
Não cheguei a tentar descer em detalhes na interpretação de cada valor desse script e o autor, como se vê no link de origem postado, é econômico na documentação, o que não facilita a vida, apenas dizendo que:
These two lines are important :
cookie=”$(xauth -i nextract - :0 | cut -d ' ' -f 9)”
xauth -i add :1 . “$cookie”
Vamos em frente, faz isso aí e vamos ver o que dá.
[]'s
Tópico: [Resolvido] Travamento versão 11.04 ao desligar ou reniciar (Lida 21270 vezes)