Como evitar que o Windows perca o GPT secundário durante a inicialização?

Como evitar que o Windows perca o GPT secundário durante a inicialização?

Minha área de trabalho tem um (e apenas) disco rígido de 3 TB com 5 partições: 1. EFI, 2. Windows 7 SP1 (64 bits), 3. partição HP Factory Recovery, 4. um NTFS para armazenamento de dados e 5. Ubuntu 18.04 .2 (64 bits). GRUB (v.2.02) é o gerenciador de inicialização.

Contanto que eu inicialize no Windows 7, sempre recebo um aviso de "tabela de partição secundária sobrepondo a última partição em 4.294.966.385 blocos" e o último setor utilizável é redefinido para 1.565.565.838 (que precede o último setor 5.860.533.168 do disco rígido muito cedo ). O mesmo aviso continua voltando, quer eu tenha deixado o Windows 7 consertar ou consertado pelo gparted no Ubuntu.

As perguntas que peço para sua gentil ajuda são duas:

  1. Existe alguma solução ou maneira de evitar que o Windows 7 redefina incorretamente o GPT secundário durante o processo de carregamento do Windows?

  2. O posicionamento incorreto do GPT secundário faz com que alguns dos meus arquivos tenham agora zero bytes no tamanho do arquivo. Existe uma maneira de restaurar esses arquivos, já que o conteúdo deles ainda está lá?

Abaixo estão as mensagens de erro detalhadas:

(1. Fase Ubuntu)
Digamos que o último sistema operacional inicializado seja o Ubuntu, e o Gparted e o Gdisk não detectam nenhum erro de partição.

(2. Fase do Windows)
Reinicializar. Durante o carregamento do Windows 7 e antes de mostrar a área de trabalho do Windows, aparece:

Checking file system on E:
The type of the file system is NTFS.
Volume label is NTFS_DATA

One of your disks needs to be checked for consistency. You 
may cancel the disk check, but it is strongly recommended 
that you continue. To skip disk checking, press any key...

Continuo e termino a verificação de disco recomendada. Depois de entrar no Windows, executo o CHKDSK.exe para verificar os discos novamente e não recebo nenhum relatório de erro. (A propósito, encontrei alguns arquivos agora com zero bytes no tamanho do arquivo como resultado da verificação do disco durante a fase de carregamento do Windows.)

Abro o Gerenciamento de Disco do Windows. Ele pode reconhecer corretamente a capacidade total do disco rígido como 2.794,52 GB. Ele também pode reconhecer todas as partições, exceto a última (porque a última é ext4).

No entanto, executo gdisk64.exe (a versão do Windows de 64 bits do fdisk GPT) e ele sinaliza um aviso:

c:\gdisk>gdisk64 -l 0:
GPT fdisk (gdisk) version 1.0.4

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Warning! Secondary partition table overlaps the last partition by
4294966385 blocks!
You will need to delete this partition or resize it in another utility.
Disk 0:: 1565565872 sectors, 746.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1565565838
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI system partition
   2          206848      1925441535   918.0 GiB   0700  
   3      1925441536      1953521663   13.4 GiB    0700  
   4      1953523712      5650817023   1.7 TiB     0700  
   5      5650817024      5860532223   100.0 GiB   8300  

Desliguei o PC e inicializei no Windows 7 novamente. Ele não solicita a mesma verificação de disco mencionada acima durante o carregamento do Windows. Depois de entrar no Windows, abro o Gerenciamento de Disco do Windows, ele ainda consegue reconhecer corretamente a capacidade total do disco rígido e das partições. No entanto, gdisk64.exe ainda relata o mesmo aviso para a tabela de partição secundária sobrepondo a última partição em 4.294.966.385 blocos, e o último setor utilizável é 1.565.565.838, que precede o setor final da última partição (5.860.532.223) muito cedo.

(3. Fase Ubuntu)
Reinicialize. No Ubuntu 18.04.2, abro gdisk e fdisk no Terminal. Eles confirmam que o mesmo problema existe:

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Warning! Secondary partition table overlaps the last partition by
4294966385 blocks!
Try reducing the partition table size by 17179865540 entries.
(Use the 's' item on the experts' menu.)
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Model: TOSHIBA DT01ACA3
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1565565838
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI system partition
   2          206848      1925441535   918.0 GiB   0700  
   3      1925441536      1953521663   13.4 GiB    0700  
   4      1953523712      5650817023   1.7 TiB     0700  
   5      5650817024      5860532223   100.0 GiB   8300  


$ sudo fdisk -l /dev/sda
Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Device          Start        End    Sectors  Size Type
/dev/sda1        2048     206847     204800  100M EFI System
/dev/sda2      206848 1925441535 1925234688  918G Microsoft basic data
/dev/sda3  1925441536 1953521663   28080128 13.4G Microsoft basic data
/dev/sda4  1953523712 5650817023 3697293312  1.7T Microsoft basic data
/dev/sda5  5650817024 5860532223  209715200  100G Linux filesystem

Abro o gparted e aparece uma mensagem de aviso:

Not all of the space available to /dev/sda appears to be 
used, you can fix the GPT to use all of the space (an extra 
4294967296 blocks) or continue with the current setting?
[Fix] [Ignore]

Eu escolho deixar o gparted consertar o GPT. Em seguida, executo o gdisk novamente e ele não avisa. O erro foi corrigido e o último setor utilizável é 5.860.533.134:

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Model: TOSHIBA DT01ACA3
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4973 sectors (2.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI system partition
   2          206848      1925441535   918.0 GiB   0700  
   3      1925441536      1953521663   13.4 GiB    0700  
   4      1953523712      5650817023   1.7 TiB     0700  
   5      5650817024      5860532223   100.0 GiB   8300

Eu reinicio o PC e inicializo no Ubuntu novamente. gdisk e gparted não detectam nenhum erro GPT.

(4. Fase do Windows)
Tento então inicializar o Windows 7. O que aconteceu na Fase do Windows mencionada acima acontece novamente. Durante a inicialização do Windows, ele faz uma "Verificação do sistema de arquivos em E:" e solicita uma verificação de consistência do disco. Depois disso, tanto o chkdsk quanto o Gerenciamento de disco mostram resultados normais sem qualquer aviso, mas o gdisk64 ainda relata o mesmo aviso para a tabela de partição secundária sobrepondo a última partição em 4.294.966.385 blocos. O último setor utilizável volta a ser 1.565.565.838 e precede o último setor do disco (5.860.533.168) muito cedo, embora tenha sido corrigido e definido como 5.860.533.134 pelo gparted na última reinicialização (Fase Ubuntu).

Acho que o problema fundamental aqui aparentemente reside no Windows 7 configurando um GPT secundário/de backup no meio do disco rígido, em vez de deixar o backup permanecer após a última partição. Como eu sei, o "último setor utilizável" é onde começa o GPT secundário/de backup. O disco rígido possui 5.860.533.168 setores no total. O último setor utilizável é 5.860.533.134 após a correção do gparted, mas volta a 1.565.565.838 após o processo de carregamento do Windows 7. O fato de meu Windows 7 (SP1, 64 bits) poder reconhecer a capacidade total do disco rígido no Gerenciamento de disco não ajuda por si só evita redefinir o GPT de backup em um lugar errado. Eu sei como redefinir o GPT secundário para onde deveria estar, mas não sei como evitar que meu Windows 7 o perca durante a fase de carregamento do sistema operacional.

Abaixo estão minhas perguntas: O extravio do GPT secundário faz com que alguns dos meus arquivos tenham agora zero bytes no tamanho do arquivo. Existe uma maneira de restaurar esses arquivos, já que o conteúdo deles ainda está lá?

Existe uma maneira de evitar que o Windows 7 redefina incorretamente o GPT secundário durante o processo de carregamento do Windows?

Por favor ajude.

Responder1

5860533168(O Ubuntu vê) é o número real de setores lógicos. Isso precisa de 33 bits e se você tentar armazená-lo em 32 bits, o bit mais significativo será perdido e o número se tornará 1565565872(o Windows o usa).

Parece que o seu Windows (ou algumas partes dele) usa 32 bits onde deveria usar mais. O Windows e o Ubuntu lutam para decidir onde a tabela de partição secundária deve ser colocada. Ubuntu está certo.

De acordo com a Microsoft[ênfase minha]:

A Microsoft investigou como o Windows oferece suporte a esses discos grandes. Os resultados revelam vários problemas que se aplicam a todas as versões do Windows anteriores eincluindo Windows 7 com Service Pack 1e Windows Server 2008 R2 com Service Pack 1.

Até este ponto, sabe-se que o seguinte comportamento incorreto ocorre quando o Windows lida com capacidade de armazenamento de disco único superior a 2 TB:

  • A capacidade numérica além de 2 TB excede. Isso faz com que o sistema seja capaz de lidar apenas com a capacidade além de 2 TB. Por exemplo, num disco de 3 TB, a capacidade disponível pode ser de apenas 1 TB.
  • A capacidade numérica além de 2 TB está truncada. Isso resulta em não mais que 2 TB de espaço endereçável. Por exemplo, num disco de 3 TB, a capacidade disponível pode ser de apenas 2 TB.
  • O dispositivo de armazenamento não foi detectado corretamente. Nesse caso, ele não é exibido nas janelas Gerenciador de Dispositivos ou Gerenciamento de Disco.

Acho que você entrou nessa situação clonando um disco pequeno o suficiente para não causar problemas no Windows 7 SP1. Provavelmente 1 GB (a julgar pela localização da partição HP Factory Recovery que estava no final do disco antigo).

O sistema de arquivos na partição atual do sistema Windows foi corrompido. Pode ser possível reparar suas estruturas, mas você não pode ter certeza de que a corrupção não afetou arquivos importantes. Mesmo que funcione agora, arquivos corrompidos podem causar problemas no futuro.

Atenção: os procedimentos a seguir podem não ser a melhor solução. Nunca experimentei o seu problema, então nunca tentei me recuperar dele. Isso é exatamente o que eu tentaria. Você pode esperar que outras respostas (ou comentários) apareçam.

Se você ainda tiver o disco antigo com dados antigos e estiver disposto a descartar quaisquer alterações feitas na cópia clonada do Windows, proceda da seguinte forma:

  1. Desconecte o novo disco (para evitar conflitos de UUID), conecte o antigo.
  2. Inicialize o Windows antigo.
  3. Instale atualizações para que seu Windows esteja pronto para oferecer suporte total a discos de 3 TB. (EmboraEste artigomenciona "configurações do sistema configuradas incorretamente, entradas irregulares no registro ou tecnologia de armazenamento Intel® Rapid" também podem interferir).
  4. Clone novamente. Eu clonaria apenas a partição antiga do Windows para a partição já existente no disco grande; O Ubuntu permaneceria intacto; A entrada de inicialização GRUB e/ou EFI no disco grande pode precisar ser atualizada para inicializar o Windows corretamente.

Se você não conseguir voltar ao Windows antigo, tente o seguinte:

  1. Se possível, não deixe o Windows gravar a tabela de partição secundária.
  2. Execute chkdskno sistema de arquivos que contém o Windows (geralmente C:\). Não tenho certeza de quão seguro isso é. Observe que há uma parte da partição do Windows que está além do que o Windows considera ser o último setor, portanto a ferramenta pode ou não funcionar corretamente. Conectando o disco aoutro(totalmente atualizado) Windows e rodar chkdsklá pode ser mais seguro (mas se você quiser usar um gabinete USB para essa finalidade, lembre-sealguns gabinetes podem causar problemas).
  3. Instale atualizações para que seu Windows esteja pronto para oferecer suporte total a discos de 3 TB.

informação relacionada