Primeiramente: Sou o autor do fdisk da GPT ( gdisk , sgdisk e cgdisk ), então entendo muito bem as estruturas de dados da GPT.
Se o Windows estiver sendo inicializado no modo BIOS, ele deve estar inicializando a partir de um disco MBR. Se você tem apenas um disco, então parece que o Windows está inicializando no modo EFI, já que seu disco usa o GPT. (Uma advertência: Se a sua tabela de partições estiver muito danificada - digamos, com um MBR híbrido que gdisk não está reconhecendo por algum motivo - pode ser uma instalação no modo BIOS.) Eu mencionei isso porque você disse você executou uma instalação no modo EFI "porque [você] não pôde instalá-lo no modo Legacy". A regra número 1 de multi-boot nestes dias é instalar ambos os sistemas operacionais no mesmo modo. Em outras palavras, se a instalação do Windows estiver no modo EFI, instalar o Ubuntu no BIOS / CSM / legacy mode é algo que você deve NÃO estar fazendo. Isso pode ser um pouco complicado, já que parece que você fez a coisa certa, mas eu quero ser claro sobre isso, porque há muitos procedimentos ruins por aí que sugerem a instalação no modo BIOS / CSM / legado quando que deveria não ser feito. Eu especialmente quero ter certeza de que você não tente instalar o BIOS / CSM / modo legado para corrigir seu problema atual. Ausente informação de que você realmente tem uma instalação do Windows no modo BIOS, reinstalar o Ubuntu no modo BIOS não faria nada além de criar novos problemas sobre os que você tem agora.
Agora, para o seu principal problema: Eu já ouvi falar desse tipo de coisa acontecendo - isto é, gdisk relata uma tabela de partição de backup danificada, o usuário a conserta e ela fica danificada novamente. A causa usual é que algo está sobrescrevendo a tabela de partições de backup. Às vezes isso é um software RAID. O RAID de software baseado em placa-mãe (geralmente chamado de "falso RAID") pode fazer isso porque alguns desses sistemas usam espaço no final do disco (para onde vão os dados de backup da GPT) para armazenar seus dados. Se você tem apenas um disco, você não precisa de RAID, então você deve desabilitar suas configurações de RAID em seu firmware e em todos seus sistemas operacionais. A reinicialização com e sem a inicialização no Windows pode ajudá-lo a descobrir o que está causando o dano e, portanto, o que você precisa ajustar. OTOH, se você tem vários discos e eles estão sendo usados em uma configuração RAID, então você precisa ativar o suporte a RAID no Ubuntu. Isso é coberto em muitos lugares; aqui parece um ponto de partida tão bom quanto qualquer outro, embora eu não o tenha lido completamente.
Esses problemas também podem ocorrer devido a ferramentas de recursos avançados, como criptografia de disco ou software de compactação de disco. Tais ferramentas, por vezes, despejam coisas no final do disco, assumindo que não é utilizado. (Sob o MBR, o espaço após a partição final muitas vezes é desperdiçado, portanto esta abordagem geralmente funciona. Não é seguro, mas geralmente funciona.) Se você tiver essas ferramentas instaladas, remova-as ou, pelo menos, pesquise-as para descobrir se eles forem compatíveis com a GPT e atualizá-los ou substituí-los se não forem compatíveis com a GPT.
Se essas sugestões não ajudarem, tente extrair os últimos setores do disco para um arquivo com dd . Primeiro, você precisa descobrir o tamanho do disco em setores ( gdisk dirá isso) e usar dd , como em:
sudo dd if=/dev/sda of=foo.img bs=512 skip=100021518
Este comando copia o conteúdo do disco, começando em 100021518, para o arquivo foo.img . Você desejará definir seu valor de skip= para pelo menos 34 menos que o número de setores em seu disco, já que o GPT normalmente usa os últimos 33 setores. Você pode examinar o arquivo resultante com hexdump ou algo semelhante, como em:
hexdump -C foo.img | less
A ideia aqui é procurar por strings ou outras pistas que possam lhe dizer o que está causando os problemas. Claro, você deve olhar para o final do disco antes de repará-lo. Os 33 setores finais devem ser suficientes, já que é tudo que gdisk usa.