Marcos FRM

A mídia de instalação do Windows 11 não suporta CSM/Legacy, nem com gambiarra. UEFI é requerido mesmo. Depende. Existem gambiarras extremas até para fazê-lo rodar em CSM/Legacy (descobri agora ), basicamente recriando a mídia de instalação. Contudo, a gambiarra dos valores "BypassTPMCheck" e "BypassSecureBootCheck" do registro da mídia de instalação são oficiais para mim. Por que estariam no produto final? Alguém pode alegar que, quando o Rufus adiciona os dois valores, está modificando a mídia de instalação. Sim, está, porém apenas o boot.wim (o instalador) minimamente, não o install.wim, que é o Windows em si a ser aplicado. E tem mais: é possível adicionar os dois valores no registro dentro da própria mídia de instalação, chamando o prompt de comando (Shift+F10) e depois o regedit. Tem o mesmo efeito.

Apenas precisa estar em FAT32 (ou FAT16 para pendrives bem pequenos). A capacidade provavelmente pouco importa.

O modo de desligamento padrão do Windows desde o 8 ("inicialização rápida") coloca a placa-mãe num modo de hibernação que desativa opção para entrar no setup, pelo menos em placas não tão velhas. Existem duas possibilidades: fazer um desligamento completo, pressionando o "Desligar" do menu iniciar com a tecla Shift pressionada, ou usar "Reiniciar", que sempre faz o desligamento completo. Caso ainda não consiga acionar alguma tecla para entrar no setup, pode usar, caso a placa esteja no modo UEFI, o seguinte: clique em "Reiniciar" mantendo a tecla Shift pressionada. Depois vá em "Solução de Problemas → Opções avançadas → Configurações de Firmware UEFI → Reiniciar".

Esse método é para inicializar em UEFI; não é para usar o Q-Flash, em princípio. Essa pasta BOOT não estava dentro de outra EFI? Faça o seguinte: crie uma pasta com nome EFI na raiz do pendrive e mova a pasta BOOT para dentro dela. Deve cair num prompt de comando (shell EFI), daí você digita fs0: ou fs1: (etc, Enter no final) para acessar o sistema de arquivos FAT do pendrive e depois digita flash.nsh, um arquivo batch para o shell, que rodará o atualizador, tendo como opção de linha de comando o nome do arquivo contendo a imagem do BIOS. Talvez você tenha que desabilitar o Secure Boot temporariamente para conseguir inicializar o shell. Se não funcionar, poste o que tem dentro da pasta BOOT.

A menos que tenha sido modificado anteriormente, msconfig nunca é solução para nada nesses casos. Deixe as opções como eram originalmente. Procure no BIOS algo como "memory remap" ou similar.

Com o wimsplit deve funcionar (nunca testei): https://wimlib.net/man1/wimsplit.html Contudo, é perda de tempo. Use o Ventoy como recomendado pelo @FoxBlack : https://www.ventoy.net/en/doc_start.html Sabe-se lá qual base essa porcaria de Satux usa hoje em dia, por isso baixe o binário pré-compilado e pronto: https://www.ventoy.net/en/doc_linux_gui.html

Cuidado: Há uns dois anos, comprei na loja física da Kalunga o MS Office 2019 Home & Student vitalício por 250 reais. Na época, era mais barato do que no site. 100% legalizado. A Microsoft tem desestimulado as versões vitalícias, porém ainda existem. Dê uma olhada se tiver alguma loja perto de você. É aquele tipo de licença que vêm a chave no cupom fiscal, daí você entra na sua conta da Microsoft no site do Office e baixa o instalador.

Obrigado pelo link. Dele, extraímos o link que interessa: https://www.amd.com/en/support/kb/faq/pa-410 Demorou pacas para descobrirem, hein? Os primeiros relatos das infames travadas já devem ter uns 10 meses mais ou menos (pegando da memória, talvez seja mais). Levando em conta que a correção sairá daqui dois meses, terá sido ~1 ano! Depois tem outra celeuma, que será a rapidez (ou lentidão ) dos fabricantes de placas-mãe para incorporarem o novo AGESA.

Qual programa do Mint? Tem alguns que são ruins, como WoeUSB... já teve tópico aqui no fórum reclamando. No Linux, use o Ventoy. Todo mundo fala bem dele: https://www.ventoy.net/en/doc_start.html Evite o Windows 7, que está morto e enterrado.

Um sistema de arquivos com journal, como o NTFS, é mais robusto, às custas de lentidão adicional com a péssima qualidade média dos pendrives atuais. Como o @Lucsp disse, nada é garantido. Nada impede que uma porta USB assassina, de algum computador de terceiros, frite-o...

Esta falha, apelidada de Dirty Pipe, presente desde o kernel 5.8, é catastrófica: https://dirtypipe.cm4all.com/ https://www.suse.com/c/suse-statement-on-dirty-pipe-attack/ https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/ Permite usuários normais obterem privilégio root com facilidade. Qualquer usuário com acesso ao shell pode fazer estrago. Corrigida nas versões 5.16.11, 5.15.25 e 5.10.102. Todas as distribuições já lançaram pacotes atualizados.

Com setores de 4 KB. Dispositivos 4K native (4Kn) ainda não são muito populares: por enquanto, só alguns HDDs e SSDs. Pendrives expõem setores de 512 bytes. Contudo, para dispositivos desse tamanho (> 2 TB), FAT32 não tem escalabilidade necessária. Não sendo importante ampla compatibilidade, exFAT quase sempre é melhor escolha comparado com FAT32 -- exceto em dispositivos pequenos ou com alguma finalidade específica (que inicialize MS-DOS ou algo do gênero).

Quem escreveu isso? FAT32 suporta arquivos de no máximo 4 GB. O tamanho do volume é limitado artificialmente pela interface gráfica do Windows em 32 GB, porém suporta com ampla compatibilidade até 2 TB. Tais sistemas são apelidados de "Large FAT32" e podem ser criados pela linha de comando com o diskpart (parece que limita em 1 TB, a conferir) ou usando ferramentas de terceiros, como o Rufus. A limitação artificial de 32 GB do Windows faz sentido, pois acima disso é recomendável exFAT, que está cada vez mais popular e não tem a limitação de 4 GB por arquivo. Possui hoje em dia bom suporte no Linux, Android e macOS. Aparelhos velhos e/ou porcarias costumam não suportar, entretanto. NTFS em pendrives baratos em geral é horrível, pois o desempenho deles deixa muito a desejar. Daí soma o overhead do journal e piora mais ainda. Num pendrive rápido (existe isso?) talvez dê para aturar.

É o GNOME o ambiente gráfico?

Qual recurso do Pro faz alguma diferença para jogos?

Teste desabilitando o fTPM no BIOS (cuide a questão do BitLocker!). Se resolver, é o problema que linkei acima.

É Windows 11? Edit: @Roberto Tokuda Pode ser isto: https://www.reddit.com/r/Windows11/comments/sccict/amd_ftpm_causes_random_stuttering_issue/ Há um problema entre o firmware TPM (fTPM) da AMD e o Windows 11. Alguns relatos dizem que acontece também no Windows 10. Não há solução por enquanto, a não ser desabilitar temporariamente o fTPM no BIOS. Sem o fTPM, Windows 11 considerará o hardware "não suportado", mas continuará funcionando. Cuidado se usar o BitLocker! Leia sobre como salvar suas chaves, senão pode perder para sempre o acesso aos seus arquivos. AMD diz que está investigando e a Microsoft está calada. Caso seja bug no código da AMD, tem que esperar a empresa corrigir e disponibilizar atualizações para os fabricantes de placas-mãe integrarem em novas versões de BIOS. Já se for bug do Windows, tem que esperar a Microsoft corrigir. Ou as duas coisas.

Gigabyte é um caos. Seria de imaginar que "Windows 10 WHQL" desativaria todo o legado carcomido e deixaria a configuração recomendada desde o Windows 8: CSM off (nenhuma opROM "legacy", etc), UEFI+Secure Boot on e TPM on. Mas não... Se tiver um modo "Windows 11" escolha-o, mesmo para o Windows 10. Sobre pendrive, para Linux, o pessoal fala bem do Ventoy, porém nunca usei.

Achar documentação dessas marcas chinesas é difícil. Veja se no BIOS tem algo útil.

O Arch não incomum é o primeiro a implementar mudanças drásticas, até mais radicais que o Fedora. Arch fez algo que nunca seria aceito no Debian e arrisco dizer até no Fedora: acabou com o diretório /usr/sbin. Todos os binários vão em /usr/bin: https://archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ O Fedora fez há 10 anos o famoso "usrmerge", que foi abolir os diretórios /bin, /sbin, /lib, /lib64, tornando-os links simbólicos para /usr/bin, /usr/sbin, /usr/lib, /usr/lib64, respectivamente, o que não era novidade, pois já havia sido feito pelo Solaris anos antes: https://fedoraproject.org/wiki/Features/UsrMove openSUSE adotou esse layout do Fedora faz pouco tempo: https://en.opensuse.org/openSUSE:Usr_merge Debian 11 oferece uma opção para converter sistemas existentes, instalando o pacote "usrmerge". Futuro Debian 12 usará o novo layout por padrão: https://wiki.debian.org/UsrMerge Ou seja, as coisas vão andando. Às vezes mais devagar do que o esperado.

O Fedora tem tradição em inovar -- em geral para melhor. Quando as mudanças são benéficas, tendem a serem incorporadas, parcialmente ou totalmente, pelas demais distribuições. Quem gerencia pontos de montagem para usuários regulares nos ambientes gráficos é, no GNOME/KDE/XFCE (talvez outros), o udisks: https://github.com/storaged-project/udisks Antigamente, o udisks usava /media, porém mudou para /run/<usuário> posteriormente: https://github.com/storaged-project/udisks/blob/udisks-2.9.4/configure.ac#L129 (ou seja, é compilado com --disable-fhs-media hoje em dia) Discussão: https://bugs.freedesktop.org/show_bug.cgi?id=51709 É um longo processo (ainda não terminado) de adaptar os pacotes para colocarem seus arquivos de configuração padrão em /usr. Modificações são feitas em /etc: arquivos com mesmo nome têm prioridade sobre os de /usr. Veja este commit do PAM: https://github.com/linux-pam/linux-pam/commit/10b83ef224a5e9c3e2663b3f08dd17090acc58ab Isso evita arquivos .rpmnew/.dpkg-new/etc, pois as modificações locais feitas pelo administrador estão num lugar diferente dos arquivos empacotados. Contudo, ainda não é ideal, pois tem o problema de configurações não sincronizadas: a versão nova pode trazer uma nova opção, não presente no arquivo de /etc. Tem este projeto interessante da SUSE para atacar isso: https://github.com/openSUSE/libeconf Como é funcionalidade nativa do systemd, está à mão. Contudo, tem bastante coisa no repositório que usa o crond. É um programa ativamente mantido (pelo menos o fork cronie[1] usado pelo Fedora/openSUSE), que permanecerá entre nós por bastante tempo. [1] https://github.com/cronie-crond/cronie

Qual modelo da placa?

Não tem. O dispositivo está com defeito, ou é algum bug do programa de clonagem, ou ambos.

Qual máquina? Pois é comum pessoal tentar usar M.2 PCIe NVMe com processador Athlon 3000G, que não suporta...

Certifique que está usando o Rufus 3.17. Mesmo com NTFS, o Rufus usará um bootloader próprio, com suporte ao secure boot, para carregar a mídia. Portanto, está correto assim. Resta descobrir como fazer o notebook iniciar pelo pendrive. É quase certo que esteja em UEFI. Caso não consiga entrar no setup, tente usar, dentro do Endless, o comando: systemctl reboot --firmware-setup ou sudo systemctl reboot --firmware-setup Deve reiniciar e entrar no setup automaticamente. Lá veja o que tem para ajustar. Alguns notes não iniciam via USB se "Fast Boot" estiver habilitado. Outros possuem opção para mostrar um menu de inicialização via F12, "F12 Boot Menu" ou algo assim. Mantenha o modo de inicialização em UEFI com secure boot habilitado.