Caixa Seca

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

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

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.

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