Estou vendo algo realmente estranho dentro de um armelambiente Debian com chroot .
Mas primeiro, um pouco da história de fundo ... Isso é longo, mas a pergunta é complexa e qualquer ajuda em potencial depende do conhecimento da história completa.
Eu tenho um ARM SoC incorporado que executa o Linux - mais especificamente, um Debian armelLenny em um kernel 2.6.17. A distribuição Debian em si é facilmente atualizável para versões posteriores ( sudo apt-get dist-upgrade) e, portanto, pode ser atualizada, para as armelversões
squeezeou mesmo wheezy.
O problema é que o kernel é personalizado ... O ARM SoC em questão não faz parte do kernel da linha principal, portanto é praticamente abandonado na 2.6.17.
Se você sabe como o Linux e o GLIBC funcionam, já pode ver o problema - as versões do GLIBC são compiladas com uma versão mínima suportada do kernel ... Que foi além da 2.6.17. Portanto, se tentarmos, por exemplo, chroot para um aperto do Debian ...
$ # From inside the little ARM machine running Debian Lenny
$ sudo debootstrap --arch armel squeeze /squeeze \
http://ftp.whateverCountry.debian.org/debian
$ sudo -i
# mount -t proc none /squeeze/proc
# mount -t sysfs none /squeeze/sys
# mount -t devpts none /squeeze/dev/pts
# chroot /squeeze
Fatal: Kernel too old
... vemos uma mensagem do GLIBC de squeeze, informando que não foi compilado para trabalhar com este kernel antigo (2.6.17).
O mesmo problema também acontece com o wheezy - já que é mais novo que o squeeze - e de fato acontecerá com qualquer versão do Debian a partir de agora, já que o GLIBC não funcionará no meu kernel 2.6.17.
No começo, pensei que isso era um rompimento de acordos - mas então percebi que, em teoria, recompilei o GLIBC para trabalhar com o kernel mais antigo que meu SoC está usando ... Mas eu precisaria de um ambiente idêntico ao usado para criar a libc6 pacote, por exemplo, no Debian squeeze.
Eu estou supondo que a compilação do GLIBC e a preparação do arquivo libc6_2.11.3-4.deb sejam feitas através de máquinas automáticas de compilação cruzada inventadas pelos deuses do Debian.
Eu não sou Deus ... nem encontrei nada no Google sobre como se tornar um - ou seja, como usar o Core i5 como host, para compilar o GLIBC usando exatamente as mesmas configurações da versão em pacote (dentro do Debian squeeze) usando.
Então, eu o enganei - eu descobri como configurar a versão ARM do Debian squeeze no meu Core i5 (uma técnica que usa uma versão estática do qemu-armbinário).
Depois de fazer o chroot na minha versão hospedada em x86 Debian-armel-squeeze, consegui simplesmente ...
$ cd /var/tmp
$ apt-get source libc6
...
$ # edit this in - compile for my kernel...
$ vi eglibc-2.11.3/debian/sysdeps/linux.mk
...
MIN_KERNEL_SUPPORTED := 2.6.17
...
$ export DEB_BUILD_OPTS="nocheck parallel=1"
$ cd eglibc-2.11.3
$ dpkg-buildpackage -b -d -us -uc
... e após 3 horas (a versão chroot hospedada no Core i5
Debian-armel-squeezeé muito mais lenta que uma máquina nativa ...), recebi meu pacote libc6 .deb. Provavelmente levaria três meses para fazer essa compilação no meu SoC, então não estou reclamando.
Voltando ao meu verdadeiro ARM SoC, copiei todos os arquivos libc (.so) do novo pacote sobre os arquivos padrão do squeeze e tentei chroot ...
# chroot squeeze/
root@ttsiodras:/#
Sim! Funcionou! (ou assim parecia)
Minha libc personalizada relatada de dentro do chroot:
# /lib/libc.so.6
GNU C Library (Debian EGLIBC 2.11.3-4) stable release version 2.11.3, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.5.
Compiled on a Linux 2.6.26 system on 2014-10-23.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
As coisas pareciam funcionar - copiei um arquivo, invoquei ls...
Mas quando tentei usar apt-getpara instalar alguns aplicativos squeeze, comecei a receber ... alguns erros inesperados:
# apt-get install indent
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
indent
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 110 kB of archives.
After this operation, 516 kB of additional disk space will be used.
Get:1 http://ftp.gr.debian.org/debian/ squeeze/main indent armel 2.2.11-1 [110 kB]
Fetched 110 kB in 0s (236 kB/s)
tar: ./control: Cannot utime: Function not implemented
tar: ./md5sums: Cannot utime: Function not implemented
tar: .: Cannot utime: Function not implemented
tar: Exiting with failure status due to previous errors
dpkg-deb: subprocess tar returned error exit status 2
dpkg: error processing /var/cache/apt/archives/indent_2.2.11-1_armel.deb (--unpack):
subprocess dpkg-deb --control returned error exit status 2
configured to not write apport reports
rm: cannot remove `/var/lib/dpkg/tmp.ci': Function not implemented
dpkg: error while cleaning up:
subprocess rm cleanup returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/indent_2.2.11-1_armel.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Oh-oh ... um monte de Function not implemented. Parece o GLIBC relatando que coisas básicas não estão funcionando ...
Eu consegui strace (não pergunte como) e descobri que todas as -atfunções estão falhando: openat, mkdirat, renameat, etc - todos eles são ENOSYS relatórios.
Parece que tive sucesso apenas parcialmente - algumas chamadas do sistema estão falhando no meu novo GLIBC.
É impossível compilar um squeezeou wheezeGLIBC para executar sob 2.6.17?
Quaisquer ideias / sugestões sobre o que fiz de errado e / ou como proceder serão muito apreciadas ...