Postagens

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 512 KiB [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 ',1024,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 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 montar /de

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

Backup do registro no Windows 10

No Windows 10 1803, com objetivo de diminuir o uso de disco, a Microsoft desativou o backup automático do registro , salvo em %SYSTEMROOT%\system32\config\RegBack . Pode ser restaurado com facilidade sobrescrevendo os arquivos de mesmo nome uma pasta abaixo. Para quem tem espaço e poder de processamento sobrando, sugiro ativar novamente. É um backup que numa improvável eventualidade pode salvar a lavoura — particularmente o SYSTEM . Basta importar: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager] "EnablePeriodicBackup"=dword:00000001 Não consegui descobrir exatamente como funciona o agendamento. É feito uma vez a cada uma ou duas semanas mais ou menos.

Pendrive de instalação do Windows a partir do Linux

Pergunta que de quando em quando aparece nos fóruns. Há ferramentas aos moldes do excelente Rufus para Linux, acho. Dá também para rodá-lo dentro de uma máquina virtual com Windows, conectando o dispositivo USB ao sistema operacional convidado. Tratarei aqui da forma manual, entretanto. Não é muito complicado. Precisamos de particionamento MBR (MS-DOS), que serve tanto para instalar em Legacy/CSM quanto UEFI, com uma partição formatada em FAT32. O particionamento é tranquilo. Pode ser feito via cfdisk , fdisk ou sfdisk , bem como parted ou GParted. A partição precisa ser marcada como ativa para funcionar no modo Legacy/CSM. Usando como exemplo /dev/sdx . Comandinho mágico : # echo ',,0c,*' | sfdisk --lock=yes --wipe=always --wipe-partitions=always --label=dos /dev/sdx (tipo 0x0c : FAT32 LBA) Depois criamos o sistema de arquivos FAT32: # mkfs.fat -F 32 -v /dev/sdx1 Caso o alvo seja UEFI, basta montar /dev/sdx1 e extrair o conteúdo do

Como está o suporte ao Linux do Ghost (agosto/2020)

Imagem
Novidades desde a última vez . A partir da versão 12.0.0.11181 (Ghost Solution Suite 3.3 RU4) e 12.0.0.11197 (Deployment Solution 8.5 RU4) [1] : - EXT4 com recurso metadata_csum ainda é problemático. Captura funciona pelo menos, com reclamação. Não é mantido ao restaurar. EXT4 com metadata_csum - XFS é suportado. Desde a 12.0.0.10618, há a opção -ISR , que habilita um tal de "Smart Raw Imaging for use with XFS filesystems", cuja descrição é "only sectors that by along with their locations on disk rather than capturing full disk sectors". Na nova versão, a opção passou a ser habilitada automaticamente. Pelo jeito, o formato do arquivo mudou, pois a Broadcom diz que imagens contendo XFS criadas com versões anteriores precisam ser refeitas. Pelo pouco que pude testar, funciona direito. - Aliás, agora é Broadcom Ghost, pois a Symantec foi vendida. - Clonagem de disco

Opção --lock das ferramentas da suíte util-linux

A partir da versão 2.36, os programas da suíte util-linux que lidam com particionamento e sistema de arquivos ganharam a opção --lock=<modo> e a variável de ambiente LOCK_BLOCK_DEVICE=<modo> para ativar a supressão de processamento do udev. Veja o post Usando o sfdisk para detalhes. Enquanto escrevo, existe suporte no fdisk , cfdisk , sfdisk , mkswap , wipefs . Modos disponíveis: 1 ou yes → aguarda eventual trava ativa ser removida (recomendado). 0 ou no → ignora trava (comportamento anterior), padrão se a opção não for especificada. nonblock → retorna erro se existir trava ativa. <ferramenta> --lock=yes /dev/sdx e LOCK_BLOCK_DEVICE=yes <ferramenta> /dev/sdx terão o mesmo resultado.

limpadsk 1.2

Dias desses chegou às minhas mãos um disco rígido contendo uma instalação do Windows 8.1 no particionamento MBR. Ao limpá-lo com o wipefs , havia em algum lugar uma assinatura de tabela de partições atari ! Não me pergunte como foi parar lá. O insólito caso me inspirou a modificar meu programinha limpadsk para mostrar o que é apagado pela libblkid. Comecei a fuçar no código até concluir que estava reimplementando, de forma piorada, o wipefs . Levando em conta que faz parte da suíte util-linux, um pacote básico, podemos ter por garantido que estará presente na maioria das instalações. A nova versão, portanto, não depende mais da libblkid. Via fork()/exec() chama wipefs --all --force , tendo como argumentos o dispositivo e suas partições, caso existentes. Exemplo: # limpadsk /dev/sdb /dev/sdb2: 8 bytes were erased at offset 0x00000003 (ntfs): 4e 54 46 53 20 20 20 20 /dev/sdb2: 2 bytes were erased at offset 0x000001fe (dos): 55 aa /dev/sdb1: 8 bytes wer

Inicialização via USB na placa-mãe Intel D101GGC

Imagem
Estamos em 2020 com as implementações UEFI prestes a removerem o Compatibility Support Module (CSM). Ainda assim, cá estou eu falando de uma placa-mãe de 15 anos atrás: Intel D101GGC (soquete 775, DDR1!) com BIOS 0313. Se a memória não me falha, foi o único modelo da marca a usar chipset ATI (Radeon Xpress 200). Pendrive de 16 GB com particionamento MBR criado pelo Rufus. Partição, ativa, iniciando no setor 2048 (alinhamento por MiB ). Código de boot do GRUB4DOS no MBR. Sistema de arquivos FAT32. Não inicializa. Estar detectando o dispositivo como drive ZIP é uma pista. No setup tem esta opção (Advanced → USB Configuration → USB ZIP Emulation Type): Padrão é Auto … que usa emulação Floppy . Mudando-a para HDD faz funcionar: Não lembro de placas de outros fabricantes oferecerem esse ajuste. A propósito, olha a relíquia que é o processador da máquina: # lscpu Architecture: x86_64 CPU op-mode(s):

Cuidado com pastas criadas na raiz da unidade C:

Imagem
Tenho uma pasta na raiz da unidade C: onde coloco alguns programas úteis. Está presente na variável de ambiente PATH do sistema. As ACLs padrão da raiz da unidade dão permissão de escrita, em todas as pastas ali criadas — propagada ao conteúdo descendente —, a todos os usuários autenticados (que tenham feito logon), incluindo quem não é administrador. Diferente das pastas C:\Program Files e C:\Program Files (x86) , tipicamente usadas para tais fins, que não possuem permissão de escrita para usuários limitados. Por isso alguns programas burros, que não fazem diferenciação entre o território do sistema operacional e do usuário , criam pastas diretamente na unidade C: . Qualquer usuário autenticado pode escrever ali, não sendo necessário usar o perfil. Nosso maior exemplo são os programas da Receita Federal, cuja pasta é C:\Arquivos de Programas RFB . Contudo, como minha pasta está no PATH , é um problema! Pode ser usada para ataques de DLL preloading . É imperativo remover a per

Discos rígidos SMR estão aparecendo silenciosamente

Imagem
Buyer beware—that 2TB-6TB “NAS” drive you’ve been eyeing might be SMR (Ars Technica) Western Digital admits 2TB-6TB WD Red NAS drives use shingled magnetic recording (Blocks & Files) A tecnologia tradicional usada nos discos rígidos chama-se Perpendicular Magnetic Recording (PMR) [1] e permite que qualquer setor físico ( 4 KiB ) seja escrito e reescrito sem restrições. Com finalidade de aumentar a capacidade de armazenamento, foi criada a tecnologia Shingled Magnetic Recording (SMR): What is Shingled Magnetic Recording (SMR)? (StorageReview) Methods of SMR Data Management (StorageReview) SMR in disk drives: PC vendors also need to be transparent (Blocks & Files) Shingled hard drives have non-shingled zones for caching writes (Blocks & Files) Bem resumidamente, discos rígidos SMR possuem, de forma similar aos SSDs, o conceito de erase block . A granularidade do apagamento é maior do que um setor de 4 KiB: apenas zonas inteiras, compreendendo vários setore