Marcos FRM

Se você não quer colocar os sistemas operacionais em UEFI, que é um processo maçante, não difícil, então atualize para a última FGa. O risco é mínimo, diria inexistente com o DualBIOS. Daí você tira a dúvida!!!

Acho difícil a atualização resolver seu problema. A Gigabyte deve ter atualizado apenas o AGESA (microcódigo da AMD) para suportar o CPUs com núcleo Godavari. Não tem mistério nenhum. Crie o pendrive de instalação do Windows 7 com o Rufus, selecionando "Esquema de partição -> GPT" (o que selecionará "Sistema de destino -> UEFI (não CSM)". O 7 ainda requer CSM ativo para funcionar, mesmo em UEFI -- essa restrição não existe a partir do Windows 8. Sua placa apenas permite desativar o CSM ("CSM Support") se "OS Type" estiver em "Windows 8" ao invés de "Other OS". Ou seja, mantendo "OS Type" em "Other OS" garante CSM ativo mesmo com "Boot Mode Selection" e "Storage Boot Option Control" em "UEFI Only" (que evita inicializar por engano em Legacy/CSM). Depois de salvar suas coisas noutro lugar, inicie com a mídia do Windows. No menu F12 da placa-mãe, deverá aparecer o prefixo "UEFI:". Carregado o instalador, depois da tela de seleção do layout do teclado, pressione Shift+F10. No prompt de comando que abrir, digite o seguinte, pressionando Enter ao final de cada linha: diskpart list disk select disk X detail disk clean exit Substitua X pelo número do disco que deseja limpar, que é listado por list disk (coluna "Nº Disco"). detail disk mostrará o modelo para ter certeza. Tudo que estiver nesse disco será apagado. Preste atenção! Feche o prompt de comando e prossiga com a instalação. Quando chegar na parte para escolher onde instalar, como fará dual boot, crie uma partição pequena (a seu gosto) para o Windows (que ficará no início do disco) e instale nela. Nisso, o próprio instalador criará automaticamente estruturas GPT, pois a mídia foi inicializada em UEFI. O resto do espaço deixe como não alocado, sem criar nenhuma partição adicional. Por baixo do capô, o instalador criará as partições EFI e MSR. Não precisa criá-las manualmente. Isso completa a parte do Windows. Nas instalações dos Linuxes, vá usando o espaço não alocado depois da partição do Windows. O único cuidado é que você precisará aproveitar, em todos eles, a partição EFI criada pelo Windows, como comentado aqui: Note que partição "primária", "estendida", "unidade lógica", são características do particionamento MBR apenas. Em GPT, não tem essa diferenciação.

Essa placa tem dois chips de BIOS ("DualBIOS"), um é sempre backup. Tente a FGa de uma vez.

É placa chinesa sem marca? Lembro de um tópico aqui no fórum sobre uma placa dessas em que a conclusão foi que o fabricante não implementou o recurso. Tinha UEFI, mas nada de secure boot.

Sim. BIOS UEFI são pequenos sistemas operacionais. Eles já entendem AHCI, NVMe, USB Mass Storage, FAT... Hoje, acho que todas as placas da ASUS vêm com suporte ao NTFS. Parece que a MSI também tem algum suporte, não sei se tão amplo.

Pode sim. Se apareceu lá, pode fazer.

É que não tem mais nada para editar ali. Foto de capa e foto de perfil, o que restou para editar eu acho, têm suas próprias opções para tal. Esse botão "editar perfil" provavelmente possa ser removido...

Para enfrentar o malware BlackLotus, acontecerá, no início do ano que vem (previsão é janeiro de 2024), uma revogação em massa de bootloaders comprometidos do Windows. https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d https://uefi.org/sites/default/files/resources/dbx_release_info.pdf • Boot Managers from Windows 8 to Windows 10, version 1507: revoked by DBX entries • Boot Managers from Windows 10, version 1507 to Windows 10, version 1607: revoked by hash by SKU SiPolicy • Boot Managers from Windows 10, version 1703 to today: revoked by version number by SKU SiPolicy A tal Code Integrity Boot Policy (SKUSiPolicy.p7b) funciona mais ou menos como o Secure Boot Advanced Targeting (SBAT) do Shim: https://github.com/rhboot/shim/blob/main/SBAT.md Aqui tem uma longa discussão sobre os detalhes técnicos: https://github.com/pbatard/rufus/issues/2244 Pelo que entendi, se o arquivo SKUSiPolicy.p7b estiver presente, na partição EFI, ao lado do bootmgfw.efi em EFI\Microsoft\Boot, o bootmgfw (desde o 10 1507) criará duas variáveis "Boot Services" (SkuSiPolicyUpdateSigners e SkuSiPolicyVersion), que desaparecem quando o kernel chama ExitBootServices(). Ou seja, podem ser manipuladas apenas no ambiente pré-sistema operacional. A presença dessas variáveis faz com que o bootmgfw bloqueie a si próprio caso esteja listado em SKUSiPolicy.p7b. Caso o arquivo SKUSiPolicy.p7b seja removido, bootmgfw abortará a inicialização[*]. Não está claro para mim se a criação das variáveis é automática estando o arquivo presente ou se algo mais é necessário. [*] Exceto que há bugs no bootmgfw entre as versões 10 1903 e 10 20H2, que permitem-no iniciar mesmo com as variáveis presentes e SKUSiPolicy.p7b ausente. O Windows Update, no ano que vem, colocará o arquivo SKUSiPolicy.p7b na partição EFI para ativar essa parte, talvez fazendo algo mais para criar as tais variáveis e efetivamente ativar o bloqueio. A segunda parte é o bloqueio no BIOS UEFI. DBX será atualizado pelo Windows ou pelos fabricantes de hardware com atualizações de BIOS... quem chegar primeiro. Aplica-se a máquinas em UEFI com Secure Boot ativo. Com Secure Boot desativado ou instalações Legacy/CSM, não tem impacto. Para sistemas já instalados, supõe-se que o Windows Update fará o que precisa ser feito automaticamente. No momento em que as revogações forem aplicadas, apenas ISOs atualizados do Windows 10 e 11 iniciarão: no mínimo versões de maio de 2023. Neste momento, são disponibilizados oficialmente pela Microsoft em https://www.microsoft.com/pt-br/software-download os seguintes arquivos (com nomes diferentes): pt-br_windows_10_consumer_editions_version_22h2_updated_may_2023_x64_dvd_5995e9f3.iso pt-br_windows_10_consumer_editions_version_22h2_updated_may_2023_x86_dvd_6af9700e.iso pt-br_windows_11_consumer_editions_version_22h2_updated_may_2023_x64_dvd_2bfcd786.iso Assim não seremos pegos de surpresa!

Irrelevante. Ele carrega ambos, "part_gpt" e "part_msdos" (MBR). Como o disco está em MBR, o primeiro não é usado.

Pelo contrário. No Windows, depois de instalado, precisa mexer no registro antes de mudar; é uma alteração simples. [*] No Linux, em geral não precisa fazer nada, pois o driver ahci.ko é tão importante que as distribuições ou compilam embutido dentro da imagem do kernel (Arch, Fedora) ou adicionam o módulo incondicionalmente ao initramfs (Debian, cuja configuração do mkinitramfs é MODULES=most). Ou seja, pode mudar que será indolor. AHCI tem a vantagem de ativar algumas coisas que o carcomido modo IDE não fornece, como NCQ, ALPM. Esqueça essa entradas. Todo BIOS UEFI gera esse tipo de coisa. Uns mais, outros menos. Não tem importância. [*] [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci] (Windows Vista/7) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\storahci] (Windows 8 e superiores) Em "Start", altere o valor para 0 (zero).

Então antes de tudo, dentro do BigLinux, reinstale o código no MBR: grub-install /dev/sda Assim tem certeza que boot.img e core.img estão sincronizados com os módulos de /boot/grub. AHCI é o modo recomendado. A especificação foi desenvolvida pela Intel e adotada por toda a indústria. Tem algumas sugestões aqui: https://unix.stackexchange.com/questions/72625/why-is-usb-not-working-in-linux-when-it-works-in-uefi-BIOS

Qual a diferença entre "Boot Option #1" e "#2"? Em qual partição o "stage 2" do GRUB está? Na /dev/sda5, a partição ativa do disco? (onde /boot/grub/grub.cfg usado por ele está)

efibootmgr não mexe no disco. Não tem risco de apagar nada.

Acredito que o BIOS tente achar o tal binário, não ache, desista e passe para a próxima entrada, que possivelmente seja o bootloader não-UEFI do MBR do disco. Remova a tal entrada, afinal o binário por ela referenciado não existe. Acho que não. Não conheço o Ventoy em detalhes.

Isso só teria importância caso existisse uma partição EFI no disco. Se você iniciar através da opção "antergos_grub" no menu F12 acontece o quê?

Não gosto do Ventoy pois ele quebra Secure Boot em UEFI: a mídia deixa de ser compatível, a menos que adicione-se um certificado (ou hash nas versões recentes, parece: link1, link2) no MOK -- o que eu nunca farei. Para mim, o melhor programa para a tarefa é o Rufus, mas tem um escopo diferente: apenas uma mídia por dispositivo. "Bricar" é improvável. Não tem nada no protocolo USB Mass Storage que permita a um aplicativo fazer um estrago assim. Não tem ligação. Usa-se para swap: https://docs.kernel.org/admin-guide/blockdev/zram.html

O tipo de partição é a coluna "Id" da saída do fdisk: apareceria "ef" ali, sem o prefixo "0x". Então, não. Não tem partição EFI em /dev/sda. O pendrive (/dev/sdb) ter uma partição EFI não importa. Programas como o Ventoy fazem uma bruxaria danada... o Rufus, em algumas circunstâncias, cria uma partição EFI no pendrive. Sim. Sem partição EFI em /dev/sda, essa entrada é inútil. Ainda mais a árvore de diretórios "EFI/antergos_grub/" não existindo no sistema de arquivos de nenhuma partição -- repetindo, teria que ser numa partição do tipo "ef". "antergos_grub" é a entrada 0 (zero). Portanto: efibootmgr -b 0 -B As demais entradas são geradas automaticamente pelo BIOS e não devem ser removidas, inclusive a 7, do pendrive usado para iniciar. Curioso que "antergos_grub" aponta para /dev/sda mesmo; veja a assinatura de disco (0x1835), que o fdisk chama de "identificador de disco". Não causa problema. Se não me engano, é indolor corrigir. As ferramentas *fdisk possuem recurso para isso (o cfdisk é mais amigável). Não mexe no disco.

Hmmm, geralmente BIOS UEFI descartam variáveis UEFI cujo binário não exista. Para essa variável aparecer, existe uma boa possibilidade de você ter uma partição EFI no disco. Note que partição EFI pode existir no particionamento MBR também; o identificador é 0xEF.

Para a última disponível que não seja Beta, seguindo o @1lokos . Leia a lista de mudanças, pois às vezes existem versões de transição que precisam ser atualizadas antes de ir para última. Se não mencionar nada relativo a isso lá, pode atualizar para última direto e ser feliz.

BIOS UEFI está no modo híbrido, suportando ambos os tipos de sistemas: CSM e UEFI. O "antergos_grub" é uma variável de inicialização UEFI, que foi gravada com a mídia de instalação em questão tendo sido iniciada nesse modo. Você remove-a com: efibootmgr efibootmgr -b X -B Tem que substituir "X" do segundo comando pelo número retornado no primeiro em BootXXX relativo à linha que tiver "antergos_grub". Ambos os comandos apenas funcionarão com um Linux iniciado em UEFI. Não sei se tem algum aí. Ao usar mídia removível, no menu de inicialização via F12, suas entradas são prefixadas com "UEFI:" para diferenciar. Já testou "Boot Mode Selection" em "Legacy Only" e "Storage Boot Option Control" em "Legacy Only"? Isso mais ou menos desativa as funções UEFI.

Sim... mas, pelas fotos, o pendrive tem o FreeDOS, não a mídia de instalação do Windows. Usou o Rufus? Caso sim, precisa fornecer o ISO para ele, clicando em "Selecionar". Para máquinas que vieram com Windows 7 de fábrica, precisa configurar "Sistema de destino" com "BIOS (ou UEFI-CSM)".

Em princípio, você não detonou /dev/sda2 e /dev/sdb2, o que é bom sinal. Rode: lsblk -fp fdisk -l

O preço do Adata SU650 está muito bom de uns tempos para cá. Andei instalando alguns para reviver notebooks antigos. Até agora, não incomodaram. Tem tópicos aqui no fórum comentando sobre ele, com recomendações positivas.

Você precisa de um Linux "live" qualquer, que rode do pendrive, que tenha esse comando. Tente com o https://www.system-rescue.org/ . Dentro do Linux carregado pelo pendrive.

As duas partições EFI (de ~1 GB) devem estar ok, pois o sistema chega a iniciar. Ou seja, o bootloader carrega kernel e initramfs pelo menos. O que estes comandos retornam? mdadm --examine /dev/sda2 mdadm --examine /dev/sdb2 mdadm --detail --scan cat /proc/mdstat Se estiver como usuário normal, tem que adicionar "sudo" (sem apas) antes de cada comando.