Postagens

Driver da Nvidia convive com o simpledrm

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ç

Arquivo de swap? Sim, obrigado.

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 -

Driver da Nvidia atravancando o progresso do Linux

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

Mídia de instalação do Windows em MBR ou GPT?

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

Ghost e o BCD

Imagem
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

Como as partições são identificadas no BCD

Imagem
Dias atrás, surgiu no fórum Clube do Hardware a dúvida se, ao mover partições do Windows, entradas para as mesmas no BCD — banco de dados onde ficam armazenadas as configurações do carregador de inicialização desde o Vista — deixariam de funcionar, requerendo reconfiguração ( BootRec /RebuildBcd do Windows RE é o jeito mais simples). Tal assunto está bem documentado aqui . O que bcdedit /enum ALL mostra em device , osdevice , filedevice e ramdisksdidevice é a tradução que o programa faz, com intuito de deixar a saída amigável. Por baixo do capô, assinatura NT do disco e o deslocamento em bytes estão salvos caso seja MBR; em GPT, os GUIDs do disco e da partição [1] . Isso quer dizer que, em GPT, as partições podem ser movidas à vontade, enquanto que, em MBR, seus inícios não podem ser alterados. Depois de publicar este texto, descobri a opção não documentada bcdedit /raw , que exibe o dispositivo sem firulas! [1] detail partition do

Mídia de instalação USB do macOS High Sierra (10.13.6) pelo Linux

Imagem
Consiste em criar uma única partição HFS+, colocar o conteúdo de BaseSystem.dmg dentro e depois copiar alguns arquivos para o diretório Install macOS High Sierra.app/Contents/SharedSupport (incluindo o próprio BaseSystem.dmg ). Para nossa sorte, o Linux tem suporte razoável, de leitura e escrita, ao HFS+, desde que não tenha journal . Instale o pacote hfsplus-tools (Fedora) ou hfsprogs (Debian). Não funciona em Hackintosh. Rode como root e adapte USBDEV . #!/bin/bash set -e # dispositivo a ser usado # apagará tudo! USBDEV=/dev/sdx # para outras versões, pesquisar em # https://swscan.apple.com/content/catalogs/others/index-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz # https://swscan.apple.com/content/catalogs/others/index-10.14-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz # https://swscan.apple.com/content/catalogs/others/index-10.15-10.14-10.13-10.12-10.11-10.10-10.9-