Arquivos históricos do BR-Linux.org apresenta:

Bug do Fedora Core 2 com dual boot

Notícia publicada por brain em maio 28, 2004 09:33 PM | TrackBack


Paulo Dias (joshua.t@tutopia.com.br) enviou este link e acrescentou: "Olá pessoal, Venho através desta mensagem alertar para um bug no Fedora Core 2. Ao fazer dual boot com o Windows XP, a instalação do Windows se torna inoperante. Você não perde seus dados como é informado durante a instalação do sistema, podendo até acessá-los mais tarde de dentro do Fedora. Mas terá que reinstalar o Windows, pois a restauração da MBR através do prompt de comando não funcionará. Envio este link de referência que usei para solucionar o problema. Outras informações e possíveis soluções podem ser encontradas também no link da O'Reilly." O problema não é propriamente novidade, mas a possível solução pode ser interessante.

 

Comentários dos leitores
(Termos de Uso)

» Douglas Augusto () em 28/05 21:47

Bug que buga outro bug, cem anos de perdão!

Isso para mim não é um bug, mas sim uma nova funcionalidade (extremamente útil) do Fedora Core 2. É o incentivo que faltava para largarem de vez o Windows.


» Antonio Censi () em 28/05 22:16

Uma questão ainda me intriga, o problema pode acontecer com RH ou FC, Mdk e Sues. Já vi referências de que acontece com Conectiva (que também usa o Grub), mas que segundo consta já resolveu tudo.

A causa é clara, em certas instalações do WInXP é ativada o LDM que precisa de algum suporte no Linux e de que certos parâmetros no MBE que eram pouco imporantes anteriormente agora são usados para acessar a tabela de particções no final do disco. O parted altera um deles (head count, provavelmente) baseado na resposta do Kernel 2,6 qeu é ddiferente do 2.4 e o Grub não acha o boot do WinXP. O Lilo com usa endereços absolutos não é afetado.

Tá na hora do pessoal da Conectiva dizer como resolveu o problema, que também deve ser menos frequente no Brasil e na Europa que nos EUA.


» Manoel Pinho () em 28/05 22:28

O engraçado é que eu instalei o Conectiva 10 beta 1 em 3 máquinas diferentes no trabalho e em uma delas havia o XP instalador em FAT32. Não tive nenhum problema.

Um amigo meu fez o mesmo no micro dele e ele disse que não conseguia dar mais boot no XP. Ele conseguiu restaurar a tabela de partições depois.

Será que tem a ver com o Service Pack 1 do XP ?

Mas achei engraçada essa "funcionalidade". Bem que a comunidade linux poderia criar um vírus que formatasse o hd e instalasse nele aquele Famelix (o Kurumin com cara de XP). Acho que ia ter gente que levaria um tempão para notar a diferença :-)


» RedCzar777 () em 28/05 23:01

Bom, tenho o XP, com o service pack 1 e todas as atualizações, e o Fedora Core 2 instalados. Posso dizer que não tive nenhum problema para fazer dual-boot.


» Paulo Zambon () em 28/05 23:23

Bendito Bug! Poderíamos aproveitá-lo para nunca mais usarmos o Windows! Desculpem, não resisti... ;-)


» Marcelo Vivan Borro () em 28/05 23:40

Antonio,a solução encontrada pela Conectiva está na lista Snapshot-users.
Se não me angano, bastou aplicar um patch de correção ao parted.
Vale lembrar que no Conectiva o problema ocorreu nos Betas do CL10 e foi resolvido antes dos Release Candidates.


» Ambulante da Praça () em 29/05 01:16

Eu acho que isso é um baguho que a M$ colocô só pra dizê que é defeito do linux...

Acho que o XP, já muito bixado, tá querendo "bixa" (acho brabo!!) o linux pra dispois fala mau...

Pelo menos tentô.

Antes rí pra não xorá.


» MediaSonic () em 29/05 09:24

Um patch no Parted? Provavelmente o FC usa o Parted como back end. O problema é ter que fazer isso antes de instalar o FC, certo? Provavelmente uma mexida na imagem do instalador resolve.


» cvs () em 29/05 09:58

fedora? o que é isso?

tsc tsc tsc


» Joerlei P. Lima () em 29/05 11:38

Esse problema ocorre em praticamente qualquer distribuição que use o Kernel 2.6. Já vi casos de pessoas reclamando desse problema com SUSE, Mandrake (com grub), Fedora, etc. Entretanto, há na internet meios de se contornar o problema.


» anom () em 29/05 14:52

Opa, tem certeza que o problema é so com o GRUB? Estava eu usando o mandrake 10CE e aumentei o tamanho de uma particao usando a ferramenta do mandrake. Resultado, pelo LILO (default do mandrake), nao consegui acessar o WinXP. O problema foi resolvido mudando o access mode do HD para LBA. Esta dica eu peguei justamente numa discussao sobre este problema no fedora.


» José Luiz () em 29/05 16:56

Já tive problemas em dual-boot 2 vezes ano passado,usando win-xp e Mandrake 9.1, na 1ª vez,usei "fdisk/mbr" o win não entrava de jeito nenhum, acessava o mdk pelo disquete,resolvi o problema restaurando a MBR através do FREE-DOS de um disco destes que acompanham revistas,atualmente uso windows-xp em hda e Mandrake 10 em hdb,instalo o lilo em hdb e configuro o dev1 no "setup" como 1º boot,mesmo assim outro dia, o lilo deu bronca,não entrava nada,corrigi o problema com uma atualização,e,está tudo bem,em caso de bronca,mudo o "setup" para 1º boot pelo ide0 e acesso o windows-xp que meus filhos usam.


» Manoel Pinho () em 29/05 19:34

Pelo que andei lendo na internet o bug é do Windows (não sei exatamente qual versão e SP), e não do linux, do grub ou do lilo. E parece que a ssolução é simples: só colocar o hd no modo LBA na BIOS.


» Paulo Dias () em 29/05 20:41

Ei, olhem só este link: http://lwn.net/Articles/86835/
Nele encontrei uma solução que funcionou em quatro máquinas diferentes.
OBS: Quem já largou o XP e está usando só o Fedora, evite ler isto ;-)


» pnc () em 30/05 08:58

fedora? o que é isso?

tsc tsc tsc

è o sonho de consumo da Conectiva !!!

se bem que não sei se Conectiva ainda existe !!!

rsrsrsrsrsrsrsr


» Manoel Pinho () em 30/05 10:09

Fedora sonho de consumo da Conectiva ??!! Pelo que pude testar até agora o Fedora é bem pior do que o CL10 e o Mandrake 10. É uma distribuição lenta e pesada, com KDE piorado, vem sem pacotes multimídia e oficialmente usa o yum, que é bem mais lento e pior do que o apt. Sim, existe o apt para Fedora, mas não é a ferramenta oficial e o apt-rpm é invenção da Conectiva, que tanta gente gosta de tacar pedras sem motivo.

Os pontos positivos para mim são o intuitivo e organizado instalador Anaconda (que também está sendo portado para o Debian) e o grande repositório de pacotes, herança da popularidade do Red Hat e não mérito próprio do Fedora, que com certeza possui menos usuários do que a Red Hat tinha.


» anom () em 30/05 11:36

Rapaz, se experiencia com linux fosse ciencia nao seria uma ciencia exata. É incrivel como as pessoas tem resultados diferentes talvez influenciadas talvez por uma pre-disposicao em falar mal.

Eu estava usando mandrake e passei pro fedora e nao vi a tal lerdeza deste. Claro que, assim como fiz com o mandrake, desabilitei servicos que nao se aplicam a minha estacao de trabalho, resultando em desempenho, pelo menos até onde minha percepcao alcanca, semelhante a do mandrake.

O gerenciamento de pacotes no fedora é realmente pior. O motivo é simples: a ferramnta que gerencia os pacotes do CD nao tem nenhum suporte aos repositorios na internet. O Synaptic do repositorio freshrpms contorna, em parte, o problema, embora os CDs do Fedora nao possam ser incluidos como repositorio para o apt. Ou seja, quem nao quer ter trabalho para arrumar o sistema de gerenciamento de pacotes que ja vem redondo no Mandrake e imagino que no Conectiva talvez nao deva usar o Fedora.

Por fim, nao é merito do fedora ter o repositorio que tem? Eu nao tou reaproveitando repositorios do RedHat nao. Eu tou usando repositorios especificamente criados para o Fedora. Se nao houvesse merito, os respositorios ja teriam sumido do mapa. Quanto ao numero de usuario, isso nao me preocupa e nao deveria preocupar alguem que defende o Conectiva, distribuicao cujos usuarios se limitam aos brasileiros.

Boa sorte a Conectiva, pelo synaptic e o porte do apt para rpm que uso no fedora. Pra mim, com todos os defeitos vou ficar com o fedora mesmo. Bom repositorio, e até agora tá funcionando bem, sem bugs relevantes e com desempenho semelhante ao mandrake, que usava antes.


» anon2 () em 30/05 18:37

é isso aí...

..conectiva usei alguns anos,vivia mais tentando corrigir seus erros que propiamente usando-o.

Nós sou contra nenhuma distro, mas Conectiva sucks...

Fedora pesado, não sei aonde....

Boa noite Conectiveiros...

have a lot of bad dreams...


» Manoel Pinho () em 30/05 20:10

Como disseram aí, distribuições são escolhidas por gostos e experiências pessoais e não é matematicamente precisa, mas daí ficar pichando com "... sucks" é coisa de criança.

Não uso somente Conectiva e nem tenho qualquer relação com a empresa. Realmente a distribuição é praticamente restrita ao Brasil, mas o engraçado é que ela é mais respeitada lá fora (e por méritos técnicos) do que aqui dentro. Fico triste pelo preconceito de certos brasileiros de que tudo que é nacional "sucks" (nem isso falam em português...).


» ThLux () em 30/05 21:13

Falou e disse... Manoel Pinho!


» Tchelo_Xinelo () em 31/05 14:01

Affe!!!

Normal do brasileiro preferir produtos estrangeiros!!!!

Conectiva 10
Estou a sua espera!!!

100+


» Phantom X () em 05/06 17:24

Quem disse que o conectiva é brasileiro?
Por acaso o kernel é brasileiro? A maioria dos programas também são?
Acho que ficarem brigando por causa de sistemas operacionais é besteira! Em vez disso, comprem um hd maior e coloquem pelo menos uns 4 SOs para ver as vantagens e desvantagens de cada um, usem o que acharem melhor e se calem em relação aos outros, pois se alguem usa um SO que você não gosta, é problema dele.

Eu gosto de Linux e de Windows, e daí se existe gente que não gosta...


» Renan Opel () em 05/06 20:16

O Conectiva é brasileiro e feito por brasileiros. Se não fosse por ele, milhares de usuários de Linux no país não teriam se iniciado no SO do pinguim. Pra quem está começando, como universitátios e curiosos é um ótimo SO. Agora depois de uma certa evolução, podem migrar para outras distribuições normalmente, se acharem necessidade. E não precisa ficar falando mal depois.

Todos nós, da comunidade Linux deveríamos nos ajudar e não nos degladiar. Um possível inimigo é o Windows e seu caminhão de $$$poder$$$$ e bugs.

E quanto ao kernel, ele é open source, é o mantenedor é brasileiro, Marcelo Tosatti. Assim como os programas, todos podemos contribuir no desenvolvimento, então o "nacionalidade" do software não é de lugar nenhum.

É bom muitos prestarem atenção no que dizem!!!!

Até mais....


» Usuário Conectiva dorme tranqüilo () em 05/06 21:37

Calem a boca. Usem Conectiva e ajudem o Brasil ser uma potência tecnológica.


» Fabricio () em 09/06 15:54

Afinal de contas, alguém sabe uma maneira de consertar o boot do xp, sem ter que reinstalá-lo?
Estou com problemas no grub do conectiva, apesar de aparecer a opção de rodar o XP, quando seleciono, a maquina tenta dar o boot mas retorna para o grub.



» Marco Pacheco () em 21/06 20:49

Fabrício, tive o mesmo problema que vc. Assim que terminei de instalar o Fedora 2 eu não mais consegui dar boot pelo win me. Toda vez que selecionava esta opção no grub ele retornava para o grub. Ao entrar no FC2 novamente, eu não mais tinha acesso a minha partição windows. Conclusão: Formatei tudo de novo e reisntalei o windows.

Agora estou com um problema. Eu não tenho disco de boot do FC2 e acho que so vou conseguir entrar no sistema com o cd de instalação no modo Rescue!! E vou tentar reinstlar o grub na MBR e ver se vai ficar tudo direitinho.

Até agora não entendi por que minha partição fat foi pro saco.

Só para deixar registrado, eu achei o FC2 bem mais rápido que o FC1. Acho que a galera não devia ficar brigando por distribuição, afinal de contas, é tudo linux e cada um usa a que mais lhe agrada.

Abraços


» Phantom X () em 26/06 21:25

Tá cheio de tutoriais para consertar o boot do Fedora na internet.
Tentem instalar o grub só na partição (superbloco) e usem o truque do dd para ver se funciona


» Renato () em 30/06 08:17

Colegas, instalei o Fedora Core 2 e o WindowsXP na minha máquina pessoal e obtive os mesmos problemas, mas no meu caso, não adiantou usar o sfidsk para resolver o problema de geometria do hd. Então reinstalei os dois sistemas, primeiro o windows e depois o Fedora, sendo que informei ao Fedora a geometria do hda antes de iniciar o boot, dessa maneira:
boot: linux hda=CHS
Onde boot é a tela inicial da instalação, logo assim que você "boota" o CD, e CHS é, respectivamente, cilindros, cabeças e setores do hd onde ficará o grub, isto é, na MBR.
Feito isso, não tive mais problemas com nenhum dos dois. Espero ter contribuido.

Abraços a todos.


» Fábio Cabrini () em 08/07 17:50

Olá Pessoal,

Estou migrando meus servidores para o Fedora Core 2, pois tenho experiência com o RedHat 9.

Tive muitos problemas com o Conectiva X.

Este problema só afeta máquinas com dual boot, acredito que para quem abandonou a idéia de utilizar o Windows isto deixa de ser um problema.

Sem Mais ...


» José Carlos () em 16/07 21:27

Acabei de instalar o Fedora, porem qdo reiniciou o sistema foi direto e reto pro maldito winxp...
Olhei na bios e tah tudo ok... mudei tb todas as ordens de boot, e nada... Estranho pakaz.
Alguem pode dar um Help???


» Phantom X () em 24/07 21:58

José Carlos, vc naum instalou o grub na partição por engano? Tente entrar no modo rescue e instale o grub manualmente. Espero ter ajudado!


» Paulo J.A. dos Reis () em 12/08 08:40

Não é preciso reinstalar o windows; para recuperar o mbr é so usar o ptedit do partition magic e rescrever as informações CHS novamente e mandar grarvar, ao sair o ptedit, use ptbootx e mande dar boot na partição do windows, pronto o mbr esta recuperado. Depois use o cd rescue do fedora e mande gravar o Grub de novo ai não ocorre mais bug ja q este se encontra na instalação.


» Edusousa () em 01/09 18:08

Tenho um servidor de FTP rodando RedHat 9....porém está ocorrendo algum bug que não consegui resolver, pesquisei na net e descobri alguns casos semelhantes ( http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=39078 )um dos poucos comentarios que li não resolveram meu problema. Alguém poderia me ajudar ???

Segue erro retirado do log:

PCI: Cannot allocate resource region 0 of device 00:0f.0
PCI: Cannot allocate resource region 1 of device 00:0f.0
PCI: Cannot allocate resource region 2 of device 00:0f.0
PCI: Cannot allocate resource region 3 of device 00:0f.0
PCI: Cannot allocate resource region 4 of device 00:0f.0
PCI: Cannot allocate resource region 5 of device 00:0f.0

PCI: Error while updating region 00:0f.0/1
PCI: Error while updating region 00:0f.0/2
PCI: Error while updating region 00:0f.0/3
PCI: Error while updating region 00:0f.0/4
PCI: Error while updating region 00:0f.0/5


» fernando arcella () em 10/10 15:09

TENTEI INSTALAR O FEDORA 2,MAIS NAO FUNCIONOU NEM O FEDORA E NEM WINDOWS TENTEI FORMATAR O HD NEM ISSO RESOLVEU. ESTOU IMPOSSIBILITADO DE INSTALAR QUALQUER S.O MICROSFT.
OBS: O LINUX ESTLA BLZ QUALQUER DITRIBUIÇAO O QUE FAZER?


» fnazaro () em 15/10 08:49

Olá caras,
Tive o mesmo problema e pesquisando, na net encontrei um guia bastante abrangente sobre o assunto. Ainda não testei mas talvez alguém queira fazê-lo antes de mim:

Fonte: www.fedorabrasil.com.br

Pois bem , depois de tantos problemas com o bug do dual boot , Jeff Spaleta (do Projeto fedorabrasil) decidiu escrever um guia baseado nas discussoes sobre o assunto. O orignal pode ser lido em http://www.redhat.com/archives/fedora-deve...y/msg00908.html .

Problemas de dual boot com Fedora Core 2 e Windows XP - ntfs Prevencao e Recuperacao

Atencao: Por favor , leia este documento em sua complitude.

Esse guia foi inspirado pela solucao desenvolvida por Radu Cornea e Alexandre Oliva no thread http://www.redhat.com/archives/fedora-test...y/msg02114.html .

Esse guia tenta integrar a solucao original com refinamentos que surgiram naquele thread. O guia oferece uma explicacao de porque os refinamentos sao beneficos e algumas saidas para os problemas que podem impedir o uso da solucao por nao iniciados. Ele tambem prove meios de prevenir o problema inteiramente.

Introducao:
O Fedora Core 2 possui um bug que causa a alteracao da geometria do disco rigido como reportada pela table de particoes durante a instalacao. Esta mudanca pode causar falhas ao tentar carregar o Windows. Apesar da severidade deste bug , ele eh corrigivel e eh possivel nao perder dados. Eh importante nao entrar em panico se e quando isto ocorrer , para evitar maiores problemas ou perda de dados no processo de recuperacao do erro.


Prevencao:
Este bug pode ser evitado completamente usando-se alguns passos preventivos no momento da instalacao do Fedora Core 2. Agradecimentos para Cero (cero at coolnetworx.net) por descobrir e testar essa solucao.
Para evitar que a geometria do disco seja alterada , voce pode entra-la manualmente durante a instalacao usando o parametro hdN= (onde N eh a letra representando o drive com a MBR que voce vai usar). Para descobrir a geometria atual antes de instalar o Fedora Core 2 , voce deve usar uma ferramenta que consegue ler a geometria do drive como reportado na tabela de particoes. Eh importante entender que algumas ferramentas podem nao estar reportando os dados exatos deste local , mas algum valor derivado , entao a melhor saida eh usar o fdisk. Voce pode conseguir essa informacao seguindo esses passos.

Nota: esse exemplo assume que voce vai estar olhando o dispositivo /dev/hda , que eh o dispositivo Master na IDE primaria. Se a sua MBR estiver localizada em outro dispositivo , voce deve usar o nome deste (ex: /dev/hde)

Baixe e grave o cd Rescue do Fedora Core 2.

De boot a partir do CD de rescue (nao eh necessario iniciar a rede ou montar os drives).

De o comando: fdisk -l /dev/hda para imprimir a tabela de particoes atual em modo nao interativo.
Anote a geometria de disco reportada no inicio da saida do fdisk. Ela eh reportada como um numero de Cilindros (Cylinders) , Cabecas (Heads) e Setores (Sectors)(dai o nome CHS).

Voce pode agora reiniciar o computador pressionando simultaneamente as teclas Ctrl-Alt-Delete.

Voce pode agora dar boot usando o cd de instalacao do Fedora Core 2. No primeiro menu , voce deve executar o instalador com a geometria conhecida.

Exemplo: linux hda=14593,255,63

O instalador deve agora executar normalmente e provavelmente nao alterara a geometria do disco. Se , por alguma razao , a geometria for alterada mesmo com esse passo preventivo , use os passos de recuperacao para corrigir a geometria do drive como reportado pela tabela de particao.

Recuperacao:

Voce instalou o Fedora Core 2 e descobriu que nao consegue carregar o Windows. Normalmente o processo de inicializacao vai terminar com as palavras

Rootnoverify(hd0,0)
Chainloader +1

Esses sao os parametros da sua configuracao do grub. Os parametros provavelmente estao corretos , mas o Windows falha ao iniciar porque o Fedora Core 2 alterou a geometria do disco como reportado pela tabela de particao dos discos.

Importante: Nao entre em panico e nao comece a usar multiplas ferramentas em uma tentativa de corrigir esse erro. Ferramentas automaticas podem ser muito perigosas. As verdadeiras mudancas que devem ser feitas sao pequenas e benignas. Usando ferramentas de terceiros para recuperar a sua instalacao do windows pode causar a perda de dados. Voce foi avisado.

Para aqueles que tem uma inclinacao tecnica , I incluo aqui uma breve explicacacao do que esta acontecendo. O disco nao foi danificado e sua tabela de particoes esta OK. O problema eh que o Windows reuqer uma tabela CHS "perfeita" . Essa tabela foi alterada pelo instalador do Fedora Core e o Windows trava. Por sorte , a verdadeira tabela , no formato LBA , nao foi corrompida. Para aqueles vendo uma tabela de particoes estranha , note que provavelmente voce esta vendo a tabela em valores de CHS e esses valores sao derivados da geometria. O GNU/Linux nao usa esses valores e opera puramente com os valores de LBA. O Windows nao deveria estar usando CHS tambem , mas por alguma razao , ele checa a geometria CHS e pode travar por essa geometria nao estar correta. Mudar a geometria do disco muda a tabela de particoes CHS porque ela eh uma virtualizacao do estado do disco , que eh melhor descrita como sendo mistico. Pense na geometria CHS como um compasso. Se voce muda a geometria , voce recalibrou o ponto de referencia da agulha e nao esta mais olhando para o norte verdadeiro.

A solucao para este problema eh bem simples , mas ela pode confundir , pois a maioria das pessoas vai questionar porque elas estao vendo valores estranhos sendo reportados pela tabela de particao no formato CHS. Se voce nao confia nessa solucao ou na sua habilidade para seguir esses passos , entao voce deve parar e procurar ajuda especializada na recuperacao de dados. O Projeto Fedora nao eh responsavel de maneira nenhuma por perda de dados e este guia eh oferecido sem garantias. Voce assume a reponsabilidade pelo que acontecer. Agora , vamos a solucao.

Ja que somente a geometria foi alterada , nao existe a necessidade de intervencao manual na forma de descobrir e alterar as informacoes das particoes. As informacoes na tabela de particoes estao corretas. Entretanto , voce deve alterar a geometria e normalmente isso requeriria que voce recriasse a tabela de particao manualmente usando uma ferramenta como o fdisk. Entretanto , esse ponto eh onde a ferramenta sfdisk vem ao resgate. Sfdisk pode ser muito poderoso em modo nao-interativo. Ele pode imprimir informacoes que podem ser usadas como entrada em qualquer lugar e ele pode aceitar dados como entrada em tempo de execucao. Isso faz o sfdisk ideal para esta solucao , pois voce pode pedir para ele ler a tabela de particao e entregar o resultado em uma forma que ele mesmo pode escrever no disco quando voce mandar alterar a geometria. Isto faz o processo rapido e diminui o risco de erro humano , pois poucos valores devem ser entrados. A solucao pode ser resumida em uma unica linha com dois comandos:
sfdisk -d /dev/hda |sfdisk --no-reread -H255 /dev/hda

Para que o leitor entenda melhor o que esta ocorrendo aqui , vamos passar por cada secao e explicar o que cada parametro significa.

sfdisk -d /dev/hda

Essa parte roda o sfdisk em modo nao-interativo e imprime a tabela de particao em um formato que o sfdisk pode usar como entrada (que eh o que estamos fazendo). Tente este comando por si so para ver sua tabela de particoes. Voce vai querer checar a saida para garantir que nao existem warnings. Esses avisos podem ser um problema , pois eles interferem no uso destes dados como entrada. Uma saida contendo um aviso pode parecer com o exemplo abaixo:

$ sfdisk -d /dev/hda
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
# partition table of /dev/hda
unit: sectors

/dev/hda1 : start= 63, size= 16771797, Id= 7, bootable
/dev/hda2 : start= 16771860, size=217632555, Id= f
/dev/hda3 : start= 0, size= 0, Id= 0
/dev/hda4 : start= 0, size= 0, Id= 0
/dev/hda5 : start= 16771923, size=104856192, Id= 7
/dev/hda6 : start=121628178, size=112776237, Id= 7

Por razoes desconhecidas , o uso da opcao --quiet nao oculta todos os avisos , logo torna-se tarefa do usuario uma maneira de usar a saida como entrada. A maneira mais simples eh gravar a saida num arquivo de texto puro , edita-lo para remover o aviso e entao usar o arquivo resultante como entrada. Logo:

sfdisk -d /dev/hda > tabeladeparticoes.txt
Edite o arquivo tabeladeparticoes.txt para remover os avisos , salve o arquivo e entao:
cat tabeladeparticoes.txt | sfdisk --no-reread -H255 /dev/hda

A saida de "sfdisk -d /dev/hda" deve comecar assim: (este eh a versao editada do exemplo mostrado anteriormente):

# partition table of /dev/hda
unit: sectors

/dev/hda1 : start= 63, size= 16771797, Id= 7, bootable
/dev/hda2 : start= 16771860, size=217632555, Id= f
/dev/hda3 : start= 0, size= 0, Id= 0
/dev/hda4 : start= 0, size= 0, Id= 0
/dev/hda5 : start= 16771923, size=104856192, Id= 7
/dev/hda6 : start=121628178, size=112776237, Id= 7

Note que "cat tabeladeparticoes.txt" toma o lugar de "sfdisk -d /dev/hda" pois eles sao equivalentes. Neste caso , a parte do aviso foi retirada , preservando-se os dados pedidos pelo passo dois do comando.

sfdisk --no-reread -H255 /dev/hda
Esta parte do comando executa a mudanca no seu disco. A principal operacao eh -H255. Isto faz com que o sfdisk grave uma contagem de 255 cabecas na geometria do disco. O comando executado sozinho pediria ao usuario a entrada da tabela de particoes (como fdisk). Entretanto , usando um pipe para redirecionar a tabela que nos lemos no primeiro comando , isso eh evitado e diminui-se o trabalho e nos sabemos que os dados sao corretos (ou , no minimo , os mesmos). Essa eh a razao de usarmos o sfdisk.

A opcao --no-reread permite a execucao do comando mesmo quando uma particao esta montada. Alguns usuarios acabam precisando forcar um pouco mais a operacao para que ela seja completada. Isto eh feito usando --force (sfdisk --no-reread --force -H255 /dev/hda).

Neste exemplo , nos estamos mudando somente o numero de cabecas da geometria.
Se voce sabe o numero correto de cilindros antes do Fedora Core ter alterado estes valores , voce tambem pode alterar este valor. Um exemplo com 14.593 cilindros eh mostrado abaixo:
sfdisk -d /dev/hda | sfdisk --no-reread -H255 -C14593 /dev/hda

O numero de setores reportado (S) nao deve ter mudado e deve ter permanecido como 63.
Essa parte eh onde aparece a pergunta "se eu mudo o numero de cabecas , eu preciso mudar o numero de cilindros?". A resposta para a pergunta eh "nao". Quando a geometria foi mudada , o numero de cabecas foi mudado de 255 para 16 e o numero de cilindros foi aumentado para compensar. Desde que os valores sejam grandes , tudo deve estar OK. Somente os pedantes devem se preocupar em mudar o numero de cilindros manualmente. Se voce nao sabe o valor antes da alteracao , eh melhor nao mexer nesse parametro.

Usando-se esse metodo nao eh necessairo , e voce nao deve , rodar um programa que apaga a mbr (como fdisk /mbr , no DOS). Fazendo isso, voce vai perder o ponteiro pra o Grub instalado na MBR e voce vai ter que usar o cd rescue para recuperar o acesso ao seu Fedora Core.

Atualizar o grub depois da instalacao parece nao ter efeito na geometria do drive , pois o problema parece estritamente limitado ao instalador do Fedora Core.

Boa sorte e una-se a nos no IRC no canal #fedora no irc.freenode.net para quaisques duvidas ou contribuicoes que voce queira fazer.


» Filipe Nazaro () em 15/10 08:56

Olá caras,
Tive o mesmo probelma e encontrei este link. É um manual completo sobre o bug. Muito bom! http://www.canoanet.com.br/modules.php?name=News&file=article&sid=4


» Helio M Y Jr () em 24/10 10:46

Olá Pessoal. Tive o mesmo problema acima, mas para mim essa solução da forma que está não funcionou. No desespero fui procurando e quando já quase estava desistindo achei uma pequena variação no comando citado acima que resolveu meu problema. A idéia é trocar o -H255 por -H240. Não entendi bem o porquê disso, mas sei que funcionou perfeitamente. Espero que ajude a outros também. Abraços!


Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.



O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação, layout, tabela de caracteres, etc.) o acervo de notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter de acervo, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.