O seu resumo do BootInfo parece OK, com a ressalva de que parece ter sido gerado a partir de uma inicialização no modo legado BIOS / CSM / e, portanto, não fornece informações sobre as variáveis de inicialização EFI. Além disso, há um carregador de inicialização no modo BIOS instalado em /dev/sda
, mas isso não deve interferir na inicialização do modo EFI. Também é possível que eu tenha perdido alguns detalhes críticos de diagnóstico. Aqui está como eu recomendo que você proceda:
- Faça o download de uma unidade flash USB ou imagem de CD-R do meu gerenciador de inicialização do rEFInd.
- Prepare um meio de inicialização a partir do download do rEFInd.
- Reinicie para o rEFInd. Ele deve fornecer opções para inicializar o Windows ou o Fedora. Teste ambas as opções.
- Se ambas as opções funcionarem, inicialize no Fedora.
- Neste ponto, você tem várias opções para o que fazer (não necessariamente mutuamente exclusivas):
- Você pode abrir um Terminal, digitar
su
para se tornarroot
, digitarefibootmgr -v
e postar a saída aqui (edite sua pergunta para adicionar a saída) para mais análises. Isso é puramente diagnóstico. - Você pode continuar usando o rEFInd na mídia removível para inicializar. É provável que isso seja estranho, mas deve funcionar.
- Você pode instalar o rEFInd RPM. Ele deve então assumir como o carregador de inicialização principal e seu problema deve ser resolvido. Uma ressalva: o que impediu sua instalação de inicializar normalmente logo após você ter instalado o Fedora também pode afetar o rEFInd, caso em que a saída
efibootmgr
pode ser útil. - Você pode tentar reparar a entrada de inicialização do GRUB. Uma maneira cega e bruta de fazer isso é reinstalar o grub (
grub-install
asroot
); mas isto parece ter sido feito como parte da instalação do Fedora, por isso não acredito que funcionaria melhor neste momento. Reparar a lista de inicialização examinando a saídaefibootmgr
e, em seguida, emitindo comandos específicos do sistema com base nesse conhecimento pode funcionar. - Exclua o carregador de boot no modo BIOS de
/dev/sda
digitando (comoroot
)dd if=/dev/zero of=/dev/sda bs=440 count=1
. Note que este comando é potencialmente muito perigoso se você digitar algo errado. Em particular, certifique-se de que as opçõesbs=440
ecount=1
estejam corretas; se você escrever muitos dados, você danificará a tabela de partições e, potencialmente, além dela! O objetivo desta ação é remover um caminho de inicialização no modo BIOS que possa estar interferindo na inicialização do modo EFI. Essa interferência não deve acontecer, mas não há uma padronização real em como os computadores decidem se devem inicializar no modo BIOS vs. no modo EFI, portanto, há uma chance de que esse código de inicialização no modo BIOS esteja causando problemas.
- Você pode abrir um Terminal, digitar
Em alguns casos, pode ser necessário ajustar suas configurações de firmware ou ajustar os locais e nomes de arquivos do carregador de inicialização. Em particular, seu firmware pode estar configurado para inicializar no modo BIOS / CSM / legado, o que explicaria por que ele não está sendo inicializado agora; ou as entradas de inicialização (armazenadas na NVRAM) podem ficar irremediavelmente confusas, exigindo a restauração de todas as configurações de firmware para seus padrões.
EDITAR:
O menu do rEFInd, desprovido de entradas de inicialização do SO, indica que o rEFInd não consegue localizar nenhum carregador de inicialização, o que contradiz as informações de resumo do BootInfo, que mostram carregadores de inicialização em locais que o rEFInd deve detectar em /dev/sda1
( veja perto do topo da saída). A explicação mais provável é o dano no sistema de arquivos - algumas EFIs são muito mais sensíveis a isso do que a maioria dos sistemas operacionais. Essa situação "danificado-mas-não-danificado" pode surgir devido a uma falha ao desativar os recursos de Inicialização Rápida e Hibernação do Windows, conforme descrito aqui e aqui, respectivamente. Se você conseguir fazer o boot do Windows, sugiro que você desative ambos os recursos e tente novamente. Você também pode tentar executar CHKDSK
no ESP do Windows ou dosfsck
em um disco de emergência do Linux. Na pior das hipóteses, o backup do ESP, a criação de um novo sistema de arquivos e a restauração de seus arquivos podem funcionar para reparar danos sutis no sistema de arquivos. Isso exigirá a correspondência do número de série do sistema de arquivos ("UUID" no Linux, embora não seja realmente um UUID) ao que é agora ou a atualização de /etc/fstab
para substituir o antigo número de série por um novo. (Você pode encontrar o novo UUID via blkid
, como em blkid /dev/sda1
as root
.)