quarta-feira, 17 de maio de 2017

Novidades do EXT4

Fiquei um tempo afastado do EXT4. Por mais que mostre sua idade e seja considerado obsoleto pela Red Hat e Oracle, ainda é provavelmente o sistema de arquivos mais usado no mundo Linux.

Existem trezentas opções que podem ser habilitadas ou não no momento da criação do sistema de arquivos. E mais! O mesmo pode ser feito em sistemas existentes. Antes que pensem que acho isso bom: não acho. Porém é assim que os EXT vêm sendo desenvolvidos há décadas; logo, saudemos a tradição!

A partir do kernel 3.5, suporta checksums dos metadados. Considerado estável desde o 3.18. Quão estável? Não tenho ideia.

Parte 1: 64bit

Recurso adicionado na versão 1.42 da suíte e2fsprogs e presente desde o antigo kernel 2.6.28. O mke2fs (e atalho de conveniência mkfs.ext4) cria EXT4 com a opção 64bit ao detectar dispositivo maior que 16 TiB (auto_64-bit_support = 1 em /etc/mke2fs.conf) — mais especificamente 232 * tamanho_do_bloco (em 99% dos casos 4 KiB). Sem ele, não é possível formatar dispositivos acima dessa marca: o comando falhará. Podemos forçar a criação de volumes menores com o recurso habilitado usando a opção -O 64bit. Contudo, existe um bug no mke2fs, que impede o redimensionamento posterior caso o volume seja criado com essa opção e seja maior que o limite imposto pelo endereçamento de 32 bits (improvável usuários domésticos depararem-se com isso). Foi consertado na versão 1.42.10.

A partir da versão 1.43, 64bit é finalmente habilitado por padrão independentemente do tamanho do dispositivo \o/. Tais volumes são suportados desde o GRUB 2.02-beta1.

Parte 2: metadata_csum

Requer e2fsprogs 1.43 ou superior. Funciona melhor junto com 64bit. Por que não é requerido então? Sabe-se lá... coisas dos EXT.

Não interfere na compatibilidade com o GRUB.

Resumo

Tendo uma distribuição com kernel ≥ 3.18, e2fsprogs ≥ 1.43 e GRUB ≥ 2.02-beta1:

# mkfs.ext4 -O metadata_csum /dev/<dispositivo>

Mais ou menos, é equivalente ao XFSv5 no EXT4. Mas... ainda com limite de 16 TiB por arquivo. Há a opção bigalloc para remediar, porém recomendo migrar para outro sistema de arquivos (XFS, Btrfs) caso a limitação impacte seu uso.

terça-feira, 2 de maio de 2017

Compilação oficial do Firefox para Linux requer SSE2

Seguindo o Firefox x86-32 para Windows, a compilação oficial da Mozilla para Linux x86-32 requer processador com SSE2 a partir da versão 53. É compilado com -march=pentium-m -msse -msse2 -mfpmath=sse. Ou seja, o conjunto de instruções do Pentium M, que por sua vez é basicamente o conjunto de instruções do Pentium III + SSE2.

Uma pequena parte do código é compilada com -march=pentiumpro -mno-sse -mno-sse2 -mfpmath=387 para conseguir exibir esta mensagem e finalizar com erro:

This browser version requires a processor with the SSE2 instruction set extension.
You may be able to obtain a version that does not require SSE2 from your Linux distribution.


Não afeta as compilações das distribuições, que definem suas próprias opções.

Lembrando que em x86-64 nada disso interessa, visto que SSE2 sempre está disponível.

domingo, 30 de abril de 2017

Transplantando instalação do XP para o VirtualBox

Pelos mais variados, às vezes absurdos, motivos, cacarecos com Windows XP ainda estão na ativa. Em geral, hardware cambaleante. Um provável meio de lidar com o abacaxi é passá-los para dentro de ambientes virtualizados. Sendo o VirtualBox gratuito, é a solução que usarei aqui.

Existem diversas ferramentas[1] para extrair o conteúdo do disco onde as velharias residem. O Symantec Ghost, o mais clássico dos programas para tal fim, suporta salvar diretamente em VMDK (VMware) desde a versão 11.5 e em VHD (Virtual PC, Hyper-V) desde a 12.

No entanto, usando a GUI do programa, não é possível salvar nesses formatos. Só permite fazê-lo no seu formato nativo GHO. Recorremos então à linha de comando.

O gdisk32 chamado sem argumentos nos dá os índices de cada dispositivo (estou rodando-o no Windows PE):

Disk  Partitions  Cylinders  Heads  Sectors  Mbytes  Model
  1        1        14593     255      63  114473.5  PH4-CE120
  2        1        38913     255      63  305245.3  WDC WD32 00BPVT-22JJ5T0 01

Com isso, acertamos src= nos comandos abaixo de acordo com a coluna "Disk".

VMDK:

ghost32 -clone,mode=create,src=1,dst=<unidade>:\caminho\imagem.vmdk -batch

Para salvar em VHD[2], basta mudar a extensão:

ghost32 -clone,mode=create,src=1,dst=<unidade>:\caminho\imagem.vhd -batch

Ambos formatos são suportados pelo VirtualBox. Prefiro VHD pois podemos montá-lo pelo Windows Explorer desde o 8. No 7, também é possível, porém sem a mesma praticidade, porque precisa ser feito via Gerenciamento de disco ou diskpart.

Agora, basta criar nova máquina virtual do tipo Windows XP (32-bit)[3] e usar a imagem VHD existente como disco. Detalhe importante! Até o XP, havia a salada de HALs! Caso o PC de origem use um dos HALs APIC (ACPI Uniprocessor PC ou ACPI Multiprocessor PC), você precisa marcar a opção "Habilitar o I/O APIC" nas propriedades, do contrário não iniciará:


Por fim, instale os Adicionais para Convidado.

Se você tiver imagens GHO, pode convertê-las para VMDK ou VHD usando o próprio Ghost:

ghost32 -clone,mode=restore,src=<unidade>:\caminho\imagem.gho,dst=<unidade>:\caminho\imagem.vmdk -batch
ghost32 -clone,mode=restore,src=<unidade>:\caminho\imagem.gho,dst=<unidade>:\caminho\imagem.vhd -batch


[1] O popular Disk2vhd é uma alternativa.
[2] VHD tem limite de ~2 TiB. O Ghost não suporta VHDX, formato mais novo, introduzido no Windows 8.1, sem a limitação. Nem faria diferença, pois igualmente não funciona no VirtualBox.
[3] Nem considerei o XP 64-bit pois é um Unicórnio. Em máquinas virtuais XP, o VirtualBox configura o controlador de disco IDE, que deve iniciar com qualquer instalação.

sexta-feira, 21 de abril de 2017

O útil blkdiscard

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. 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*, pois com a opção -z (--zeroout) faz o mesmo que o dd faria:

# blkdiscard -z -v /dev/sdxy

blkdiscard -z usa a requisição BLKZEROOUT da chamada de sistema ioctl().

Com -v, mostra um sumário ao término do processo.

Versão mínima requerida do kernel é 2.6.28 (BLKDISCARD) e 3.7 (BLKZEROOUT) e a ferramenta existe desde a versão 2.23 da suíte util-linux.


* Não recomendo rodá-lo em áreas grandes demais, maiores do que alguns gigabytes, de discos rígidos. Enquanto a chamada de sistema não retornar, o processo fica no estado uninterruptible sleep e não pode ser terminado manualmente.

sexta-feira, 7 de abril de 2017

quarta-feira, 5 de abril de 2017

Unity e Mir estão mortos

Ubuntu Unity is dead: Desktop will switch back to GNOME next year (Ars Technica)

Vão para a cova ao lado da ocupada pelo Upstart. Que descansem em paz. GNOME + Wayland a partir do Ubuntu 18.04 LTS.

Visto que são projetos cobertos por CLA, não é de estranhar que tenham morrido...

A divisão desnecessária causada pelo Mir tem um fim com esse anúncio. Tivesse a Canonical não despejado FUD sobre o Wayland quando iniciou sua aventura solo sem apoio comunitário, talvez hoje tivéssemos o protocolo Wayland em estágio de desenvolvimento mais avançado bem como melhores compositores.

domingo, 2 de abril de 2017

Autoconfiguração de proxy com NetworkManager + PACRunner

No NetworkManager 1.6, temos novidades na forma de lidar com configuração automática de proxies. Agora, o NM pode obter a configuração via WPAD (DHCP) e enviá-la ao PACRunner, outro daemon, ativado via D-Bus, que trata de processar o JavaScript recebido e responder às requisições dos clientes. Os proxies podem ser configurados de acordo com a interface, caso mais de uma exista.

Os clientes falam diretamente com o PACRunner usando sua interface via D-Bus, ou, para os que linkam a libproxy, uma biblioteca de compatibilidade provida pelo daemon faz o mesmo. Essa biblioteca substitui a libproxy original, sendo mais simples e eficiente. Trabalha apenas consultando-o via D-Bus.

O design está aqui: https://wiki.gnome.org/Projects/NetworkManager/Proxies

        +----------------+
        | NetworkManager |
        +----------------+
                |
                | D-Bus (org.pacrunner.Manager.CreateProxyConfiguration)
                v
        +----------------+         +-----------+
        |   PACRunner    | <---->  | v8, mozjs |
        +----------------+         +-----------+
            ^         ^
            |          \ D-Bus (org.pacrunner.Client.FindProxyForURL)
            |           +----------+
            |                       \
            |                        v
            |             +----------------------+
            |             |                      |
            |             |    libproxy.so do    |
            |             |      PACRunner       |
            |             |   (API compatível)   |
            |             |                      |
            |             +----------------------+
            |                        ^
            |                        | libproxy API (px_proxy_factory_get_proxies)
            |                        v
            |                  +-----------+
            |                  | Cliente 2 |
            |                  +-----------+
            |
            | D-Bus (org.pacrunner.Client.FindProxyForURL)
            v
      +-----------+
      | Cliente 1 |
      +-----------+

Nem tudo são flores

E se o cliente não conversar com o PACRunner via D-Bus nem linkar a libproxy? Daí restam as variáveis de ambiente, que são terrivelmente problemáticas com autoconfiguração de proxy e não são suportadas pelo PACRunner.

Arch e openSUSE não empacotam o PACRunner. Já a versão que está no Fedora é velha demais e é compilada com --disable-libproxy.

Bugs

NetworkManager 1.6.2 (última versão estável enquanto escrevo) não envia a configuração ao PACRunner (BGO#780558).

Ainda ruim

Autoconfiguração de proxy no GNU/Linux tem avançado a passos de tartaruga. O esqueleto de uma configuração funcional existe; os clientes, contudo, precisam parar de depender de variáveis de ambiente. Visto que a libproxy possui uma API simples, o ecosistema poderia padronizar nela a tarefa de lidar com proxies. Dos componentes básicos, a libcurl é usada por muitos códigos que acessam a internet. Precisaria ser a primeira a passar a usá-la (patch existe).

sábado, 18 de março de 2017

Pavilion 14-n050br que não desliga

Este notebook HP Pavilion 14-n050br (E7J04LA#AC4) estava com o mesmo problema do Dell do post anterior. Veio de fábrica com o Windows 8, posteriormente atualizado para o 8.1 e depois 10. A última instalação do 10 foi limpa, em UEFI com Secure Boot habilitado.

Felizmente bastou atualizar o firmware da versão F.66 para a F.70 e foi resolvido. O driver Intel MEI ficou na versão instalada pelo próprio Windows 10 1607 (11.0.0.1146).

[Atualização - 24/03/2017] Escrevi cedo demais. Ocasionalmente ainda falhava. Atualizei o driver Intel MEI para esta versão 11.0.0.1177 e até agora não incomodou.

quinta-feira, 9 de março de 2017

Inspiron 5547 que não desliga

Este notebook Dell Inspiron 5547 (etiqueta de serviço 3SSFM22) não desligava. Veio com Windows 8, posteriormente atualizado para o 10 (instalação limpa). Primeira providência foi atualizar o firmware da versão A07 para a A10 (na A08 o Windows 10 passou a ser oficialmente suportado). No entanto, continuou o problema.

Solucionei instalando driver mais recente da Intel Management Engine Interface (11.0.0.1173):

http://www.dell.com/support/home/br/pt/brdhs1/Drivers/DriversDetails?driverId=3MD6D

A versão instalada pelo Windows 10 1607 era a 11.0.0.1146.

Complica o fato do driver listado no site da Dell para o modelo ser obsoleto e não resolver nada (o link acima é do Inspiron 5557).

sexta-feira, 3 de março de 2017

A boca livre não terminou

Havia testado o caso de máquinas com chaves do 8 e 8.1 salvas no firmware, nas quais podemos atualizar para o Windows 10 diretamente através de instalação limpa com a mídia adequada, mesmo após o encerramento em 29 de julho de 2016 da campanha de atualização em massa.

Hoje, fiz o teste que faltava: a partir do Windows 7, coloquei a mídia equivalente do 10 e rodei setup.exe. Atualizou e ativou.

Portanto, apenas foi descontinuado o mecanismo via Windows Update. Fazendo na mão continua sendo possível.

sexta-feira, 17 de fevereiro de 2017

Ghost 12 suporta (com bugs) EXT4

Desde 2015, o venerável Symantec Ghost[1], parte da Ghost Solution Suite (atualmente na versão 3.1), voltou a ser atualizado, saindo da cansada versão 11.5.1 para a 12. Além de suportar oficialmente os Windows modernos (ver esta tabela), também trouxe suporte[2] ao sistema de arquivos EXT4. Na 11.5.1, suportava apenas EXT2 e EXT3. Volumes EXT4 eram rejeitados com um tal erro 652 (Attempted to access an inconsistent Linux partition). Estranho não ter uma palavra sobre a novidade nas notas de lançamento.


A versão 12 preserva todas as características de volumes EXT4 formatados com o mke2fs da série 1.42[3] (via mkfs.ext4), com exceção de uninit_bg, que faz pouca diferença, pois afeta apenas o tempo requerido pelo e2fsck para verificar o sistema de arquivos.

No entanto, se o sistema de arquivos tiver o recurso 64bit habilitado (a partir do mke2fs 1.43 o é por padrão), daí o programa falha por completo. Não é exibido erro algum ao criar e restaurar a imagem, porém o sistema de arquivos fica totalmente corrompido depois de restaurado. Provavelmente o pessoal da Symantec está testando seu código usando distribuições velhas como referência. Vamos ver se em versões futuras (depois da 12.0.0.8065; GSS 3.1 MP5) arrumam esse problema. [Atualização - 07/04/2017] Resolvido na versão 12.0.0.10517.


[1] Existe uma confusão entre Norton Ghost e Symantec Ghost. Ver este meu post no fórum CdH sobre isso.
[2] Significa salvar só os dados, recriando o sistema de arquivos no momento da restauração, já entregando-o redimensionado caso necessário. Dessa maneira, o tamanho da imagem é otimizado. Similar ao FSArchiver. Não é uma cópia bit a bit como o dd faria.
[3] Até a 1.42, auto_64-bit_support = 1 era configurado em /etc/mke2fs.conf: habilitava 64bit apenas em volumes maiores que 16 TiB. Ou seja, na prática, na esmagadora maioria das instalações, o recurso não estava presente. Na 1.43, passou a ser sempre habilitado — o mesmo comportamento foi backportado para o pacote 1.42.9 do RHEL 7.

sábado, 11 de fevereiro de 2017

systemctl enable|disable|mask --now

A partir do systemd 220, a opção --now poupa uma invocação adicional do systemctl quando queremos habilitar e iniciar, ou desabilitar e parar um daemon.

# systemctl enable xxx.service
# systemctl start xxx.service

               |
               v

# systemctl enable --now xxx.service

# systemctl disable xxx.service
# systemctl stop xxx.service

               |
               v

# systemctl disable --now xxx.service

# systemctl mask xxx.service
# systemctl stop xxx.service

               |
               v

# systemctl mask --now xxx.service

Melhor de tudo: a equipe da Red Hat backportou o recurso para a versão 219 do RHEL 7.2.

quinta-feira, 9 de fevereiro de 2017

segunda-feira, 30 de janeiro de 2017

Bugs do Firefox para monitorar (II)

Mais dois bugs do Firefox me interessam no momento.

https://bugzilla.mozilla.org/show_bug.cgi?id=1207306

A partir do Firefox 49, separou-se o processo que renderiza a interface do que renderiza o conteúdo das páginas. Ainda assim, todas as abas continuam compartilhando um único processo. Nesse primeiro passo, o objetivo foi fazer a interface sempre ser responsiva. Usuários antigos devem lembrar como era irritante uma página pesada acabar com a responsividade da interface. Isso pelo menos está resolvido. Contudo, uma aba mal comportada ainda deixa as outras esperando. A solução virá com o projeto e10s-multi, que aproximará o Fx dos demais navegadores modernos, separando grupos de abas em diferentes processos.

https://bugzilla.mozilla.org/show_bug.cgi?id=336193

Para sistemas Unix-like. Fazer o navegador finalizar de forma limpa ao receber SIGTERM. Hoje, um killall firefox realiza uma finalização forçada, que causa o travamento do plugin-container e dispara a restauração de abas na próxima vez em que o programa iniciar. Bug constrangedor, que tem mais de 10 anos.