[Resolvido] Travamento versão 11.04 ao desligar ou reniciar

pirozzimorales · 18 de Maio de 2011, 10:54

Bom dia pessoal!
Eu instalei o Ubuntu 11.04 no meu computador, porém estou tendo um problema ao desligar ou reinciar o sistema ele simplesmente trava na tela com o logo do Ubuntu, trava mesmo, é necessário desligar diretamente no botão!
Gostaria de saber se mais alguem já teve esse problema?
Obrigado,
Diego

pirozzimorales · 26 de Maio de 2011, 14:37

Pessoal, gostaria de adicionar mais algumas informações!
Pensando que fosse um problema do ambiente gráfico eu efetuei a remoção do mesmo (apg-get remove gdm) e então loguei no modo texto, com o modo gráfico removido, e pedi para reiniciar o sistema (shutdown -r now) e mesmo assim o sistema travou, ou seja, não é um problema do modo gráfico.
Outra coisa que gostaria de acrescentar é que já dei uma olhada nos logs e não encontrei nenhum problema (apenas uma falha no gdm-session-worker, por isso testei desinstalando o pacote). Também já fiz os updates (apt-get update e apt-get upgrade).
Bom, mesmo depois de tudo isso e de muita pesquisa na intenet ainda estou com o mesmo problema, já estou desanimando com essa distribuição.... estou pensando em instalar outra para teste,
Obrigado,
Diego

druidaobelix · 26 de Maio de 2011, 16:19

Um travamento ao desligar ou reiniciar, sem que haja alguma mensagem de erro, é algo muito inespecífico, o caminho que v. escolheu está certo, tentando isolar e identificar o problema, ou seja, permitir em algum momento isolar as variáveis que possam estar interferindo na ocorrência.

Creio, entretanto, exatamente pela generalidade do sintoma, há necessidade de ampliar a informação disponível.

1) Informações adicionais sobre o seu hardware, em uma breve descrição, podem ser úteis.

2) Adicione o resultados dos comandos:

sudo dmidecode -t System

sudo lspci | grep VGA

3) Convém, ainda, que analise as saídas do desligamento, procurando por identificação de erros.
Um desligamento normal ocorreria mediante o sinal 15. Tente identificar essa sequência no log correspondente.

Podem ser úteis:

cat /var/log/syslog.1 | grep "error"

ou

cat /var/log/syslog.1 | grep "fail"

e ainda:

cat /var/log/syslog.1 | grep "signal 15"

4) Ocorre travamento tanto mandando desligar quanto mandando reiniciar?
Estando em tty, teste:

sudo shutdown -h now

sudo shutdown -r now

5) É interessante se saber o que ocorre quando se faz o carregamento e desligamento exclusivamente a partir do LiveCD/USB da versão 11.04.
Nesse caso desliga e/ou reinicia normalmente, sem travar?

6) Uma possibilidade adicional é instalar a versão 10 (aproveite para testar o desligamento dela) e atualizar a partir dela para a versão 11 de tal forma que tenha mais de um kernel disponível para testar, ou seja, kernel anterior, além do próprio modo de recuperação.

A remoção que v. fez eventualmente não é suficiente, pois que entradas do subsistema de vídeo podem estar nos arquivos de configuração, sendo adequado purgar e remover essas entradas, cujos comandos específicos dependem de sua específica placa de vídeo.

Analisar é decompor logicamente o todo em partes, de tal forma que se possa individuar certo aspecto que se queira observar, para o que é essencial a informação metódica.

[]'s

pirozzimorales · 30 de Maio de 2011, 11:03

Obrigado druidaobelix, abaixo vou descrever as resposttas e ver se assim você pode identificar melhor os problemas:

1) Informações adicionais sobre o seu hardware, em uma breve descrição, podem ser úteis.
Meu PC é um Intel pentium dual core - E2160 - 1.80GHZ
2GB de memória RAM, Placa de vídeo Intel G33/G31 e placa de rede Broadcom NetXtreme 57xx Gigabit Controller.

2) Adicione o resultados dos comandos:

sudo dmidecode -t System

diego@H205183:~$ sudo dmidecode -t System
# dmidecode 2.9
SMBIOS 2.5 present.

Handle 0x0100, DMI type 1, 27 bytes
System Information
   Manufacturer: Dell Inc.
   Product Name: OptiPlex 330
   Version: Not Specified
   Serial Number: 1YWM4G1
   UUID: 44454C4C-5900-1057-804D-B1C04F344731
   Wake-up Type: Power Switch
   SKU Number: Not Specified
   Family: Not Specified

Handle 0x0F00, DMI type 15, 29 bytes
System Event Log
   Area Length: 2049 bytes
   Header Start Offset: 0x0000
   Header Length: 16 bytes
   Data Start Offset: 0x0010
   Access Method: Memory-mapped physical 32-bit address
   Access Address: 0xFFF01000
   Status: Valid, Not Full
   Change Token: 0x0000000D
   Header Format: Type 1
   Supported Log Type Descriptors: 3
   Descriptor 1: POST error
   Data Format 1: POST results bitmap
   Descriptor 2: System limit exceeded
   Data Format 2: System management
   Descriptor 3: Log area reset/cleared
   Data Format 3: None

Handle 0x2000, DMI type 32, 11 bytes
System Boot Information
   Status: No errors detected

sudo lspci | grep VGA

diego@H205183:~$ sudo lspci |grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)

3) Convém, ainda, que analise as saídas do desligamento, procurando por identificação de erros.
Um desligamento normal ocorreria mediante o sinal 15. Tente identificar essa sequência no log correspondente.

Podem ser úteis:

cat /var/log/syslog.1 | grep "error"

diego@H205183:~$ cat /var/log/syslog |grep "error"
May 26 14:18:48 H205183 kernel: [ 14.826306] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 26 14:18:48 H205183 NetworkManager[622]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 26 14:18:50 H205183 kernel: [ 17.433498] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 26 14:18:52 H205183 kernel: [ 19.016454] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 26 14:24:21 H205183 kernel: [ 5.821084] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 26 14:24:30 H205183 NetworkManager[749]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 26 14:24:34 H205183 kernel: [ 22.215921] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 26 14:27:45 H205183 kernel: [ 10.100127] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 26 14:27:45 H205183 NetworkManager[504]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 26 14:27:47 H205183 kernel: [ 12.217909] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 26 14:30:57 H205183 kernel: [ 8.064471] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 26 14:31:02 H205183 NetworkManager[753]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 26 14:31:07 H205183 kernel: [ 22.207478] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 26 14:31:11 H205183 kernel: [ 26.215497] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 30 10:42:45 H205183 kernel: [ 15.926957] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 30 10:42:45 H205183 NetworkManager[576]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 30 10:42:49 H205183 kernel: [ 19.965901] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 30 10:49:23 H205183 kernel: [ 16.212830] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 30 10:49:23 H205183 NetworkManager[617]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 30 10:49:26 H205183 kernel: [ 20.136699] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 30 10:50:52 H205183 kernel: [ 16.312086] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
May 30 10:50:53 H205183 NetworkManager[570]: <warn> bluez error getting default adapter: The name org.bluez was not provided by any .service files
May 30 10:50:54 H205183 kernel: [ 18.845703] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
May 30 10:50:56 H205183 kernel: [ 20.665964] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0

ou

cat /var/log/syslog.1 | grep "fail"

diego@H205183:~$ cat /var/log/syslog |grep "fail"
May 26 14:18:49 H205183 kernel: [ 15.937213] [drm] MTRR allocation failed. Graphics performance may suffer.
May 26 14:18:53 H205183 gdm-session-worker[1083]: GLib-GObject-CRITICAL: g_value_get_boolean: assertion `G_VALUE_HOLDS_BOOLEAN (value)' failed
May 26 14:24:22 H205183 kernel: [ 10.233949] [drm] MTRR allocation failed. Graphics performance may suffer.
May 26 14:27:46 H205183 kernel: [ 10.895989] [drm] MTRR allocation failed. Graphics performance may suffer.
May 26 14:30:57 H205183 kernel: [ 10.935679] [drm] MTRR allocation failed. Graphics performance may suffer.
May 26 14:31:14 H205183 gdm-session-worker[1046]: GLib-GObject-CRITICAL: g_value_get_boolean: assertion `G_VALUE_HOLDS_BOOLEAN (value)' failed
May 30 10:42:45 H205183 kernel: [ 16.477534] [drm] MTRR allocation failed. Graphics performance may suffer.
May 30 10:42:50 H205183 gdm-session-worker[1016]: GLib-GObject-CRITICAL: g_value_get_boolean: assertion `G_VALUE_HOLDS_BOOLEAN (value)' failed
May 30 10:49:23 H205183 kernel: [ 16.688090] [drm] MTRR allocation failed. Graphics performance may suffer.
May 30 10:49:32 H205183 gdm-session-worker[1004]: GLib-GObject-CRITICAL: g_value_get_boolean: assertion `G_VALUE_HOLDS_BOOLEAN (value)' failed
May 30 10:50:53 H205183 kernel: [ 16.989029] [drm] MTRR allocation failed. Graphics performance may suffer.
May 30 10:50:58 H205183 gdm-session-worker[1082]: GLib-GObject-CRITICAL: g_value_get_boolean: assertion `G_VALUE_HOLDS_BOOLEAN (value)' failed

e ainda:

cat /var/log/syslog.1 | grep "signal 15"

diego@H205183:~$ cat /var/log/syslog |grep "signal 15"
May 26 14:23:17 H205183 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="591" x-info="http://www.rsyslog.com"] exiting on signal 15.
May 26 14:26:29 H205183 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="602" x-info="http://www.rsyslog.com"] exiting on signal 15.
May 26 14:30:08 H205183 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="463" x-info="http://www.rsyslog.com"] exiting on signal 15.
May 26 14:39:12 H205183 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="516" x-info="http://www.rsyslog.com"] exiting on signal 15.
May 30 10:48:43 H205183 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="525" x-info="http://www.rsyslog.com"] exiting on signal 15.
May 30 10:50:00 H205183 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="604" x-info="http://www.rsyslog.com"] exiting on signal 15.

4) Ocorre travamento tanto mandando desligar quanto mandando reiniciar?
Estando em tty, teste:

sudo shutdown -h now

Utilizando o shutdown -h now ou o halt -h now o PC é desligado sem problemas.

sudo shutdown -r now

Utilizando o shutdown -r now o PC trava na tela do logo do Ubuntu.

5) É interessante se saber o que ocorre quando se faz o carregamento e desligamento exclusivamente a partir do LiveCD/USB da versão 11.04.
Nesse caso desliga e/ou reinicia normalmente, sem travar?

Quando fiz o teste com o pendrive bootavel antes da instalação não tive nenhum problema (somente com configuração de teclado).

6) Uma possibilidade adicional é instalar a versão 10 (aproveite para testar o desligamento dela) e atualizar a partir dela para a versão 11 de tal forma que tenha mais de um kernel disponível para testar, ou seja, kernel anterior, além do próprio modo de recuperação.

Pensei nessa alternativa, mas gostaria de esgotar todoas as outras alternativas antes.

Bom, epero que essas informações sejam uteis para que surjam alternativas novas, Agradeço muito pela atenção.

druidaobelix · 30 de Maio de 2011, 19:57

Olá pirozzimorales,

Considerando as informações passadas, creio que compensa fazer uma experiência com um outro software de reiniciar/desligar e ver o que acontece, pelo menos isso iria fazendo um funil na identificação do problema.

Acho que poderia instalar, por exemplo, o GShutdown, usar e avaliar o resultado.

Também não sei se funcionará bem no Unity (se é que v. o está usando), só testando mesmo.

sudo apt-get install gshutdown

Editando (1):

É o vício :-(
Instale pela Central de Programas do Ubuntu

Editando (2)

Faltou ver isso, se usar:

sudo reboot

reinicia o computador?

[]'s

druidaobelix · 30 de Maio de 2011, 22:38

Olá pirozzimorales,

Agora, com um pouco mais de tempo, vamos elaborar um pouco melhor o raciocínio.

A idéia com o GShutdown é ver se ele consegue superar o problema de não estar realizando o shutdown, isto é, usando um outro 'disparador' que não o padrão do sistema.

Caso o resultado seja positivo a análise ficaria mais circunscrita aos softwares envolvidos nesse processo.

O uso efetivo do GShutdown, ao menos como eu estava imaginando, passa por utilizá-lo não apenas na configuração padrão, mas também, e principalmente, usando a opção de "Comando personalizado", existente no menu "Editar/Preferências", usando a entrada "Reiniciar o computador" lá existente, variando os comandos entre o "shutdown -r now" e o "reboot".

Apenas que para poder fazer isso é necessário, antes, alterar as permissões do sudo, pois que esses comandos de reinicialização exigem o sudo, ou seja, os privilégios de root.

As variáveis a serem acrescentadas na configuração do sudo são essas:

User_Alias SHUTDOWNERS = user1, user2
SHUTDOWNERS ALL = NOPASSWD: /sbin/shutdown

As configurações do sudo estão no arquivo /etc/sudoers, porém esse arquivo não pode ser editado diretamente, requerendo que se use o visudo.

Caso não tenha familiaridade com isso, existe um bom texto ensinando a fazer:

http://www.vivaolinux.com.br/artigo/Comando-sudo-instalacao-e-configuracao

Se houver facilidade com o idioma inglês, há aqui um bom resumo:

http://ubuntuforums.org/showthread.php?t=1132821

Entretanto, indo além, tratando do próprio GShutdown, o mantenedor desse software, que afinal é especializado nisso,dá um alerta que parece ser útil (em tradução livre):

"Problemas de comunicação com GDM podem aparecer: é o mesmo problema o qual faz desaparecer o botão de shutdown e reboot do menu do gnome."

Aí ele sugere um script que, parece, pretende contornar a questão, nos seguintes termos:

"Aqui meu script para iniciar minha seção com Xgl:"

Xgl -fullscreen :1 -ac -accel glx:pbuffer -accel xv:fbo & sleep 2
cookie="$(xauth -i nextract - :0 | cut -d ' ' -f 9)"
xauth -i add :1 . "$cookie"
DISPLAY=:1 exec dbus-launch –exit-with-session gnome-session

fonte: http://gshutdown.tuxfamily.org/en/wiki/doku.php?id=faq

Vamos ver se o pessoal aí nos ajuda nisso, analisando essas informações e, se o caso, sugerindo formas de implementá-las.

[]'s

druidaobelix · 31 de Maio de 2011, 00:34

Olá pirozzimorales, de novo

Um adendo ao último post:

Havia dito no post anterior, acerca do uso do shutdown no GShutdown, da necessidade de usar o visudo e acrescentar as variáveis que lá menciono, pois que o comando shutdown requer o uso do sudo (privilégios de root).

Pois bem, pesquisando um pouco mais descobri um modo muito interessante de fazer isso sem ter que mexer no visudo e nas variáveis. Muito criativa a forma que o autor encontrou para contornar esse procedimento, apenas alterando as características externas do shutdown, ou seja, permite usar o shutdown sem precisar do sudo e aí o GShutdown funciona tranquilo. :-)

Como na verdade o que se pretende, por enquanto, são somente testes, então acho que dá para usar esse outro método sem prejuízo algum, já que facilmente reversível.

A forma é essa:

1) Faça uma cópia de segurança do shutdown (para adiante retornar se necessário):

sudo cp /sbin/shutdown /sbin/shutdown.bak

2) setando SUID no arquivo:

sudo chmod 4755 /sbin/shutdown

3) criando um link simbólico para o usuário ter acesso:

sudo ln -s /sbin/shutdown /bin/shutdown

A partir disso o comando shutdown passa a funcionar sem precisar do sudo e pode ser usado lá no GShutdown na forma que mencionei.

Baixei aqui o GShutdown para poder testar, fiz os procedimentos acima e funcionou perfeitamente.

Então a idéia é implementar esse uso do GShutdown e ver o que acontece.
O restante do que havia dito, principalmente do script, continua como tal.

[]'s

pirozzimorales · 02 de Junho de 2011, 07:59

Olá druidaobelix, obrigado pelo retorno!
Quanto ao sudo reboot o travamento também ocorre. Instalei o GShutdown, fiz a cópia de segurança do shutdown, o chmod, o link simbólico, porém não entendi a forma de configuração para utilizar o GShutdwon, não achei aqui um "Editar/Preferências", me desculpe a ignorancia, mas como vou configurar para utilizar o GShutdown para reiniciar e desligar?
Obrigado,
Diego

druidaobelix · 02 de Junho de 2011, 15:53

Olá pirozzimorales,

Vamos lá

Uso do Gshutdown

1. Tela inicial quando se inicia o aplicativo
Observe que na parte superior esta "À data e hora" e na parte inferior o botão "Delisgar o computador", esses são os campos iniciais a serem alterados.
Modifique o primeiro para "Agora" e o segundo para "Reiniciar o computador";

2. Com o aplicativo ativo, observe a barra do superior do Desktop do Unity, do lado esquerdo, posicionando o ponteiro do mouse sobre ela, aparecem as entradas de menu para Ficheiro Editar Ajuda.
Esse é um princípio geral de funcionamento do Unity, a forma padrão dele trabalhar, isto é, sempre que um aplicativo qualquer está ativo abre-se na barra superior, do lado esquerdo, os menus correspondentes ao aplicativo que está ativo;

3. Clicando sobre a entrada Editar abre-se o submenu "Preferências", clique nele;

4. Abre-se o quadro "Preferences", aparecendo desde logo assinalada a opção "Auto detectar do método (recomendado), pois bem, faça um teste inicial dessa forma, é só fechar, portanto ficará ativa somente a tela inicial (na qual já estava assinalada "Agora" e "Reiniciar o computador". Verifique o resultado dessa opção;

5. Repita o processo, apenas que escolha agora a opção "Comando Personalizado" e nessa mesma tela click sobre o botão "Reiniciar o computador";

6. Vai abrir um novo quadro "Configure the action", preencha o campo com shutdown -r now; Reinicie o computador e analise o resultado;

7. Repita o processo, apenas que agora no quadro "Configure the action" preencha com reboot. Reinicie o computador e analise o resultado;

Para reiniciar o computador v. sempre voltará à tela inicial e aciona o botão "Começar";

Essencialmente é esse o funcionamento do GShutdown.

Obviamente o GShutdown pode ser usado de forma mais completa em uso normal para programar um desligamento, mas não é esse o nosso objetivo imediato e sim, apenas, usá-lo como uma interface gráfica para disparar os comandos.

Dependendo do resultado desses testes, caso não resultem satisfatórios, experimente aplicar o script sugerido pelo desenvolvedor do GShutdown.

[]'s

pirozzimorales · 03 de Junho de 2011, 08:43

Olá druidaobelix!
Valew, fiz os testes e tive os seguintes resultados:

4. Abre-se o quadro "Preferences", aparecendo desde logo assinalada a opção "Auto detectar do método (recomendado), pois bem, faça um teste inicial dessa forma, é só fechar, portanto ficará ativa somente a tela inicial (na qual já estava assinalada "Agora" e "Reiniciar o computador". Verifique o resultado dessa opção;

Neste teste ele somente encerrou a sessão do meu usuário (não reiniciou o pc).

5. Repita o processo, apenas que escolha agora a opção "Comando Personalizado" e nessa mesma tela click sobre o botão "Reiniciar o computador";

6. Vai abrir um novo quadro "Configure the action", preencha o campo com shutdown -r now; Reinicie o computador e analise o resultado;

Neste teste ocorreu o travamento.

7. Repita o processo, apenas que agora no quadro "Configure the action" preencha com reboot. Reinicie o computador e analise o resultado;

Neste teste não aconteceu nada, nem reiniciou nem desligou e nem encerrou a sessão.

Quanto ao script para carregar na inicialização onde eu devo colocá-lo? tentei no grub mas ele da um erro que não encontra o Xgl:
Xgl: comando não encontrado

Obrigado.

zekkerj · 03 de Junho de 2011, 10:39

Olá pirozzimorales e druidaobelix, tudo bem? Tenho acompanhado este tópico de longe --- só na lista de tópicos da sala, admito ---, hoje tomei coragem de entrar pra ver.

Esse tipo de travamento costuma ser relacionado ao sistema de ACPI, vocês chegaram a verificar alguma coisa sobre isso?

Outra coisa que lembrei enquanto lia, meu irmão também usa Ubuntu (acho que é de família

), mas a máquina dele, de uns tempos pra cá, deixou de desligar --- apenas reiniciava. Ele chegou a abrir tópico aqui, mas a única solução que conseguimos foi voltar a uma versão anterior do kernel onde o problema não acontecia. Ele usa o Ubuntu Lucid, o kernel que não dá o problema é o 2.6.32-30.

Bem, talvez o caso aqui também esteja relacionado ao kernel. O que eu ia perguntar é se já foi testado outro kernel nessa máquina, e principalmente, se as atualizações dela estão em dia.

leogomesmg · 03 de Junho de 2011, 11:52

Ótimo tópico. Um amigo passa por este mesmo problema.

pirozzimorales · 03 de Junho de 2011, 14:12

Olá zekkerj, então, não cheguei a testar nada relacionado ao sistema de ACPI, e quanto a outro kernek eu já usei aqui outra versão do ubuntu 09.04 e não tive nenhum problema, outra informação que eu não citei até agora é que nesta máquina estou usando dualboot (windows 7 e ubuntu 11.04) não é minha máquina pessoal, é minha máquina de trabalho.
Valew aí pela colaboração!

druidaobelix · 03 de Junho de 2011, 22:59

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

pirozzimorales · 07 de Junho de 2011, 07:30

Olá druidaobelix, acredito que a solução realmente vai ser voltar pra uma versão anterior, pois mesmo com o script não foi possível reiniciar a máquina, quanto ao sistema está sim atualizado e também não fiz nenhuma grande modificação. Também fiz alguns testes desabilitando e habilitando algumas opções de energia da bios do pc, porém também sem sucesso!
Agradeço sua atenção e se você ou alguem tiver mais alguma idéia vou estar acompanhando este tópico antes de voltar para a versão anterior!
Obrigado.