Marcos FRM

Igual: Ou seja, CSM nem funciona mais com o próprio vídeo integrado. Portanto, mantenha UEFI com secure boot ativo (padrão da indústria desde 2012) e reinstale o Windows.

O sistema operacional do Xbox usa máquinas virtuais para isolar jogos dos aplicativos, então realmente não tem nada mais comendo processamento enquanto o jogo roda. Acredito que o Sony faça algo similar no Playstation. Este vídeo antigo, do tempo do Xbox 360, explica como funciona: A arquitetura não deve ter mudado muito desde lá.

Vá lá saber! CSM nem era para estar disponível mais se esses fabricantes tivessem vergonha na cara.

O BIOS está te explicando: a placa de vídeo não é compatível com CSM. Se a instalação do Windows foi feita em CSM, precisará reinstalar em UEFI.

Essa serve. Não precisa mais.

Considerando a TUF GAMING B660M-PLUS D4, não tem o recurso mencionado pelo @rodrigo.dcvieira , que a ASUS chama de "USB BIOS FlashBack".

Sim, é triste. O hardware é excelente, porém muito caro. Vai no usado então. Terá atualizações do macOS por no mínimo mais três anos; com sorte, mais.

O M2 é um processador potente pacas. No entanto, maior RAM e SSD do modelo usado vão fazer diferença para seu uso. Se estiver em boas condições, acho mais negócio. E novas versões do macOS serão suportadas nesse MacBook Pro 2017 por vários anos ainda. @Rjmp Olhei agora e o macOS 13 (Ventura) já está exigindo o MacBook Pro 2017 ou superior. Então, é provável que, daqui um ou dois lançamentos, o MacBook Pro 2017 deixe de ser suportado. Continuaria na última versão compatível recebendo atualizações de segurança. Considerando o pior cenário possível, que é o macOS 13 ser o último suportado, teria mais uns três anos (em média) de atualizações de segurança. Nada impede usar o macOS depois de ser descontinuado, porém, igual ao Windows, não é recomendável. Com isso em mente, mudo minha recomendação: talvez o M2, mesmo com especificação inferior de RAM/SSD, seja melhor!

Era para ter. Em princípio, é isso. Se alguém desvendar o mistério, nos ilumine!

A opção do BIOS não tem importância neste contexto. Correção: a mensagem dizendo que o volume está hibernado é do NTFS-3G. O udisks captura stdout e stderr, daí me confundi. https://github.com/tuxera/ntfs-3g/blob/2022.10.3/libntfs-3g/volume.c#L716 Estranho. Rodou o chkdsk com a opção /f? Depois, tem que acessar volume novamente no Windows para o journal ser atualizado, para só daí testar no Linux.

Tem certeza que desativou a inicialização rápida no Windows? Pois o udisks está dizendo que não... Caso sim, carregue o Windows e rode o chkdsk. Testei no meu Windows 11 aqui e o NTFS-3G monta em leitura/escrita sem problema.

A partição NTFS é outra então? Daí não tem ligação mesmo. Monte volume NTFS e rode os seguintes comandos: journalctl -b | grep -E 'udisksd|ntfs' findmnt -uS /dev/disk/by-uuid/06F8E27F0FFBAFC7

Essa linha de nada serve. Remova. Qual volume tem o rótulo "HDD1"? Qual o sistema de arquivos desse volume?

O ponto de montagem /mnt/blabla não é o padrão do udisks. Poste o conteúdo do /etc/fstab para termos certeza que nada está atrapalhando.

Então resta fazer o NTFS-3G exibir informações de depuração para ver se aparece algo útil. Como você monta o volume? Pelo aplicativo "Discos" tão somente? Mexeu no /etc/fstab? (é preferível não mexer)

Não. @Pepse Você desativou a inicialização rápida? Caso não, testou reiniciando o Windows ao invés de desligá-lo antes de carrear o Arch?

Ele quer gravar no volume NTFS a partir do Arch. É suportado faz muito tempo:

Versões Pro do Windows:

Compra obrigatória. Adoraria uma versão impressa, mas infelizmente o Gabriel já explicou que é inviável.

"Fast BOOT" quer dizer "Ligar inicialização rápida (recomendado)" em "Painel de Controle → Opções de Energia → Escolher a função do botão de energia"? Qual ambiente gráfico e como está montando o volume em questão?

Crie, pois não era para acontecer.

Qual foi a mexida?

Volta e meia aparece tópico aqui de gente com placa Gigabyte que não consegue desativar CSM, que não consegue ativar Secure Boot, que não consegue fazer isso, aquilo.

Esqueci de algo importante. Para rodar o GNOME Wayland tem que usar uma distribuição com componentes mais recentes. Neste momento, o GNOME do Debian 11 (3.38) está quatro major versions para trás. É muito tempo para códigos em constante desenvolvimento como o Mutter, bibliotecas que implementam o protocolo e o protocolo em si. Tópico ainda é útil. Reforme-o quando sair o Debian 12. Na seção 4.1, faltou substituir "Ajustes do GNOME" pelo aplicativo "Extensões" (GNOME 3.36+).

Concordo que, para hardware antigo, o 10 é preferível e um pouco mais leve. Eu acreditava nessa baboseira de hardware "não suportado" não receber atualizações de segurança. Desde as primeiras versões de teste do Windows 11, ninguém deixou de receber atualizações de segurança, mesmo rodando em hardware caquético. Cheguei à conclusão que é pura cascata da Microsoft. Para instalar em tais máquinas é simples, resume-se, no Rufus, a marcar duas caixinhas (selecionadas por padrão, aliás): Havendo drivers -- e drivers para Windows 10 servem --, tudo tende a funcionar, desde que a máquina suporte UEFI (CSM/Legacy sim requer gambiarras complicadas e não vale o trabalho). O interessante é que, em máquinas que rodam atualmente o Windows 10 cuja licença foi obtida via atualização gratuita a partir de versões anteriores, a licença digital também aplica-se ao Windows 11. É só fazer uma instalação limpa que ativará da mesma forma. Suponho que igualmente valha para máquinas que vieram com Windows 8, 8.1 ou 10 pré-instalado de fábrica (com chave no BIOS). Não testei este último cenário ainda, mas aposto um café que funciona. Tenho usado o Windows 11 numa máquina secundária, velhinha (Intel Sandy Bridge), para ir me ambientando. O 22H2 está tranquilo até o momento.