On Mon, 2005-11-21 at 01:42 -0200, Marcos Vinicius Lazarini wrote: > >> > >>Bom, se copiar o disco todo não resolveu, você tentou criar as partições e > >>copiar apenas o seu conteúdo? tipo hda1 -> hdc1; hda2 -> hdc2; etc > > > > > > Sim, com a tabela de particoes identicas, o hda1 (primaria!)(fat32) para > > hdc1 as vezes funcionava, outras dava aleatoriamente espaco insuficiente > > no meu conjunto de tentativas. Do hda5 em diante todas retornavam espaco > > insuficiente apesar de terem as mesmas geometrias.. > > Muito estranho isso... > tentou fazer as particoes destino ligeiramente maiores? tudo bem, no final > vai faltar, mas seria interessante descobrir se a diferença é pequena ou > grande... > Tipo, se tiver que fazer uma partição 30% maior pra não dar espaco > insuficiente, claramente alguma coisa está muito errada.
Lembro de ter criado uma particao alguns blocos maior, uns 3 ou 4 e mesmo assim retornava espaco insuficiente ao escrever os dados dentro desta particao. > >>Outra coisa, talvez o comando/pacote dd_rescue possa ajudar nos testes... > > > > Verifiquei o dd_rescue mas nao cheguei a utiliza-lo, nada me motivou a > > tentar ele. Nao apresenta diferencas significativas pro dd para o tipo > > de utilizacao que tentei. > > Vc não viu nada de útil nele pq não o rodou. Ele mostra o progresso da > operação. Daria pra vc saber em que ponto ele parou. Além disso ele tem > outros modos de operação (modo reverso por exemplo). A documentação não é > aquelas coisas, mas um 'dd_rescue --help' ajuda. > Meu, o negócio está apenas a um apt-get de distância, não tenha preguiça de > usá-lo... :-) Na verdade, eu li as man pages dele e achei que nao era worthwhile.. Na verdade, trabalhando com dados que eu nao possuia backup, eu estava muito cauteloso ao "brincar" com o dd, e alem disso, devido a nao ter backup, a maquina estar 24hs up e a a companhia de energia eletrica nao ser nossa amiga, eu estava com pressa de gerar um backup.. > > A minha tabela de particoes, para verificacao de problemas de geometria, > > segue abaixo: > > > > # fdisk -l /dev/hda > > > > Disk /dev/hda: 122.9 GB, 122942324736 bytes > > 255 heads, 63 sectors/track, 14946 cylinders > > Units = cylinders of 16065 * 512 = 8225280 bytes > > > > Device Boot Start End Blocks Id System > > /dev/hda1 1 43 345366 b W95 FAT32 > > /dev/hda2 44 14946 119708347+ 5 Extended > > /dev/hda5 44 49 48163+ 83 Linux > > /dev/hda6 50 73 192748+ 83 Linux > > /dev/hda7 74 3112 24410736 83 Linux > > /dev/hda8 3113 4085 7815591 83 Linux > > /dev/hda9 4086 4207 979933+ 83 Linux > > /dev/hda10 4208 4231 192748+ 83 Linux > > /dev/hda11 4232 4365 1076323+ 82 Linux swap / > > Solaris > > /dev/hda12 4366 14946 84991851 83 Linux > > > > O fato de eu conseguir copiar a hda1 pode ser devido a ela estar abaixo > > do cilindro 1024 e ter diretamente a ver com a questao de LBA.. > > Nao sei mais o que pensar sobre isto.. > > O hda1 tbm é a unica partição primária... e a única não linux. Não poderia > ter algo a ver? O fato nao linux acho que nao tem a ver pq eu estava escrevendo a principio hda -> hdc.. O que podereia estar acontecendo eh uma falha na escrita da partition table na parte que define a particao estendida e entao todas as particoes logicas dentro dela poderiam ficar com problemas.. Mas analisando bem, com o dd hda -> hdc, eu consegui obter um resultado onde o hdc5 hdc6 estavam com as mesmas geometrias do hda5 e hda6 e estes nao funcionavam mesmo assim.. Serah que o "fdisk -l" lia uma coisa e o conteudo do disco era outro? Lembro de ter tentado usar o "cmp" (compare) sem chegar a nenhum resultado claro .. Penso que pode existir alguma relacao do problema do cilindro 1024 com o dd.. Algum problema nas conversoes do lba, alguma coisa assim.. O ruim eh que fazer cada teste com 120GB levava em torno de 3hs, e meus dados eram vitais.. -- [] JA Tavares -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]