Muitos de seus problemas parecem se resumir a problemas com sua Partição do sistema EFI (ESP) , que no seu caso é (ou deveria ser) /dev/sda4 . O problema é que o script de Reparo de Inicialização (mis? -) identificou /dev/sda4 como mantendo o arquivo core.img do GRUB. OTOH, está marcado na tabela de partições como sendo um ESP. Minha suspeita é que uma das duas coisas aconteceu:
- Ao instalar o Windows,
/dev/sda4foi usado como o ESP, mas a localização da partição coincidiu com a localização de uma Partição de inicialização do BIOS , que contém o código GRUB 2 para inicializações no modo BIOS. Se o Windows não apagasse adequadamente esses dados antigos, isso poderia fazer com que o sistema de arquivos fosse identificado erroneamente por algumas ferramentas do Linux, o que resultaria no problema que você está enfrentando agora. - Em algum momento após a instalação do Windows, você ou um utilitário de reparo erroneamente gravou os dados do GRUB "brutos" em
/dev/sda4. O comandogrub-installem uma inicialização no modo legado do BIOS / CSM / pode fazer isso, mas normalmente apenas se a partição foi marcada como uma Partição de inicialização do BIOS, o que atualmente não é. No entanto, esta é uma possibilidade se os dados do GRUB foram escritos aqui de alguma outra forma ou se o código de tipo da partição foi alterado para o de um ESP após o errogrub-install.
A primeira dessas explicações é aquela que você deve esperar, pois significa que os dados do sistema de arquivos FAT devem estar intactos. Neste caso, o primeiro passo para a recuperação é fazer backup da partição (talvez seja necessário especificar explicitamente seu tipo de sistema de arquivos para montá-lo no Ubuntu, como em sudo mount /dev/sda4 -t vfat /mnt ), desmontá-lo, criar um novo sistema de arquivos FAT ( sudo mkdosfs /dev/sda4 ), montá-lo novamente e restaurar os arquivos de backup. Isso deve habilitar o Reparo de Inicialização para funcionar. Note que você pode fazer tudo isso em praticamente qualquer sistema operacional, embora você tenha que montar o ESP primeiro se fizer isso no Windows (veja abaixo).
Outro caminho para a recuperação seria usar meu gerenciador de reinicialização em uma unidade flash USB ou CD-R . Se o sistema de arquivos do ESP for legível para o firmware, o rEFInd deverá permitir que você inicialize o Windows ou o Ubuntu. Você poderia então criar uma entrada /etc/fstab para montar /dev/sda4 at /boot/efi e instalar o rEFInd através de seu pacote Debian ou PPA. (Como alternativa, você pode instalar o pacote grub-efi e configurá-lo você mesmo.) Por si só, essa abordagem ainda deixará dados confusos no ESP, portanto, ferramentas como o Boot Repair continuarão a ser menos úteis; para totalmente recuperar, você precisaria fazer o backup do ESP, criar um novo sistema de arquivos e restaurá-lo. Por falar nisso, não tenho certeza se o script de instalação do rEFInd (usado nos pacotes) funcionaria corretamente devido à identificação errônea do sistema de arquivos, então talvez seja necessário corrigir o problema mesmo com essa solução.
Se o sistema de arquivos em /dev/sda4 estiver tão danificado que você não possa recuperar seus arquivos, você precisará criar um novo sistema de arquivos, usar um disco de recuperação do Windows para reinstalar o gerenciador de inicialização do Windows e em seguida, recupere o Ubuntu para a inicialização usando o Boot Repair ou o rEFInd.
Note que é possível que o sistema de arquivos seja legível em um ou dois ambientes, mas não em todos os três. (Os três ambientes são EFI, Windows e Ubuntu.) O Windows normalmente não monta o ESP, portanto, é necessário digitar mountvol S: /S em uma janela Prompt de Comando do Administrador. (Você pode alterar S: para algum outro identificador de unidade, se quiser.) É claro que sua saída do Boot Repair já revela que algumas ferramentas do Linux (como blkid ) não vêem um sistema de arquivos FAT no disco, mas Ainda poderia ser legível pelo kernel se você dissesse para usar o driver vfat , como no comando mount /dev/sda4 -t vfat /mnt que apresentei anteriormente.