Postagens

ntfs3 empacou

Quando postei Linux 5.15 contará com novo driver NTFS , esperava que, lançado o kernel 5.15 com o novo driver ntfs3 da Paragon Software, começasse o processo de correção de bugs logo em seguida, com a estabilidade continuamente melhorando a cada nova versão. Infelizmente, não foi o que aconteceu. Konstantin Komarov, mantenedor do código, desapareceu e, no repositório oficial, o último commit é de 12 de outubro de 2021. Desde que a versão 5.15 foi lançada, nenhuma mudança relevante foi aplicada — apenas adequações à API interna do kernel feitas por outros desenvolvedores. No repositório de desenvolvimento , há nove commits adicionais, sendo o último de 24 de novembro de 2021. Andei testando-o no Fedora nas últimas semanas (5.15.x até 5.16.8 enquanto escrevo). O desempenho é muito melhor do que o NTFS-3G, porém é instável. É fácil fazê-lo travar com o rsync (o kernel fica em pé pelo menos) e links simbólicos e pontos de junção não são resolvidos corretament

GRUB4DOS no MBR

Costumava usar o bootlace64.com para instalar o código de inicialização do GRUB4DOS no MBR. Contudo, com o dd dá para conseguir o mesmo resultado. Pegando o post anterior como exemplo: # dd if=grub4dos-0.4.6a/grldr.mbr of=/dev/sdx bs=440 count=1 conv=fsync,notrunc Copia os primeiros 440 bytes ( bs=440 count=1 ) do arquivo grub4dos-0.4.6a/grldr.mbr para o início do dispositivo /dev/sdx . Os demais 72 bytes (offset 0x01b8 até 0x01ff ) do MBR não devem ser alterados: são criados durante o particionamento. # dd if=grub4dos-0.4.6a/grldr.mbr of=/dev/sdx bs=512 skip=1 seek=1 conv=fsync,notrunc Copia o resto do código para o espaço não usado antes da primeira partição. Pula os primeiros 512 bytes ( bs=512 ) do arquivo ( skip=1 ) e do dispositivo ( seek=1 ). Dali para frente, escreve o restante do arquivo no disco. Agora é só copiar grub4dos-0.4.6a/grldr para a raiz do sistema de arquivos e criar, igualmente na raiz, o menu.lst de sua preferê

Desafio: inicializar o IBM PC DOS

Imagem
Lendo a lista de desenvolvimento do FreeDOS, achei este link: IBM ServerGuide Scripting Toolkit, DOS Edition, version 1.3.07 Tem uma cópia do IBM PC DOS 7.1, um DOS moderno , com suporte a LBA e FAT32 (ufa!). Como inicializá-lo, criando o disco a partir de outro sistema, sem ter os códigos de inicialização à mão no ms-sys ? Para mim, o jeito mais simples é usando o GRUB4DOS [1] , que reconhece, através do comando chainloader , o arquivo IBMBIO.COM e aplica a mágica necessária para carregá-lo. A partir de qualquer Linux atual: wget https://github.com/chenall/grub4dos/releases/download/0.4.6a/grub4dos-0.4.6a-2021-12-17.7z wget ftp://ftp.software.ibm.com/systems/support/system_x/ibm_sw_sgtk_1_3_07_anyos_anycpu.zip 7za x grub4dos-0.4.6a-2021-12-17.7z unzip ibm_sw_sgtk_1_3_07_anyos_anycpu.zip echo ',,0c,*' | sfdisk --lock=yes --wipe=always --wipe-partitions=always --label=dos /dev/sdx mkfs.fat -F 32 -n PCDOS /dev/sdx1 mount /dev/sdx1 /mnt cp -pv grub4d

Precisa de sync ao escrever diretamente em dispositivos de bloco?

É comum, em tutoriais sobre como escrever imagens ISOHybrid em pendrives, a recomendação: # dd if=xxx.iso of=/dev/sdx bs=1M status=progress # sync ( bs= variando dependendo do gosto do freguês) Esse sync após o dd , apesar de muito difundido, acredito não ter efeito. O manual da chamada de sistema sync() diz claramente que aplica-se apenas a sistemas de arquivos. O dispositivo de bloco bruto não é um sistema de arquivos. Portanto, o que faz efeito é adicionar a opção conv=fsync ao dd : quando a escrita termina no destino, chama fsync() no descritor de arquivo associado ao dispositivo, que o kernel traduz num comando adequado para os dados atingirem a mídia, como ATA_CMD_FLUSH, SYNCHRONIZE_CACHE, etc. Observando o comportamento do kernel através do strace , estou convicto que, quando o dd chama close() no descritor de arquivo do dispositivo, o kernel automaticamente garante que os dados chegaram na mídia quando a função retorna, não sendo ne

UEFI:NTFS agora suporta secure boot

Ao usar o Rufus com o UEFI:NTFS (quando há arquivo maior do que 4 GiB na mídia de instalação do Windows), era necessário desabilitar secure boot temporariamente para conseguir inicializar pelo pendrive. Não mais a partir do Rufus 3.17. Pete conseguiu fazer a Microsoft assinar o UEFI:NTFS e o driver EFI baseado no NTFS-3G . Portanto, agora funciona com secure boot sem reclamar. Como os binários são públicos, podemos aproveitá-los no processo manual, para Linux, comentado no post Pendrive de instalação do Windows a partir do Linux (II) . Atualizei-o, pois o tamanho da partição para acomodar a imagem aumentou de 512 KiB para 1 MiB. Ou seja, refaçam seus pendrives de instalação do Windows com o Rufus 3.17+!

Linux 5.15 contará com novo driver NTFS

O driver ntfs do Linux é um código deficiente, com suporte à escrita quebrado, e sem manutenção. Tanto que algumas distribuições desativam-no e fornecem apenas o lento NTFS-3G , que roda no espaço de usuário. Depois de um ano de discussão, o novo driver ntfs3 da Paragon foi aceito e estará disponível na versão 5.15. Suporta leitura e escrita, compressão, ACLs, arquivos esparsos, replay do journal — processo de colocar o sistema de arquivos num estado consistente caso não tenha sido desmontado corretamente da última vez. Como todo novo código, será azeitado nos próximos meses, com a Paragon se comprometendo em mantê-lo (lista de discussão aqui ). Considero um driver muito promissor e importante para uma melhor interoperabilidade com o Windows. Os ganhos no desempenho serão significativos e tendem a melhorar com o tempo. Junto com os drivers exfat , presente desde a versão 5.7 , e vfat , fará o kernel ter suporte de primeira aos sistemas de

Windows 11? Meh.

Quanta diferença na minha reação ao Windows 11 (Insider) comparada ao Windows 10 lá em 2014. Naquela época, era uma novidade excitante, importante, pois estávamos com a interface horrenda do 8.1, que ninguém aguentava mais. Hoje, vejo o Windows 11 mais como uma oportunidade para a Microsoft subir a exigência de hardware — com bons propósitos no caso de Secure Boot e Trusted Platform Module —, removendo finalmente a versão x86-32 (e possivelmente suporte ao BIOS/CSM), do que qualquer outra coisa. Se o fizesse no ciclo de vida do Windows 10 arriscaria tomar processo na justiça por todos os lados. Mantendo o 10 rodando em cacarecos até 2025 resolve o problema.

Backup no escuro no Linux

Um dos maiores trunfos do Linux é podermos usar instalações realmente pequenas para funções específicas. Tratarei aqui de um mecanismo de backup automático, sem intervenção do usuário: ao plugar um HDD externo, o mesmo será montado, uma pasta será copiada com o rsync e, por fim, o disco será desmontado e desconectado. A distribuição usada é o openSUSE Leap 15.2, porém pode ser adaptado para qualquer outra [1] . Identifique o dispositivo onde será feito o backup: # blkid /dev/sdb1 /dev/sdb1: LABEL="BACKUP123" UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="ext4" PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Crie a regra para o udev: /etc/udev/rules.d/99-hdd-externo.rules ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext4", ENV{ID_FS_LABEL}=="BACKUP123", TAG+="systemd", ENV{UDISKS_IGNORE}="1", ENV{SYSTEMD_WANTS}+="meubackup@%N.service" ENV{UDISKS_IGNORE}=&

Pendrive de instalação do Windows a partir do Linux (II)

Imagem
No Windows 10 2009 (20H2), o arquivo sources\install.wim passou a ter mais de 4 GiB, o que impossibilita o uso de FAT32. Precisamos recorrer ao NTFS. Sem FAT32, contudo, perdemos a garantia de suporte via UEFI. A saída é o UEFI:NTFS , cujo propósito é ler sistemas de arquivos NTFS ou exFAT do disco em uso e carregar \EFI\BOOT\BOOT<arquitetura>.EFI . Criamos uma pequena partição de 1 MiB [1] , do tipo 0xEF , para abrigá-lo. Usamos a imagem FAT12 do Rufus ( uefi-ntfs.img ), que contém o UEFI:NTFS bem como drivers EFI para NTFS e exFAT . No espaço restante, uma única partição, ativa, do tipo 0x07 . # echo -e ',2048,EF\n,,07,*' | sfdisk --lock=yes --wipe=always --wipe-partitions=always --label=dos /dev/sdx # curl -Ls https://github.com/pbatard/rufus/raw/master/res/uefi/uefi-ntfs.img | dd conv=fsync,notrunc of=/dev/sdx1 Agora criamos o sistema de arquivos NTFS na segunda partição: # mkfs.ntfs -f /dev/sdx2 Caso o alvo seja UEFI, basta m

Windows 10 usa mDNS para resolução de nomes na rede local

Cenário: servidor Linux rodando Samba com clientes Windows. Quando acessamos, num grupo de trabalho, outra máquina na rede local pelo nome, digamos \\CENTOS , o Windows 10 tentará os seguintes protocolos para achá-la: NetBIOS, mDNS e LLMNR. 16:57:54.025570 IP 192.168.2.2.netbios-ns > 192.168.2.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:57:54.025651 IP 192.168.2.2.mdns > 224.0.0.251.mdns: 0 A (QM)? CENTOS.local. (30) 16:57:54.025725 IP6 fe80::f0a4:cbb5:c600:f448.mdns > ff02::fb.mdns: 0 A (QM)? CENTOS.local. (30) 16:57:54.025870 IP 192.168.2.2.mdns > 224.0.0.251.mdns: 0 AAAA (QM)? CENTOS.local. (30) 16:57:54.025929 IP6 fe80::f0a4:cbb5:c600:f448.mdns > ff02::fb.mdns: 0 AAAA (QM)? CENTOS.local. (30) 16:57:54.026235 IP6 fe80::f0a4:cbb5:c600:f448.51438 > ff02::1:3.hostmon: UDP, length 24 16:57:54.026301 IP 192.168.2.2.51438 > 224.0.0.252.hostmon: UDP, length 24 16:57:54.026464 IP6 fe80::f0a4:cbb5:c600:f448.64716 > ff02::1:3.hostmon: UD