Shakmatton

Estou de volta pra encerrar o tópico e relatar a solução encontrada. Um dos problemas foi resolvido via efibootmgr (ver solução no post #6). O outro (e principal problema), infelizmente, não foi resolvido. Aparentemente, a capacidade de detecção da placa-mãe usando MBR DualBIOS "morreu". Logo, foi necessário recorrer à reinstalação de todas as partições e sistemas operacionais do zero, usando um "inédito" modo UEFI. Essa outra solução, portanto, envolve formatação geral da máquina (ver solução #29). Ao final de todas as reinstalações, o teclado voltou a funcionar no Grub normalmente. Agradeço ao Marcos e ao Clube do Hardware pela possibilidade de ter conseguido resolver este problema.

Eu baixei o Rufus semana passada, se não me engano. A minha versão é a 4.1.2045 (estou usando-o em um Windows 10 de um notebook emprestado aqui pra mim). Por coincidência, abri ele aqui agora e apareceu uma mensagem de update liberado para download da versão 4.2. Vou baixá-lo para tentar novamente o procedimento de instalação com ele. (A minha insistência com a abordagem "não-Rufus" é devido a eu já ter tentado o procedimento com ele anteriormente, testando a instalação do pendrive primeiramente em máquinas virtuais. Porém, tanto no VBox como no Boxes a instalação ou não dava certo ou dava erro de driver "faltante" (perdi um bom tempo assistindo diversos tutoriais que prometiam resolver isso, mas não tive sucesso). Claro, como agora a situação é diferente (terei que formatar a máquina de qualquer forma), e de posse das novas informações (como as do post #29), acho que posso tentar tudo novamente do zero, mas dessa vez, diretamente na máquina real. E, se nada mais der jeito na situação, o jeito seria migrar pro Windows 8.1, que bem ou mal, está mais próximo do Windows 7 e do setup mais antigo da minha máquina.

Opa, só uma atualização aqui de última hora: atualizei a BIOS pra uma versão mais nova, mas acabou que isso não surtiu efeito algum sobre o problema do teclado, que ainda continua travado. Bom, pelo menos valeu a tentativa. Pelo que vejo, a solução é realmente reinstalar tudo do zero, criando um disco em formato UEFI-GPT. Vou me organizar aqui para isso agora.

Entendi. Nas opções de setup da BIOS, deixar marcada a opção "Other OS", para ficar em conformidade com a natureza CSM intrínseca ao Win 7. Já no gravador Rufus, o procedimento é tratar a ISO do Win 7 como se ela fosse gravada no USB como UEFI puro. Embora eu esteja mais inclinado a testar um update de BIOS, ainda sigo acompanhando uma discussão sobre as particularidades da instalação de uma ISO Win 7 x64 para USB. Algumas coisas que estão por lá você até já mencionou (o que me dá mais segurança e tranquilidade, para o caso de tentar o procedimento de instalação sem Rufus). Agora, o que me chamou a atenção ali foram os seguintes pontos: - A possibilidade de usar qualquer versão Win 7 (a que eu uso atualmente é versão MBR do tipo "All-in-One"); - A questão do tamanho do arquivo "\sources\install.wim" (se entendi bem, ela teria que ser dividida em pedaços menores, caso esse arquivo ficasse maior que 4G, excedendo a capacidade do Fat32); e - Um comando do Diskpart chamado "Active" (que dizem que só pode ser usado em discos MBR, ou que a partição se tornaria bootável em um disco MBR, enquanto que em um disco GPT isso não poderia ser feito). Isso significaria simplesmente dar um F12 na tela inicial de BIOS e ver na lista de dispositivos uma entrada "UEFI" e outra "Generic"...?

Obrigado pelo encorajamento! É sempre saudável para um novato quando alguns "tabus" são desmistificados, como o da atualização da BIOS...

Opa, muito obrigado pelo retorno e também pela paciência para descrever o procedimento! Vou responder aqui em partes então. Pois é, eu acabei lendo sobre isso também ontem. Vi que essa tal tecnologia AGESA teria a ver com os tais processadores Ryzen que tá todo mundo falando sobre... isso me fez pensar que um upgrade de BIOS para o meu processador de 2014 realmente não me seria de muita serventia, tal como você falou aí também. Por outro lado, eu fiquei na dúvida se um upgrade não poderia ser uma solução para o caso mesmo assim. ======================== Explico: em junho eu criei um tópico nesse site sobre a possibilidade de uma troca de fonte de energia do cpu, já que ela tinha uns 10 anos, era genérica e já não estava mais ligando direito a máquina (acabei não tirando nenhuma foto na época, mas lembro que, às vezes, quando ligava, aparecia uma mensagem na tela da BIOS falando sobre reset, algo assim... é uma lembrança um pouco mais vaga, mas acho que era algo sobre isso). (Sem mencionar que aqui na cidade onde estou, há uma taxa considerável de quedas de energia. Mesmo com as proteções adequadas, além de usar iClamper e bom senso durante tempestades, não sei até que ponto isso poderia "esculhambar" alguma coisa lá na BIOS da placa-mãe também...) Felizmente, de lá pra cá, pude trocar a fonte por uma nova, e também adquiri uma nova bateria para a placa-mãe. Nesse sentido, tudo funciona perfeitamente. ======================== Mas eu, como leigo, fiquei pensando aqui se tudo o que aconteceu poderia ter mexido com alguma coisa lá na memória/configuração da BIOS... e se porventura um "simples" upgrade de BIOS poderia restabelecer as funções básicas da placa de volta (incluindo aí a habilidade de voltar a detectar as portas USB ou o modo que funciona em conformidade com a tecnologia MBR Legacy). Olha, não sabia disso! Eu até tinha lido/separado para leitura várias postagens na internet sobre instalação do Win 7 em UEFI, mas estranhamente, pouca gente volta lá e diz algo como "Consegui! Basta fazer tal passo X e etc...". Imagino que esse novo detalhe que você mencionou faça a diferença. Vou realizar algumas novas tentativas com algumas máquinas virtuais pra ver o que acontece.

Entendo. Eu percebi que ela funciona normalmente no modo UEFI, com todos os meus OSes sendo detectados (seja em tempo de boot do HD ou direto por algum grub de live ISO ou de Ventoy) e com o teclado funcionando normalmente nele. Por outro lado, o problema do teclado travado só ocorre no modo BIOS MBR Legacy. Porém, o esforço que faço é justamente para tentar reaver a funcionalidade da MBR como antigamente, sem teclado travando. Tudo para poder manter o Win 7 em modo MBR. Do contrário, teria que encarar um processo e tentar uma reinstalação do Win 7 em modo UEFI (e pela internet afora, vejo muito mais gente apanhando com isso do que conseguindo realizar uma instalação no modo UEFI)... Estou pesquisando agora tudo o que posso aqui sobre instalação manual, Q-Flash e termos relacionados ao update de BIOS, mas fiquei bem receoso quando vi aquela BIOS em letras vermelhas. Considerando tudo o que já foi tentado, você acha que, ao contrário do que dizem por aí, realmente não haveria perigo de baixar uma versão "Beta" (com "letras vermelhas ameaçadoras" e tudo)?

Ei Marcos! Desculpe ressucitar esse tópico, mas é que só agora percebi uma coisa sobre a placa-mãe que queria compartilhar aqui, só para desencargo de consciência. Bem, tentei 1 milhão de outras coisas envolvendo grub, instalação de outros OS, inserir e remover pendrive, mas não pude obter uma solução final. Então, quando já estava entregando os pontos pra formatar e instalar tudo do zero, reparei uma coisa: No BIOS da placa-mãe, o "System Information" acusa que a versão é FFa, e a data dela é de 18 de março de 2014. Bom, eu estava dando uma olhada no site da Gigabyte, e vi que me escapou completamente um fato: a última BIOS estável (não-beta) é de 29 de Maio de 2014. Dois meses de diferença, portanto. Não sei se o "a" do "FFa" significaria "alfa", isto é, uma versão anterior à disponível no site deles (a "FF"). Pensei em realizar um salto de fé, baixando e instalando essa nova versão FF de Maio disponível na lista de BIOS... Porém, não vejo a minha atual versão "FFa", de Março, na lista deles. Isso significaria que, qualquer problema que houver com a BIOS nova = Game Over, certo? Ou haveria uma forma de fazer uma cópia de backup da BIOS antiga instalada, para alguma eventualidade de dar problema? Aqui o link da foto com a versão atualmente instalada. E aqui, outro link, mostrando a lista de BIOS disponíveis para download no site da Gigabye.

Ah, entendo. É... vou ver o que eu arrumo aqui então. Se eu conseguir algum progresso, retorno aqui para relatar como consegui resolver. Marcos, muito obrigado pelo apoio, e principalmente, pela paciência em ajudar! Valeu!

Eu fui investigar os 3 arquivos grub.cfg, que encontrei no BigLinux, no Linux Mint e no Elive_OS. Achei curioso que, embora todos sejam mais ou menos parecidos em algum grau, somente o grub.cfg do BigLinux é que possui uma linha chamada "insmod part_gpt". Bom, isso me fez pensar que talvez o problema não estaria na placa-mãe, mas sim em algum (possível) conflito entre as instalações. Não me lembro de ter instalado o BigLinux em modo GPT... será que a resolução da questão passaria simplesmente por uma formatação e reinstalação mais cuidadosa? Aproveito pra complementar o tópico sobre essa questão com esse link aqui.

Nossa, por pouco eu não testo isso agora... acontece que, por um acaso, consegui mais uma vez fazer o teclado funcionar durante o grub. Tudo o que fiz foi ativar o IOMMU, e o XHCI e EHCI. Daí, acabei escolhendo o Win7 (que creio que, a essa altura, já deva estar bagunçado, já que um tempo atrás saí pela BIOS testando combinações de opções sem saber dessa questão de ter que mexer no registro dele antes de mudar para AHCI...). Mas quando reiniciei para testar pra saber se conseguiria entrar em outro Linux, o problema do teclado travado voltou a ocorrer novamente... Daí, dentro do BigLinux, tentei o comando do grub-install, conforme você me recomendou aqui. Infelizmente, o problema continou. Até aqui, esse ciclo "problema-resolvido/problema-existente" que às vezes ocorre me faz pensar que haja uma espécie de conflito ou de sobreposição de configurações ou de diretivas (se é que posso usar tais termos) sobre o que se deve ou não fazer durante o grub. Me parece que o problema reside na (ou também na) placa-mãe... Após tentar dentro do BigLinux o comando grub-install /dev/sda, eu tentei também consertar o grub com a ferramenta nativa da versão Live do Biglinux no pendrive... escolhi a opção de restauração intermediária (#2, como na figura abaixo), mas também não deu em nada... Bom, antes de jogar a toalha, creio que ainda posso tentar "brincar" um pouco com as novas configurações... Ou posso tentar instalar um novo SO naquela partição "vazia" do Win 10... Ou ainda, poderia tentar reaver algum grub de outro SO Linux...

Hmm, entendo. Vou em breve fazer isso e retorno aqui o resultado do grub-install. Deixo aqui uma outra informação... não lembro se mencionei aqui, mas, antes de criar o tópico, eu tinha tentado fazer a restauração do grub através de uma ferramenta nativa do Biglinux, que te dava algumas opções para que ele fizesse todo o trabalho de restaurar o grub. Não sei se isso pode ter causado o problema das partições desordenadas... Pelo que disseram aqui, aqui e aqui, não sei até que ponto isso poderia ter me afetado anteriormente, mas fiquei com a impressão de que selecionar o AHCI em vez de IDE não é algo recomendado (aparentemente, isso seria algo perigoso para o Windows, e um pouco chato de resolver no Linux também). Inclusive, lá dizem até que mudar de IDE para AHCI passa a ser mais interessante mesmo pra quem tem SSD... Bom, também fiquei pensando se aquelas linhas duplicadas na imagem (a que tem CD/DVD Rom BBS Drive Priorities) teriam aparecido por conta de ter mexido nessa opção... Obrigado pelo link sobre IOMMU, XHCI e EHCI. Peloq que entendi, o primeiro seria útil para quem usar VirtualBox ou similares, não? Mas de acordo com o link (e pelo que entendi), quando ele é usado em conjunto com os outros dois (que controlam a ativação do USB 3.0 e 2.0, respectivamente), aparentemente ele pode resolver problemas de inicialização... vou testar ativá-los todos e observar o que acontece.

Olha, não tenho certeza se entendi bem a pergunta, mas se você se refere à partição na qual está instalada o grub atual, então sim, o grub está abrigado na partição /dev/sda5 (Biglinux). Reparei também que esse caminho e arquivo (o do /boot/grub/grub.cfg) existe em todos os 3 OS Linux (sda5 - Biglinux, sda6 - EliveOS, e sda7 - Linux Mint). Vou enviar abaixo algumas imagens para maior esclarecimento: 1) Screenshots do Gparted, com zoom, para facilitar a leitura (ignore a partição chamada "Windows 10"... eu desisti de instalá-lo, e ainda não apaguei essa partição vazia...): 2) Boot Options: por agora, o conteúdo das entradas atuais é esse: O Boot Option #1 está assim: Essa lista de lista de dispositivos que aparece no Boot Options #1 também aparece da mesma forma no #2 e #3, só que com os dispositivos SATA PS: [...] e CD/DVD Drive selecionados, respectivamente. 3) CD/DVD Rom Drive BBS Priorities: aqui há 2 entradas com esse mesmo nome (como mostrado na foto anterior). Enquanto a primeira mostra uma tela vazia (sem opções), a segunda já mostra o Boot Option #1, selecionado como SATA PS: [...]: 4) Outras opções envolvendo "Legacy": aqui deixo umas imagens extras de apoio, mostrando com mais detalhes as opções das listas que envolvem o termo Legacy. A configuração que você vê foi testada algumas vezes em combinação com outras, mas isso foi antes de resolver a questão do "antergos_grub" e das partições desordenadas... então não sei se seria interessante refazer os testes, ou se não adiantaria muito nesse caso... : 5) Extras: não sei se são úteis ou não, mas, por via das dúvidas, aqui envio alguns prints sobre possíveis desconfianças que porventura poderiam estar desencadeando o problema original do tópico (por exemplo, ouvi falar sobre "XHCI", sobre gente ativando/desativando USB 3.0 - todas as minhas portas USB na minha máquina são 2.0 -, mas, novamente, não sei se isso influenciaria em alguma coisa...). Em "Sata Configuration", por exemplo, minha configuração está em Native IDE. Não me parece que isso teria a ver, mas já ouvi falarem sobre AHCI (que, pelo que vi, é uma tecnologia da Intel, o que não faria diferença para o meu processador AMD)... E por fim, a configuração de vídeo. Embora não tenha uma placa gráfica dedicada (a minha possui memória compartilhada), me pergunto se haveria uma chance, ainda que bem pequena, de o problema estar envolvido nesta parte também, de alguma forma... (Desculpe pelo exagero/excesso de detalhamento no tópico.) Ah, estive lendo um outro tópico daqui, sobre atualização de BIOS, e lembrei que não postei isso: https://www.gigabyte.com/Motherboard/GA-F2A55M-HD2-rev-30/support#support-dl-BIOS A minha versão é anterior à da versão Beta. Se nada mais funcionar, em último caso, o que valeria mais a pena (ou o que seria menos arriscado)? - Formatar tudo e arriscar reinstalar e particionar o HD novamente em modo BIOS Legacy ("vai que a culpa é de algum bad block..."). - Formatar tudo e arriscar reinstalar e particionar o HD em modo GPT/UEFI (e tentar a sorte encontrando uma nova ISO Win7 e fazendo-a funcionar). - Tentar atualizar a BIOS, realizando um upgrade da última versão estável para uma versão Beta.

Bom, voltei aqui para dar um feedback. Sobre a remoção do "antergos_grub" usando o efibootmgr: deu certo! Foi bem simples mesmo, como mencionado... e fiquei com a impressão de que o meu SO ficou um pouco mais rápido também... Sobre a questão das partições desordenadas usando o cfdisk: deu certo também! Tudo ordenado e ok aqui. Aí chegou a hora do teste final: saber se o teclado travava na tela do grub ou não... Bom, Após sair do modo Live do pendrive linux, retornei a BIOS da placa-mãe para as configurações de fábrica. E após reiniciar, consegui usar o teclado para selecionar outro SO que não fosse o primeiro da lista! Porém... quando saí dele e reiniciei a máquina novamente para escolher mais um outro SO, o problema do teclado travado voltou novamente... Tentei novamente mexer nas configurações de Legacy da placa-mãe, mas nada adiantou... o problema teima em permanecer... Bom... o teclado tinha funcionado na tela do grub após a ejeção do pendrive (cujo Linux em modo Live estava em UEFI) - e acho que não é a primeira vez que, sem querer, consigo usar as setas do teclado no grub dessa forma... Estou desconfiado de que a placa-mãe esteja desregulando alguma opção após os meus boots/reboots... Bom, não sei se vem ao caso, mas a pilha foi recentemente trocada. Então está nova e ok (embora tenha percebido que, nas opções de Data e Hora da BIOS, o horário do dia está errado, marcando algumas horas de diferença para o horário real). Também percebi que houve uma mudança na última vez que estive observando o setup da ordem de boot na BIOS. Antes detectava as unidades de HD e de CD. Agora, a unidade de HD não é mais detectada: em seu lugar, é detectada mais uma unidade de CD (ou seja, há duas linhas repetidas e redundantes na listagem de dispositivos detectados). Envio foto para maior esclarecimento: Me pergunto se essa confusão teria a ver com aquelas entradas duplicadas que sublinhei (em cores verde e rosa). Na verdade, estou ficando desconfiado que haja algum problema adicional ali que esteja provocando o travamento do teclado durante a tela de grub...

Ah, percebi. Bom, se a operação é totalmente segura, então nesse caso eu entendo que nem é preciso fazer backup de nada.

Ok, localizei o programa e vou dar uma verificada com calma nele em breve. Uma coisa que esqueci de comentar no início do tópico é que eu sempre usei uma ferramenta do Linux chamada "Grub-customizer". Embora sempre a tenha usado com parcimônia, fico pensando se isso também teve algum impacto no problema/questão atual. Também esqueci de mencionar outra coisa: antes da manifestação do problema do teclado travado, era possível selecionar tranquilamente o Windows 7 na lista do grub. Porém, já há algum tempo também, o Windows 7 mostrava uma tela em que ele ficava detectando e verificando os volumes instalados (isso demorava algum tempo, e lembro que mostrava uma porcentagem, como "56% da verificação concluída", por exemplo, e seguia assim). Isso acontecia em toda a inicialização dele, mas era fácil de interromper a verificação pressionando ESC. E aí eu conseguia começar a usar o Windows normal também. Mas fora esse pequeno incômodo, não havia nenhum sinal de problema mais sério... Perdão, mas só pra confirmar se entendi com certeza: quando você diz isso, você se refere a não tentar realizar mais nenhum outro procedimento além daquele já explicado sobre a remoção do antergos_grub, certo?

Entendo. Na época que conheci o Ventoy, o que me chamou a atenção foi a capacidade de colocar múltiplas mídias em um pendrive grande (imaginei que isso poderia "economizar" um pouco o desgaste natural do pendrive, ao desacalerar o ciclo de formata/instala). Mas no caso da minha máquina (com sistemas instalados 100% não-UEFI, ou seja, em MBR Legacy), isso não seria uma preocupação, não? Nesse caso, o boot ocorre normalmente. O problema do teclado travado ocorre, e eu tenho que esperar a contagem regressiva acabar para que o grub escolhe e entre na primeira opção de sistema listado nele (no caso, este Linux em que estou escrevendo essa mensagem agora).

Essa parte técnica não deve ser difícil de pesquisar na web com calma depois, mas só pra saber: Se eu entendi bem, onde o print mostra: antergos_grub HD(9, MBR, 0x1835, 0x0, 0x0) ..... Então, tudo que está entre parêntesis são apontadores para partições ou para a MBR (imagino que o número 9 seria um outro id de partição, não?), seria isso? Pergunto porque, se o antergos_grub for removido dessa lista, qual outro dispositivo assumiria/apontaria para o endereço da MBR? Ou isso seria automaticamente gerido pelo "BootOrder"? Nesse caso, não haveria com o que se preocupar, certo?

Ok, vou fazer um backup aqui e vou seguir sua recomendação então. Fiquei com uma boa sensação de que o problema do teclado pode ser resolvido exatamente aqui, neste ponto. Isso significa que não seria recomendável seguir usando o Ventoy de agora em diante? (O único programa do tipo que vi muita gente falando mal sobre foi o Balena Etcher, que diziam que havia o risco de até "bricar" o pendrive...) Esqueci completamente de grifar a parte que mostra "Disco /dev/zram0: 3,03 GB"... Você acha que isso poderia ser normal, ou poderia ter a ver com o problema também?

Olha, abri o terminal do Linux em que estou agora, e com o comando fdisk -l pude ver as partições aqui. Em nenhuma delas está escrito a palavra EFI (exceto a que aparece na ISO Linux que acabei de gravar aqui no pendrive) ou o código identificador que você mencionou. Aqui vai um print da tela: Não sei se são úteis, mas adiciono aqui mais algumas observações extras ao tópico: Observando a imagem, porém, me veio uma coisa aqui à mente: o pendrive com a imagem ISO recém gravada aparece com o rótulo DOS, mas a imagem tem no dispositivo /dev/sdb2 do pendrive uma partição do tipo EFI. Será que estaria havendo um conflito entre o rótulo e o tipo de sistema a se instalar (no caso, aquele EFI da imagem lá)? Eu pensava que o Linux fosse mais flexível e adaptável à essas questões, enquanto o Windows seria algo mais estrito nesse quesito. Sobre gravadores de imagem de USB: geralmente uso Popsicle ou Ventoy como gravadores padrão, mas recentemente vi que existe um outro chamado Rufus, que te possibilita escolher logo de início se o sistema será GPT ou MBR. Será que isso teria alguma influência na questão também? "Partições lógicas fora da ordem do disco": me pergunto se várias instalações (e remoções) de OS ao longo dos anos possam ter criado/deixado algum problema ou vácuo que poderia eventualmente resultar nessa situação também. Reparei que em nenhum dos OS Linux instalados existe aquela pasta /boot/EFI. Já no Windows, pude acessar, via Linux, a pasta C:\Windows\Panther. Ali dentro, no arquivo setupact.log, há uma linha chamada "Callback_BootEnvironmentDetect: Detected boot environment: BIOS". Então, aparentemente, não há sinal de EFI em lugar algum... (por isso mesmo que desconfiei do antergos_grub... me pergunto se esse antigo sistema chegou a ser instalado em modo EFI na época)... Sobre a placa-mãe, uma ideia que tive foi a de atualizar a BIOS. Há uma versão beta disponível no site da fabricante, mas como vejo muita gente desencorajando o uso de versões beta sob o risco de "bricar" a placa, fiquei só com a última versão estável. Por outro lado, me pergunto se seria interessante reinstalar essa mesma versão estável da BIOS, caso nada mais dê certo (a outra opção seria migrar para o Windows 8, mais próxima do Win 7, e que (dizem) não exigiria tanto do setup de uma máquina antiga como essa)... Esqueci de responder: tentei isso e também não deu certo... Olha, acabei de testar um Linux em live mode aqui. No terminal, digitei efibootmgr, e veio um resultado que me fez ter a sensação de que o problema poderia ser resolvido mudando alguns parâmetros aqui. Segue a imagem (com alguns apontamentos meus): Separei por cores pra facilitar a leitura. A sigla MBR aparece no boot0000 (antergos_grub), mas, como você havia desconfiado, há um arquivo grubx64.efi coexistindo na máquina com os demais parâmetros/entradas dela. Fiquei meio inseguro de tentar mexer ali. Você acha que haveria algum problema, dado que as entradas parecem um pouco bagunçadas em algum grau? Quer dizer, a entrada 0005 não está listada no "BootOrder" ali em cima. Além disso, seria normal as entradas em verde e as em rosa aparecerem de maneira duplicada/redundante (especialmente as entradas 0004 e 0006, que tratam do mesmo HD, mas com nomes distintos)? Em suma, considerando a imagem acima, seria seguro remover o antergos_grub? Ou haveria o risco de que, com essa remoção, a MBR também fosse removida e perdida para sempre também?

@Marcos FRM Oi Marcos! Muito obrigado pelo apoio! Olha, no caso, não tenho nenhum Linux iniciado em UEFI. Porém, não tinha pensado na ideia de usar um Linux em pendrive, em modo Live, a partir da entrada UEFI... vou tentar aqui e depois retorno com a resposta... Esse comando do efibootmgr me foi sugerido anteriormente em outro fórum, mas até então eu não tinha percebido a possibilidade de usá-lo em um pendrive em modo Live. Fico pensando se a remoção do "antergos_grub" resolveria o problema do teclado... Eu já tentei mudar (e combinar) várias vezes as opções da placa-mãe que tinham Legacy, mas nada adiantou. Bom, vou tentar essa sua combinação, e, mais uma vez, retorno em breve com o resultado.

Olá pessoal. Não sabia onde exatamente criar o tópico, pois não tinha certeza se o problema é de software, firmware ou hardware. O fato é que, de uns tempos pra cá, não tenho conseguido mais usar o menu do meu grub (tenho um Windows 7 + 3 outros Linux nele). Sempre os usei normalmente aqui, em modo BIOS MBR Legacy, sem problemas. Mas agora percebi que o travamento ocorre quando seleciono um OS da lista de sistemas instalados. No caso, o teclado pára de funcionar durante a tela do grub (funciona normal antes e depois dele, mas não durante). Também percebi que o problema ocorre com um pendrive inicializável. Tanto apertando F12 para escolher o dispositivo de boot, como usando Ventoy instalado no USB (que, no caso, também te dá uma tela de opções de sistemas e demais coisas por lá também). A minha placa-mãe é da Gigabyte (GA-F2A55M-HD2), bem antiga, de 2014. Aliás, todo o meu setup é dessa época (à exceção da fonte de alimentação, que foi trocada por uma nova recentemente). Por ser antiga, a placa é DualBIOS, admitindo tanto o modo UEFI, o modo UEFI CSM e o modo MBR Legacy. ============================== Não sei se essas informações são relevantes, mas tenho todos os meus sistemas instalados em modo MBR Legacy. Tenho uma partição separada só para Dados, e outras para OSes e Swap. Sobre os OSes, uso o Windows 7 totalmente offline, exclusivamente como videogame. Os demais Linux são o BigLinux, o Linux Mint e o Elive OS (que uso com parcimônia). Mas, como sempre fui um distrohopper, já instalei muitos outros sistemas Linux (nunca precisei mexer no Windows, embora ultimamente ele também estivesse fazendo verificações de espaço em disco sempre que inicializa, a não ser que eu intervisse apertando ESC). Um deles foi um que testei há muito tempo (o Antergos Linux, uma finada distro derivada do Arch), e que por algum motivo, permanece aparecendo quando aperto F12 para entrar na tela de escolha de boot. Será que isso teria a ver com o problema? ============================== Enfim... fiquei pensando aqui se haveria a chance de que a "porção BIOS Legacy" da minha placa-mãe tivesse morrido, só sobrando a "parte UEFI "da placa-mãe... Tentei mexer em todas as configurações possíveis recomendadas nos diversos fórums de informática pela web (Secure Boot, Fast Boot, CSM, etc), mas nada resolve. O problema permanece: aguardo os 5 segundos de boot e consigo usar a primeira opção de sistemas do grub (o BigLinux no caso). Mas como o teclado não funciona durante esses segundos, não tenho mais acesso ao meu Win 7 e demais OS Linux... Então é isso. Vou deixar aqui algumas imagens de apoio, caso ajudem (quais outras informações extras eu poderia colocar aqui que poderiam ajudar na questão?). (O mais louco é que, muito, muuuito raramente, em condições específicas, eu consigo de fato usar o teclado e escolher o SO do meu grub. Por exemplo, quando atualizei o meu BigLinux, reiniciei e conseguir escolher outros sistema... mas quando desliguei a máquina da energia e liguei novamente algumas horas depois, o problema permaneceu. Creio que uma situação similar ocorreu após testar uma ISO live de outro Linux, pois quando reiniciei e tirei o pendrive, pude acessar o teclado... mas novamente, o problema voltou quando reiniciei a máquina). Bom, é isso. Alguém teria alguma luz sobre a questão? (Por favor, não me peçam para converter o disco para GPT/UEFI. Pelo que pesquisei nos últimos dias, a experiência de instalar o Win 7 no HD (não uso SSD) em UEFI é totalmente infernal... Muito obrigado pelo apoio, mais uma vez! Shak.

Obrigado pela formatação do tópico e pelas respostas de vocês! Bom, pelos relatos, aparentemente está tudo normal aqui. Eu só usei ele na em cidade grande - capital (110V) e pequena, de interior (220V). Bom, a única preocupação é que a energia cai com uma certa frequência por aqui, mas como eu costumo sempre desligar tudo aqui antes dela retornar (o que costuma levar cerca de uns 10 minutos, em média), creio que tudo esteja sob controle então. (Como complemento ao tópico, deixo aqui a imagem dele:)

Só aproveitando o tema do tópico: Tenho esse iClamper na versão branca (embora não saiba dizer se ele é 5 ou 8... mas ele tem 5 tomadas), comprado entre 2018/2019. Queria saber se vocês saberiam dizer qual a durabilidade média de um iClamper. Quer dizer, quanto tempo ele já durou com vocês? Quais os sinais de que o equipamento já não está performando bem, ou mesmo, que já está precisando ser trocado?

Estou de volta apenas para complementar e finalizar este tópico. Consegui descobrir que o problema era a fonte. Uma nova resolveu o problema. Obrigado a todos pelo apoio! Shak.