Caixa Seca

O finado Zero Linux dava trabalho para manter, pois muita coisa era compilada na mão. Um Linux pequeno , de modo texto, que rodasse da memória, ainda me fazia falta para tarefas de apagamento de unidades de disco, tendo alguns programas adicionais para outros fins. Cheguei à conclusão que poderia aproveitar praticamente tudo do Fedora, ganhando de brinde suporte ao secure boot. Aqui está! Download: https://www.mediafire.com/folder/xr3hzopxkj68n/zerong Binários do Fedora, espinha dorsal em C , dois programas caseiros ( limpadsk , rmusbbdev ) e uns shell scripts auxiliares. Inicia tanto em BIOS/CSM quanto UEFI. Secure boot suportado [1] . Pendrive pode ser criado com o Rufus . Extraindo o conteúdo do arquivo ISO para um pendrive em FAT/FAT32 automaticamente funcionará em UEFI sem ajustes adicionais. Gravação com o dd não é suportada. Esta é uma atualização do texto publicado originalmente em agosto de 2022, motivada por duas mudan...

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...

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 -...

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...

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-...

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ê...

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...

É 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...

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+!

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}=...

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...

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...

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.

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...

Não valia mais o trabalho de mantê-lo Tudo que me interessava nos shells scripts do Zero Linux implementei em C neste programinha: https://github.com/marcosfrm/limpadsk

openSUSE Leap 15.0+ cria por padrão particionamento GPT mesmo ao inicializar via BIOS. Para usar MBR, recorra ao particionador avançado, clique em "Avançado..." e depois em "Criar nova tabela de partição". Selecione então "MS-DOS (estilo clássico)". Daí para frente, crie as partições a gosto.

Os programas cfdisk , fdisk e sfdisk , da suíte util-linux, voltaram a ser desenvolvidos de uns anos para cá. São particionadores modernos, que levam em conta a topologia do disco ao alinhar as partições e suportam GPT. Me concentrarei no sfdisk , a ferramenta scriptável. Existem duas formas de fornecer-lhe entrada . Esta é mais simples: início tamanho tipo booteável Os campos são separados por espaços, vírgulas ou ponto e vírgulas (uso vírgulas). Ao ser omitido, o programa adota um valor padrão para cada campo: início: primeiro setor livre tamanho: máximo disponível tipo: partição Linux, 0x83 (MBR/MS-DOS), 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (GPT) (ver sfdisk(8) para outros tipos) booteável: desabilitado (MBR/MS-DOS apenas) Ao criar mais de uma partição, cada uma é representada por uma linha. Exemplo: ,50G,L,* ,,L Primeira linha: - início: vazio (nada antes da vírgula), corresponde ao primeiro setor disponível, que, num disco limpo, considerando...

Todo mundo conhece o fstrim , que instrui o sistema de arquivos a avisar ao SSD quais blocos não está mais usando. Digamos que temos uma partição e que desejamos apagar sua área por completo. Tradicionalmente, usaríamos algo como: # dd if=/dev/zero of=/dev/sdxy bs=4k Contudo, com SSDs, existe uma forma mais rápida e prática: # blkdiscard -v /dev/sdxy Esse comando usa a requisição BLKDISCARD da chamada de sistema ioctl() e nos entrega a área que compreende a partição /dev/sdxy zerada [1] . Por usar o comando ATA TRIM, é rápido. Não funciona com discos rígidos. Neles, o kernel retorna erro e o comando avisa que não há suporte. Ou seja, blkdiscard é análogo ao fstrim , porém trabalha no nível do dispositivo de bloco, não do sistema de arquivos. Pode ser usado no disco inteiro também ( /dev/sdx ). Mesmo com HDDs, pode ser útil em certos casos [2] , pois com a opção -z ( --zeroout ) faz o mesmo que o dd faria: # blkdiscard -z -v /dev/sdxy blkdiscard -z usa a requisi...

A opção de montagem discard em geral prejudica o desempenho, pois os comandos TRIM esvaziam a fila NCQ, aumentando a latência. A especificação SATA 3.1 (julho de 2011) traz NCQ TRIM, async TRIM , que não drena a fila e, em teoria™, não prejudica o desempenho [1] . Foi adicionado ao kernel 3.12: libata: Add support for SEND/RECEIVE FPDMA QUEUED libata: Add support for queued DSM TRIM O dispositivo precisa dizer ao sistema operacional que suporta o recurso. De alguns anos para cá, estão disponíveis SSDs com a tecnologia no mercado. Infelizmente, com uma tonelada de bugs. Muitos firmwares simplesmente corrompem dados ao receberem comandos NCQ TRIM. Foi necessário criar uma lista negra de modelos e versões de firmware com suporte quebrado (ver arquivo drivers/ata/libata-core.c no código fonte do kernel). Na versão 4.2, ficou mais fácil ver o estado do suporte via sysfs, bem como habilitar ou não através de opções de boot: libata: Expose TRIM capability in sysfs libata: Allow...

Quando formatamos um dispositivo de armazenamento, colocamos um sistema arquivos numa região delimitada. Às ferramentas que os criam, precisamos dizer qual área compreenderá essa região. Tradicionalmente, especificamos um dispositivo de bloco como /dev/sdc1 . Imagine um disco de 2 MiB (2097152 bytes) com setores de 512 bytes (4096 setores), particionamento MBR (MS-DOS) e uma única partição primária. Disco /dev/sdc +----------------------------------------------------------------------------+ | Espaço não | | particionado | | +--------------+ / \ +----------------------------------------+ | | | MBR, tabela | | Partição 1 | | | | de partições | | /dev/sdc1 | | | | | | ...