Como o Google Earth pode induzir a reinstalação de uma distro Linux

O problema principal é a falta de espaço no HD, que pode bloquear login de usuário comum. O presente artigo descreve o problema em detalhes.

[ Hits: 16.903 ]

Por: j g meinhardt em 21/02/2010


Afinal o que e porque aconteceu?



Precisava atualizar o mapeamento que mantenho de todas as operações de mineração no Brasil e em alguns outros países, incluindo as localizações das respectivas minas no Google Earth.

Por costume, a cada atualização ou uso do Google Earth onde tenha sido incluído/marcado um novo lugar, salvo cópias nos dois tipos ou formatos de arquivo disponíveis para guardar os meus pontos de referencia ("Meus Lugares"), em formato kml e kmz, para o caso de que um deles falhe. Creio que esta preocupação demonstra a importância das cópias.

Para fazer isto, precisei instalar o Google Earth no meu NoBo, nesta distro.

Não havia instalado antes, apenas porque versões anteriores do Google Earth não estavam tendo um desempenho decente nas distros que testei ou vinha usando. Por esta razão deixei o Google Earth para Linux amadurecer um pouco mais, antes de fazer nova tentativa.

Como fiz a instalação simplificada do Google Earth (o velho caminho mais fácil):

Baixei o arquivo binário para Linux, converti o mesmo em executável alterando as suas propriedades, não pelo terminal que é a maneira ortodoxa de fazer isto, mas direto usando a via "expressa" clicando com o botão direito do mouse sobre o arquivo baixado, escolhendo propriedades e depois abrindo a orelha "Permissões", clicando em "É executável".

Pronto, o aplicativo de instalação estava preparado para a instalação, sem nem mesmo precisar usar o terminal para alterar as propriedades do mesmo com o chmod.

Agora com o arquivo binário (.bin) do aplicativo baixado e convertido em executável, bastou clicar sobre ele para iniciar a instalação.

Poderia ter novamente usado o terminal para comandar a execução do instalador do Google Earth (./googleearth_versão_numero.bin), porém optei novamente pelo caminho mais fácil, usando o mouse.

Como de costume, fiz isto tudo de dentro de uma pasta temporária recém criada para evitar congestionamento em outros diretórios ou na área de trabalho.

Bastou clicar sobre o arquivo binário e o Google Earth foi instalado e com o respectivo ícone criado no desktop, no velho estilo NNF (Next, Next, Finish) dos Windows. Isto para usuário comum como eu é ótimo além de muito mais prático.

Para os ortodoxos o que descrevo com certeza é uma heresia, porém para usuário comum que não conhece o "caminho das pedras" ainda, talvez seja uma grande novidade totalmente contrária ao velho tabu de que Linux é muito complicado e coisa só para fanáticos, nerds, geeks e outros estereótipos no mesmo estilo.

Testei a nova versão do Google Earth, que até não me pareceu tão impressionante como as anteriores, porém agora pelo menos estava funcionando em velocidade normal e não aos trancos apesar dos 2GB de RAM disponíveis neste NoBo. Parece que nesta ultima versão disponibilizaram algum outro aplicativo para resolver os problemas de vídeo.

Chamei a última cópia atualizada dos meus mapas ("Meus Lugares") com todas as centenas de locais devidamente identificados e botei para rodar em modo "Passeio".

Visava com isto, alimentar o cache do Google Earth para poder acessar o seu conteúdo mesmo em modo offline a partir das informações salvas no meu HD.

A única alteração de configuração fora do padrão do Google Earth que fiz foi aumentar o tempo de pausa padrão no modo "Passeio" sobre os Meus Lugares de 3 segundos para 7 segundos. Com isto consigo baixar todas as imagens de cada um dos pontos marcados, com bom nível de detalhamento de imagem além de ficar armazenado no cache, portanto acessível mesmo sem conectar a Internet.

Tanto a instalação como o funcionamento do Google Earth estava rodando perfeitamente.

Descrição do problema:

Tudo ia bem, o Google Earth efetuando o seu "Passeio" e alimentando o cache em uma área de trabalho, enquanto em outra área de trabalho me dedicava a respostas de mensagens por email e trabalhava numa planilha preparando uma cotação, até que de repente tudo congelou.

Já fazia bastante tempo que não me ocorria algo assim, principalmente com uma distro da mais alta reputação e principalmente reconhecidamente estável.

Não tinha saída por lado nenhum.

Mouse travado, teclado travado, nem mesmo os comandos CTRL+ALT+ESC, CTRL+ALT+DEL, CTRL+ALT+BACKSPACE ou CTRL+ALT+F1... Fn respondiam mais.

Por via das dúvidas, deixei o NoBo parado por pelo menos meia hora antes de tentar tudo de novo.

Não consegui nada, então tive que partir para a ignorância e usar o botão Liga/Desliga por mais de 8 segundos desligando na maneira radical que já sabia, poderia provocar problemas no sistema de arquivos e na reinicialização.

Tentei reiniciar a distro, chegando até a tela de login, portanto o servidor X (X server) estava funcionando.

Depois de digitar a senha, a distro tentava seguir adiante porém voltava ao mesmo ponto como se a senha ou nome de usuário estivesse errada. Fazia apenas um loop.

Não aparecia nenhuma mensagem de erro nem de nome de usuário nem de senha errada. Tentei várias vezes e nada, imaginando haver ocorrido algum erro de digitação.

Tentei logar em modo gráfico como root para ver se conseguiria resolver o problema com mais poderes.

A distro não permitia o login como root em modo gráfico.

Tentei trocar o gerenciador de janelas com os outros disponíveis na tela de login em tipo de sessão:
  • KDE
  • TWM
  • Twm
  • Failsafe (modo de segurança)
  • Nenhuma funcionou, nem mesmo o modo de segurança.

Tentei então na opção menu:
  • Switch User (apareceu como não usada - portanto não funcionou)
  • Restart X Server (obviamente apenas voltava para a tela de login)
  • Remote Login (nem tentei pois não era isto que buscava)
  • Console Login (login pelo console - foi a única alternativa que funcionou)

Só conseguia bootar via console. Nenhuma das outras alternativas disponíveis com interfaces mais leves ou em modo de segurança aceitava ir adiante.

Com os conhecimentos de apenas usuário comum, limitados em termos de uso de terminal ou console, sem partir para os livros para pesquisar como fazer alguma alteração para resolver o problema, usei apenas alguns comandos mais simples que lembrava como "ls", "pwd", "cd" para entrar no diretório desktop e "ls -a" para verificar se o conteúdo ainda estava lá. Tentei ainda iniciar a interface gráfica com o startx, que também não funcionou.

Sabendo que por ali não daria para avançar muito, decidi bootar por outra distro, pesquisar soluções e fazer de fora aquilo que fosse necessário com acesso a ajuda tanto do sistema como consultando os fóruns via Internet.

Primeiro tentei uma sugestão para reparar a configuração do servidor X sugerida em várias fontes de consulta,:

# dpkg--reconfigure xserver xorg

O comando não foi aceito no console da distro travada e portanto não resolveu o problema, mesmo estando logado como root (#).

Posteriormente pesquisei a possibilidade de fazer o login como root de forma a tentar entrar na distro danificada em modo gráfico para experimentar alternativas para resolver o problema ou tentar fazer um backup dos dados mais recentes posteriores ao último backup.

Encontrei material no seguinte artigo aqui do VOL:
Segui o conteúdo da dica, porém não consegui reeditar o arquivo de configuração do KDM (kdmrc) sugerido usando o vim. Pelo menos pude anotar qual o arquivo a editar e parâmetro de configuração a alterar para habilitar o login gráfico como root.

Arquivo a alterar:
Buscando a linha em que está escrito "AllowRootLogin=false" e alterando-a para:

AllowRootLogin=true

Isto vai permitir que o root possa se logar no kdm.

Como não consegui fazer a alteração usando o editor vim a partir do console conforme sugerido no artigo citado, voltei para a outra distro e fiz as alterações usando o kedit em modo root.

Feito isto voltei a reinicializar a distro danificada e finalmente loguei como root, funcionando tudo perfeitamente em modo gráfico.

O servidor X portanto não estava nem danificado nem tampouco desconfigurado.

Restava a hipótese de que houvesse problema com a senha de usuário comum. Para tentar resolver estas duas hipóteses, logado como root, reeditei a senha do usuário e além disto criei um novo usuário.

Voltei a tentar logar como aquele usuário que estava travado e nada. Tentei com o usuário recém criado e também nada.

A descoberta acidental da causa do problema e a solução:

Voltei a logar como root, fui examinando o sistema para me preparar para a reinstalação completa da distro, separando ou anotando os diretórios que deveria salvar para não perder as informações e dados recentes.

Neste ponto, notei que a partição /home estava totalmente lotada (o espaço livre era literalmente zero).

Aproveitei para apagar o arquivo original de instalação do Google Earth que já estava instalado, não sendo mais necessário e com isto ganharia alguns MBs de espaço livre no /home (mais ou menos 25Mb). Apaguei outros arquivos desnecessários que encontrei em diretórios temporários, com todo o cuidado para não apagar nada mais que pudesse comprometer a instalação da distro.

Na partição raiz (/) não fiz nenhuma alteração pois ainda tinha bastante espaço disponível (1,9GB).

Desconfiei que aí poderia estar o problema então resolvi tentar fazer novamente o login como usuário comum e não mais como root, antes de partir para a recuperação do sistema a partir do backup.

Finalmente funcionou, sem que precisasse usar o backup para recuperar a distro.

Com isto aprendi que com zero bytes livres na partição de dados /home quando em partição separada do sistema (/) embora haja amplo espaço no raiz, a distro não permite fazer o login.

Acredito que deva ocorrer o mesmo, se você tiver a distro instalada totalmente em uma única partição incluindo o diretório /home e fique totalmente sem espaço no HD.

Para tentar descobrir o culpado pelo problema, sabendo que o último aplicativo instalado, coincidentemente apenas horas antes da travada geral foi o Google Earth fui examinar os diretórios onde estava instalado.

Aí notei o imenso tamanho do cache (mais de 500Mb), que obviamente havia lotado a partição /home. Isto que havia apenas cumprido a metade do passeio pelos "Meus Lugares".

Irritado com o achado, aproveitei e nem tentei desinstalar o Google Earth. Mandei tudo para o vinagre sem pestanejar.

A bem da verdade a culpa pela travada não foi absolutamente do Google Earth, porém da falta de espaço adicional disponível na partição /home para poder receber o grande volume de dados do cache. Em outras palavras o problema foi causado pelo que estava "atras" do teclado, o Mané aqui!! Não havia verificado o espaço total disponível e nas configurações do Google Earth ajustado o espaço máximo para o cache.

Depois da limpeza acima, a distro voltou a funcionar perfeitamente, tendo feito o login sem problemas agora já por vários dias.

Para confirmar a causa da travada geral e impossibilidade de login como tendo ocorrido por absoluta falta de espaço na respectiva partição, faltaria replicar a situação, o que pretendo fazer depois e em mais de uma distro instalada para confirmar.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Afinal o que e porque aconteceu?
   3. Moral da estória
Outros artigos deste autor

Librix 4.0 - Uma distro que não é para inglês ver - primeiras impressões

Usando Linux para operar plataformas de análise gráfica na Bovespa (B3)

Sugestões sobre distros Linux e particionamento de HD

Quando seria mais conveniente usar wvdial no terminal para conexões 3G ou EDGE?

Zorin OS - interessante distro lançada no ano novo - primeiras impressões

Leitura recomendada

O "Synaptic"

Um tour pelos players de vídeo para Linux

Bioinformática - Análise Filogenética com Clustalx

Mencoder ripando DVD para DIVX

Docker Linux Container - Open vSwitch Containers - Múltiplos Servidores

  
Comentários
[1] Comentário enviado por stack_of em 22/02/2010 - 12:03h

Travamentos do sistema ocorrem no Linux, com uma frequencia razoavel.
Acho que o principal culpado é mesmo o X-org, e perda de trabalho às vezes é inevitavel.

O X-org tem experimentado uma evolucao mas ainda esta bem longe de ser o ideal.

No seu caso espaço físico no HD foi a causa do problema, e graças ao seu espírito investigativo o determinante do problema foi encontrado, evitando a culpar inocentes (o SO ou o time do Google Earth).

Aconselho instalacao do /root, /home /boot em partições separadas, pois ajuda a prevenir problemas desse tipo. Mas bem que as distros deveriam implementar um sistema de quotas de disco ou de aviso de falta crítica de espaço por padrão.

O máximo de cuidado com backups em ambiente de produção é outro ponto que você enfatizou com propriedade; afinal falhas ocorrem em qualquer sistema operacional e algumas são imprevisíveis.

[2] Comentário enviado por eldermarco em 22/02/2010 - 13:28h

É verdade, isso acontece comigo também na Universidade, onde tem o Debian instalado. Se eu ultrapassar a minha quota de disco (120MB) o sistema já não me permite mais um login em modo gráfico e começa a mostrar uns erros e volta para a tela de login. Eu não cheguei a ver, mas acho que o arquivo ~/.xession-errors deve mostrar algo com respeito a isso, da interface gráfica não ter sido carregada.

De qualquer maneira, no meu caso ainda é possível logar em modo texto, apagar algumas coisas desnecessárias e fazer login em modo gráfico sem problemas depois.

Mas obrigado pelo alerta, vou tratar já de fazer o backup das minhas músicas aqui ou terei um treco se souber que perdi elas =)


[3] Comentário enviado por doradu em 22/02/2010 - 14:34h

tenho problemas com as fontes (no SliTaz), só isso


[4] Comentário enviado por irado em 23/02/2010 - 10:37h

o usuário stack_of (comentário nr. 1) ou é completamente equivocado ou maldoso mesmo. Ou nao usa Linux ;) hehehehhe...

apesar disso, fez duas assertivas corretissimas:

1 - partições distintas - pelo menos para /home (no caso de sistemas domésticos) ou /var e/ou /usr (sistemas corporativos).

2 - backups frequentes.

desde que me conheço por gente eu ouço recomendações para backup. Mas ninguém ouve/executa. Aqui eu faço 1x por semana, salvando tudo em DVDs (usando o k3b, eu gero um iso). DVDs hoje em dia (se comprados em lotes de 50 unidades) chegam a custar RS$.0,80 cada e salvam 4.7G de dados. Se compactados, êsses dados podem ser MUITOS. Pode-se (eu faço assim) tar.gz os dados a serem salvos e, se excecendo 4.7G fraciona-los em 2 DVDs. Pode-se também tirar-se um "espelho" único, mensal e depois incremental, 1x por semana (daí cabe em CDrom mesmo, normalmente) - enfim, IMMV.

nota: SEMPRE se tem 5% disponiveis para o usuário root. É do sistema, para permitir sua recuperação. Então, quando tudo falha, o root ainda tem acesso.


[5] Comentário enviado por meinhardt_jgbr em 23/02/2010 - 10:48h

Nas primeiras vezes que instalei o Mandrake, cheguei a usar uma pequena partição separada também para o /boot porém hoje em dia faço as instalações apenas com três partições, uma para o swap, outra para o sistema ou raiz (/) e outra para os dados e configurações (/home).

Cheguei mesmo a pensar a voltar a deixar o /boot em partição separada, principalmente pensando em várias distros instaladas ao mesmo tempo e com isto facilitar a edição dos arquivos de configuração quando instalo novas distros. Com a chegada do GRUB2 em muitas distros em substituição ao Grub Legacy, talvez isto venha a facilitar.

[6] Comentário enviado por Marcus-RJ em 23/02/2010 - 13:57h

Concordo com o usuario @stack_of , realmente o Xorg e ate mesmo outros componentes como KDE/GNOME tem dado trabalho no gnu-linux, e acontece do sistema "congelar". Muitas vezes devido a blobs da nvidia e afins.
Nao foi o caso deste artigo (meio ao estilo "Eduardo e Monica/Faroeste Cabloco", Legiao Urbana), no entanto.

Abs!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts