O instalador de VPN diz 32 bits: verifique o cabeçalho ELF

Uma página de download diz 32 bits, o arquivo aterrissa num Raspberry Pi e o instalador falha com uma mensagem que não nomeia nenhuma parte útil do problema. Dois executáveis completamente diferentes contam ambos como 32 bits no sentido ELF, e só um deles pode rodar nessa placa. O campo de classe é um fato, o campo de máquina é outro, e um nome de arquivo não lhe diz de forma confiável nenhum dos dois. Leia o cabeçalho antes de mudar uma biblioteca ou experimentar outro espelho.

A classe diz o tamanho da palavra, a máquina diz o conjunto de instruções

A referência ELF do Linux define um campo de classe e um campo de máquina no cabeçalho do arquivo, e os dois respondem a perguntas diferentes. A classe diz se o arquivo usa a forma de 32 bits ou a de 64 bits; a máquina diz para que conjunto de instruções foi compilado. Uma compilação x86 de 32 bits e uma compilação ARM de 32 bits concordam no primeiro e divergem no segundo. É assim que um rótulo que promete o tamanho de palavra certo entrega igualmente código que o processador não consegue decodificar. O terceiro valor que vale a pena ler é o interpretador solicitado, que os cabeçalhos de programa nomeiam quando o binário declara um.

readelf -h -- ./vendor-vpn
readelf -l -- ./vendor-vpn
readelf -d -- ./vendor-vpn | grep NEEDED

O primeiro comando imprime o cabeçalho, o segundo imprime os cabeçalhos de programa quando o arquivo tem alguns, e o terceiro lista os objetos compartilhados de que o carregador vai precisar. Registre classe, máquina e interpretador juntos, porque esses três valores são toda a questão de compatibilidade nesta camada. Nenhum dos três aparece num botão de download, por isso o arquivo tem de ser inspecionado e não descrito.

Que interpretador pede ao núcleo

Um executável que declara um interpretador pede ao núcleo um caminho de carregador concreto. Quando esse carregador falta, o arranque falha mesmo que o arquivo que você indicou esteja ali mesmo. É o ponto em que as pessoas decidem que o download está corrompido, quando a resposta real é um carregador que a distribuição não fornece.

Combine o carregador com o sistema que você realmente executa: a versão do sistema operacional, a arquitetura do espaço do usuário e o pacote que fornece o carregador. Um núcleo de 64 bits só pode executar um espaço do usuário de 32 bits quando esse espaço e o seu carregador estão instalados, então as capacidades do processador não são o fator decisivo. Uma verificação curta nomeia o interpretador numa única linha, e demora menos tempo do que um ticket de suporte. Um script de shell falha ainda de outra maneira, porque o seu interpretador é nomeado na primeira linha e não num cabeçalho ELF, e ler essa linha não custa nada.

file --brief ./vendor-vpn

Combine o download com a arquitetura do pacote

As arquiteturas de pacote das distribuições codificam a mesma distinção no seu próprio vocabulário, e é a esse vocabulário que se refere a declaração de suporte de um fornecedor. Compare o valor que o seu gerenciador de pacotes reporta com o valor que o fornecedor documenta, em vez de comparar um rótulo de marketing com um nome de arquivo. Os pares que causam problemas são amd64 contra arm64, e armhf contra armel, porque cada par parece intercambiável numa lista de download. Um nome de arquivo que termina em x64 ou ia32 descreve um alvo de compilação, não a máquina que o contém.

Cada linha é um caso em que o tamanho da palavra parece correto e o código continua a se comportar mal, ou em que arranca e depois falha uma camada mais abaixo. Leia a coluna de interpretador como um requisito rígido e não como uma pista, porque o núcleo resolve esse caminho antes de qualquer código seu ser executado. A emulação é uma decisão de implantação com as suas próprias consequências de desempenho e suporte, e nunca é implicada por um processador que anuncia um tamanho de palavra maior.

dpkg --print-architecture

ENOEXEC e ENOENT são falhas diferentes

A fase de arranque reporta um de dois erros, e apontam para problemas diferentes. Ler o valor do erro classifica a falha antes de executar qualquer outra coisa.

ENOEXEC significa que o formato não foi reconhecido: arquitetura errada, classe errada ou algo que não é de todo um executável. ENOENT num arquivo ELF significa normalmente que falta o interpretador, embora o arquivo que você pediu exista. O mesmo ENOENT também pode significar que falta o interpretador de um script, e é por isso que a primeira linha de um script importa. De qualquer forma a mensagem nomeia a camada, e tratar cada «não encontrado» como configuração ausente envia a investigação na direção errada. Cite o valor do erro no ticket, porque sobrevive melhor à recontagem do que a frase que o rodeia.

O que não fazer quando o binário não arranca

Forçar um binário não explicado através de um invólucro de shell não o faz funcionar. Não execute um verificador de dependências com leviandade num arquivo em que não confia, porque executá-lo pode rodar código do binário em algumas circunstâncias. Não acrescente ligações simbólicas do carregador, não troque bibliotecas do host nem baixe um arquivo antigo de um espelho de terceiros para contornar a mensagem. Cada uma dessas coisas amplia a superfície de alteração sem tocar na discrepância que o cabeçalho já nomeou.

Quando contatar o fornecedor, envie valores e não uma história: a versão do sistema operacional, a arquitetura do pacote, as cadeias de classe e máquina, o interpretador solicitado e a primeira linha de erro. Esse conjunto resolve as perguntas de suporte mais depressa do que uma captura de tela de um instalador que falha. Artefatos antigos e saídas de fórum memorizadas não são uma matriz de suporte atual, e uma vez que um binário nativo carrega, perfil, autenticação e roteamento continuam a ser trabalho separado.