Caixa Seca

O instalador do Windows, em UEFI, sempre aproveita a partição EFI [1] existente, independente do disco em que resida, visto que deve ser única por máquina . Tê-la num disco diferente da instalação atual, remanescente de instalações anteriores, não é tão incomum. Remover ou apagar esse disco surpreende os não familiarizados ao impedir a inicialização. O que fazer quando a partição EFI não existe mais? Começamos iniciando a mídia de instalação e, nela, carregando o Windows RE, que é o ambiente de recuperação embutido. Os assistentes automatizados de nada ajudam nesta questão. Precisamos do Prompt de Comando: Reparar o computador → Solução de Problemas → Prompt de Comando. Primeiro passo é carregar o diskpart , identificar o disco da instalação a ser recuperada e selecioná-lo: diskpart list disk select disk X detail disk Substitua X pelo número que aparece na coluna "Nº Disco" de list disk . A saída de detail disk dará deta

O Hyper-V tem um recurso interessante no comutador "Default Switch" que automaticamente adiciona um registro DNS no hospedeiro com o nome de máquina do convidado quando este obtém IPv4 via DHCP. É salvo em %SystemRoot%\System32\drivers\etc\hosts.ics e usa o domínio mshome.net . Meu convidado Fedora 40 não estava aparecendo lá. NetworkManager envia o nome de máquina na requisição DHCP: $ nmcli connection show eth0 | grep hostname ipv4.dhcp-send-hostname: sim [...] Descrição da propriedade no manual nm-settings : If TRUE, a hostname is sent to the DHCP server when acquiring a lease. Some DHCP servers use this hostname to update DNS databases, essentially providing a static hostname for the computer. If the "dhcp-hostname" property is NULL and this property is TRUE, the current persistent hostname of the computer is sent. Depois de quebrar um pouco a cabeça, lembrei que a instalação do Fedora por padrão não configura um nome

Kernel 6.5 parece ter resolvido a compatibilidade do simpledrm com o driver da Nvidia através do commit 5ae3716 — ainda requer os obsoletos drivers fbdev habilitados ( CONFIG_FB_EFI=y e CONFIG_FB_VESA=y ). A solução definitiva está presente a partir do driver 545. O módulo nvidia_drm ganhou a opção fbdev=1 , que torna-o compatível independente do commit citado e sem requerer os obsoletos drivers fbdev. Para usá-la, crie /etc/modprobe.d/blabla.conf (nome não importa, desde que termine em .conf ) contendo: options nvidia_drm modeset=1 fbdev=1 (são desativadas por padrão) É importante o initramfs ser recriado para conter esse arquivo. No Arch: mkinitcpio -P (requer o hook modconf configurado). Ambas podem ser especificadas igualmente nas opções de inicialialização: nvidia_drm.modeset=1 e nvidia_drm.fbdev=1 (hífen em nvidia-drm… também é aceito). Entretanto, em distribuições cujo kernel tenha este patch quebra-galho, a primeira opç

Havia um antigo post aqui no blog, lá dos primórdios, não recomendando partição swap. Com a popularização dos arquivos de swap, o texto foi expandido, aceitando-os a contra gosto. Só que isso foi antes de tecnologias recentes do Linux, que resolveram problemas associados ao uso de swap: melhorias no kernel e, principalmente, daemons que monitoram informações de pressão de memória, E/S e CPU do kernel ( Pressure Stall Information , PSI, disponível a partir da versão 4.20) e agem antes . O mais usado é o systemd-oomd [1] . Para ser eficiente em instalações desktop, precisa que os aplicativos sejam postos cada um num cgroup diferente , o que é feito via systemd --user pelo GNOME e KDE. Em ambientes que não o façam, como o XFCE, não é recomendado habilitá-lo. Mesmo assim, o kernel não é mais tão burro como antigamente . Minha restrição às partições swap continua: são pouco flexíveis. Logo, use sim arquivos de swap! Btrfs: # btrfs filesystem mkswapfile -

Desde o kernel 5.14, lançado em 29 de agosto de 2021, existe o driver Direct Rendering Manager (DRM) genérico simpledrm , que usa o framebuffer fornecido pelo VBIOS/UEFI. Em distribuições que ativem-no ( CONFIG_DRM_SIMPLEDRM=y e CONFIG_SYSFB_SIMPLEFB=y ), adicionar nomodeset nas opções de inicialização passa a ser verdadeiramente um modo de segurança gráfico, que funciona com o Wayland: driver DRM nativo da GPU — como i915 , amdgpu , etc. — não é carregado e o simpledrm fornece um dispositivo DRM funcional [1] . LLVMpipe (Mesa) completa o time fornecendo OpenGL via software. Acaba beneficiando também o Xorg, pois seus drivers do espaço de usuário vesa e fbdev (há muito tempo com manutenção precária) não são mais requeridos. [ 0.599209] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.600186] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device https://fedoraproject.org/wi

Há uma enorme confusão sobre esse assunto. Afinal, para instalar o Windows em UEFI, a mídia de instalação precisa estar particionada em GPT? BIOS UEFI [1] suportam particionamento MBR e GPT, enquanto BIOS antigos (não UEFI) apenas suportam MBR [2] . Tanto faz, portanto, com UEFI. Então por que muita gente acha que GPT é requerido? Presumo por dois motivos: → O Windows requer que o disco de destino, no qual será instalado, seja particionado em GPT. A exigência, contudo, não aplica-se à mídia de instalação. → O Rufus artificialmente restringe a criação de mídias compatíveis com UEFI ao particionamento GPT, ao contrário do Media Creation Tool (MCT) da Microsoft, que sempre particiona em MBR. Tal comportamento do Rufus tem como objetivo evitar confusão, pois discos em GPT não iniciam em máquinas com BIOS antigos. Assim, tem-se uma mídia UEFI-only . Já discos em MBR funcionam com BIOS antigos. Será que tais mídias iniciam também em UEFI, visto q

No particionamento MBR, o BCD armazena o caminho para cada partição usando deslocamento e assinatura de disco (ver Como as partições são identificadas no BCD ). Clonando discos com o venerável Ghost, poderíamos assumir que, ao mover os inícios das partições (ao redimensioná-las), suas entradas ficariam inválidas. MBR Não é o caso, pois o programa é inteligente para automaticamente atualizar o BCD, tanto com o deslocamento, quanto com a nova assinatura de disco. Por padrão, uma nova assinatura é criada no destino nos modos disco para disco e imagem para disco . Com GPT, novos GUIDs são gerados, para o disco e partições — BCD é atualizado de acordo igualmente. Podemos alterar esse comportamento com -fdsp , que mantém a assinatura original em MBR (deslocamentos são atualizados no BCD mesmo assim) e, em GPT, preserva todos os GUIDs, de modo que o BCD não precisa ser alterado. Ter mais de um disco co