Tópico Oficial: Ubuntu 8.10 (Intrepid Ibex) - Versão Final Disponível

[Emerickrl]

Estou com um problema depois de instalar o 8.10, sempre que inicio, me pede o login e senha nao na forma grafica e cai diretamente em tela cheia no terminal e dai nao saio mais. Sou iniciante e nao conheco os comandos do terminal para que eu possa arrumar essa situacao. Alguem pode me ajudar? Obrigado

[Alakazan]

digite sudo gdm depois de logado. Ser você tiver como root, digite só gdm.

[Emerickrl]

  Fiz o que voce me pediu, mas tive a resposta que o GDM ja estava em execucao e abortou o comando.
Ser'a que outras pessoas passaram pelo mesmo problema? Se tiveram solucao por favor me comuiuem. Obrigado.

[Alakazan]

Tem um comando que força a interface gráfica a iniciar, SE NÃO ME ENGANO é ALT+F7.
Mas ele rodava normal do live cd?

[Emerickrl]

Fiz a atualizacao pela internet,nao usei o live cd.

[Emerickrl]

Ja fiz o pedido do cd direto para a Canonical, vou ficar esperando. A sorte e que ja tinha feito o backup dos arquivos. Estou usando o live do 6.06.  Obrigado pela ajuda. Um abraco.

[Darcamo]

Fiz o que voce me pediu, mas tive a resposta que o GDM ja estava em execucao e abortou o comando.
Ser'a que outras pessoas passaram pelo mesmo problema? Se tiveram solucao por favor me comuiuem. Obrigado.

Tente Ctrl+Alt+F7, se não funcionar tente também com F8,F9,...,F12
Normalmente a interface gráfica fica no "7" (1 a 6 são terminais em texto).

Se ela não estiver rodando em nenhum, logue em algum terminal de texto e digite

Código Selecionar Expandir

sudo /etc/init.d/gdm restart
para reiniciar o gdm. Caso não funcione pode ser que ao menos você obtenha uma pista do porquer não estar funcionando.

[dtomadon]

Aí galera , ontem depois de baixar algumas atualizações o meu network manager evaporou do mapa, aconteceu com mais alguém ?

[galactus]

Na atualização que peguei hoje, veio a correção do bug de ejeção das bandejas de CDs/DVDs.

A solução para o bug de ao Ejetar o CD/DVD a bandeja abrir e fechar ao mesmo tempo, enquanto a Canonical não se pronuncia, é:

editar o arquivo 60-persistent-storage.rules que se encontra em /etc/udev/rules.d na linha que tem:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

para:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
ENV{DEVTYPE}=="disk", KERNEL=="sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

Pois é, era isso mesmo que ia comentar aqui! O BUG da ejeção do CD acabou-se! E olha que foram quase 30MB de atualizações hoje.

[alarcon]

nicoluis e galactus  sempre que vejo no gerenciador de atualizações atualizações de kernel e/ou udev eu desfaço a dica que postei aqui:

A solução para o bug de ao Ejetar o CD/DVD a bandeja abrir e fechar ao mesmo tempo, enquanto a Canonical não se pronuncia, é:

editar o arquivo 60-persistent-storage.rules que se encontra em /etc/udev/rules.d na linha que tem:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

para:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
ENV{DEVTYPE}=="disk", KERNEL=="sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

para ver se o erro do ejetar foi solucionado, mas aqui a última atualização do udev resolveu apenas em parte o meu problema e as atualizações do kernel anteriores ao do udev em nada resolveram este bug.

Explicando melhor eu tenho aqui um gravador de DVD R/RW (que grava e lê CDs e DVDs) e um Leitor de CD apenas. Para o DVD a atualização do udev funcionou, ou seja, ao ejetar ele não fecha novamente logo em seguida. Já para o apenas Leitor de CD o erro persiste.

A solução apresentado por mim anteriormente (retirado do google) resolve para os dois driver ópticos que tenho aqui, portanto ainda continua como sugestão para aqueles que tenham mais de um driver óptico e que um deles ainda esteja com problemas.

O que percebi é que o arquivo 60-persistent-storage.rules original que apresentou problemas para vários usuários em uma certa linha estava assim:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

A solução que encontrei na internet dizia para deixar assim:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
ENV{DEVTYPE}=="disk", KERNEL=="sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

A atualização do udev que resolveu somente para um driver óptico meu deixou assim:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
# skip optical drives without media
ENV{DEVTYPE}=="disk", KERNEL=="sr*", ENV{ID_CDROM_MEDIA_TRACK_COUNT}!="?*", GOTO="persistent_storage_end"

esta mesma linha. Só a título de curiosidade.

[Hqxriven]

A nível de hardware...

X2 ou maior (e não Core 2 Duo) em placas que não sejam MSI com bios recente que suporte bem TK que não seja phoenix com mais de 1GB de memória usando apenas um HD SATA2 (não usando ide) usando ADSL, sem webcam, com ondemand com driver de vídeo recente (e placa também) e sem kde4 e com apenas uma placa de som...

Desativando todos os módulos do boot e não salvando a sessão no caso gnome... desativando programas de indexação também...

Vcs não querem que eu explique o pq de tudo, não é??? (Sejam bonzinhos!!!)

http://ubuntuforum-br.org/index.php/topic,36634.msg253182.html#msg253182

Como eu havia relatado no dia 10 dessa mensagem aí em cima havia um problema (bios phoenix, etc) e ainda bem ontem dia 13 foi corrigido com a versão 27.6 do kernel.

Isso significa que em breve a galera que usa o Intrepid vai poder usar esse Linux direito (sem muitas gambiarras).

Caramba eu acho que estou sabendo de bugs demais... (hehehe)

commit c27c4b666ddf7a36b6f20c9b809217157496b36b
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date:   Tue Sep 23 00:35:33 2008 -0700

    x86: fix macro with bad_bios_dmi_table
   
    commit a8b71a2810386a5ac8f43d2095fe3355f0d8db37 upstream.
   
    DMI tables need a blank NULL tail.
   
    fixes the crash on Ingo's test box.
   
    Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 5c371b31be32033b0a4a993431484da8a2305369
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date:   Mon Sep 22 02:52:26 2008 -0700

    x86: fix CONFIG_X86_RESERVE_LOW_64K=y
   
    commit 2216d199b1430d1c0affb1498a9ebdbd9c0de439 upstream
   
    The bad_bios_dmi_table() quirk never triggered because we do DMI setup
    too late. Move it a bit earlier.
   
    Also change the CONFIG_X86_RESERVE_LOW_64K quirk to operate on the e820
    table directly instead of messing with early reservations - this handles
    overlaps (which do occur in this low range of RAM) more gracefully.
   
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 093327cb21660a2f0c028c9c8550b2808600281f
Author: Ingo Molnar <mingo@elte.hu>
Date:   Tue Sep 16 10:07:34 2008 +0200

    x86: add X86_RESERVE_LOW_64K
   
    commit fc38151947477596aa27df6c4306ad6008dc6711 upstream.
   
    This bugzilla:
   
      http://bugzilla.kernel.org/show_bug.cgi?id=11237
   
    Documents a wide range of systems where the BIOS utilizes the first
    64K of physical memory during suspend/resume and other hardware events.
   
    Currently we reserve this memory on all AMI and Phoenix BIOS systems.
    Life is too short to hunt subtle memory corruption problems like this,
    so we try to be robust by default.
   
    Still, allow this to be overriden: allow users who want that first 64K
    of memory to be available to the kernel disable the quirk, via
    CONFIG_X86_RESERVE_LOW_64K=n.
   
    Also, allow the early reservation to overlap with other
    early reservations.
   
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 41943efb7cff566ad1f6334bbddbb8b8a4bfeb59
Author: Ingo Molnar <mingo@elte.hu>
Date:   Tue Sep 16 09:58:02 2008 +0200

    x86: reserve low 64K on AMI and Phoenix BIOS boxen
   
    commit 1e22436eba84edfec9c25e5a25d09062c4f91ca9 upstream
   
    there's multiple reports about suspend/resume related low memory
    corruption in this bugzilla:
   
      http://bugzilla.kernel.org/show_bug.cgi?id=11237
   
    the common pattern is that the corruption is caused by the BIOS,
    and that it affects some portion of the first 64K of physical RAM.
   
    So add a DMI quirk
   
    This will waste 64K RAM on 'good' systems too, but without knowing
    the exact nature of this BIOS memory corruption this is the safest
    approach.
   
    This might as well solve a wide range of suspend/resume breakages
    under Linux.
   
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 71556e929b5666bc03750402ce30e3c61cd5148e
Author: Ingo Molnar <mingo@elte.hu>
Date:   Tue Sep 16 09:29:09 2008 +0200

    x86: add DMI quirk for AMI BIOS which corrupts address 0xc000 during resume
   
    commit 5649b7c30316a51792808422ac03ee825d26aa5e upstream
   
    Alan Jenkins and Andy Wettstein reported a suspend/resume memory
    corruption bug and extensively documented it here:
   
       http://bugzilla.kernel.org/show_bug.cgi?id=11237
   
    The bug is that the BIOS overwrites 1K of memory at 0xc000 physical,
    without registering it in e820 as reserved or giving the kernel any
    idea about this.
   
    Detect AMI BIOSen and reserve that 1K.
   
    We paint this bug around with a very broad brush (reserving that 1K on all
    AMI BIOS systems), as the bug was extremely hard to find and needed several
    weeks and lots of debugging and patching.
   
    The bug was found via the CONFIG_X86_CHECK_BIOS_CORRUPTION=y debug feature,
    if similar bugs are suspected then this feature can be enabled on other
    systems as well to scan low memory for corrupted memory.
   
    Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
    Reported-by: Andy Wettstein <ajw1980@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Eu acho uma excelente notícia pq pelo que vejo em pouco tempo teremos o Intrepid com um kernel mais estável nesse aspecto... e mais gente que está tendo travamentos e problemas nessa versão terá paz!!

[Luigi.H]

Pessoal, não sei se já tem uma resposta à isso, e se este seria o tópico exato mas...
Seguinte,baixei o Ubuntu 8.10 no site e instalei no Vista Home Premium, tudo belezinha, só que ele não dá boot na hora que liga o notebook, e mesmo quando entro na BIOS só aparece que o OS disponível a ser iniciado é o Vista...
então... o que fazer??? XP

[marcosalvesps]

Caro amigo,
Vc disse que instalou ele dentro do windows vista certo? Então creio que o Ubuntu não vai ser iniciado no boot, pois vc o instalou dentro do visto como se fosse um programa, ele deve ser iniciado dentro do vista.

Para que ele inicie diretamente ao ligar o pc, vc deve particionar o HD e instalar o Ubuntu em uma partição separada do windows.

Me corrijam se disse alguma besteira!

Abraços!

[rodrigo.miguel]

Caro amigo,
Vc disse que instalou ele dentro do windows vista certo? Então creio que o Ubuntu não vai ser iniciado no boot, pois vc o instalou dentro do visto como se fosse um programa, ele deve ser iniciado dentro do vista.

Para que ele inicie diretamente ao ligar o pc, vc deve particionar o HD e instalar o Ubuntu em uma partição separada do windows.

Me corrijam se disse alguma besteira!

Abraços!

Ele inicia no Boot. Não pelo Grub, mas pelo gerenciador de Boot do Windows...

[yzarc]

hoje recebi um update que consertou o bug do "." do teclado abnt2