Estou vendo algo realmente estranho dentro de um ambiente Debian armel chroot.
Mas primeiro, um pouco de história de fundo ... Isso é longo, mas a questão
é complexo e qualquer ajuda em potencial depende de saber a história completa.
Eu tenho um SoC ARM embutido que roda o Linux - mais especificamente,
um Debian armel Lenny em um kernel 2.6.17. A distro Debian em si é
facilmente atualizável para versões posteriores ( sudo apt-get dist-upgrade )
e pode assim ser atualizado, para as versões armel do
squeeze ou até wheezy .
O problema é que o kernel é personalizado ... O ARM SoC
em questão não faz parte do kernel da linha principal, por isso é bastante
muito abandonado em 2.6.17.
Se você sabe como o Linux e o GLIBC funcionam, você já pode ver
problema - versões GLIBC são compiladas com um mínimo suportado
versão do kernel ... O que mudou depois do 2.6.17. Então, se nós tentarmos
para p. chroot para um squeeze 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 , nos dizendo que
não foi compilado para trabalhar com este kernel antigo (2.6.17).
O mesmo problema acontece com o wheezy, também - já que é mais recente do que
squeeze - e de fato acontecerá com qualquer versão Debian a partir de agora,
já que o GLIBC não funcionará no meu kernel 2.6.17.
No começo, eu achei que isso era um problema - mas depois percebi
que eu posso em teoria recompilar GLIBC para trabalhar com os mais antigos
kernel meu SoC está usando ... Mas eu preciso de um ambiente idêntico
ao que foi usado para construir o pacote libc6 em, e. Debian squeeze.
Eu estou supondo que a compilação do GLIBC e a preparação do
O arquivo libc6_2.11.3-4.deb é feito através de compilação automatizada
maquinaria inventada pelos deuses do Debian.
Eu não sou Deus ... nem encontrei nada no Google sobre como
para se tornar um - ou seja, como usar o meu Core i5 como um host, para
GLIBC de compilação cruzada usando exatamente as mesmas configurações que o pacote
versão (dentro do Debian squeeze ) está usando.
Então eu enganei isso - eu descobri como configurar a versão ARM
do Debian squeeze no meu Core i5 (uma técnica que usa uma
versão do binário qemu-arm .
Depois que eu chrooted na minha versão hospedada em x86 de Debian-armel-squeeze ,
Eu fui capaz de 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 depois de 3 horas (a versão chrooted hospedada no Core i5
Debian-armel-squeeze é muito mais lento que uma máquina nativa ...)
Eu tenho meu pacote libc6 .deb. Demoraria provavelmente 3 meses
para fazer isso no meu SoC, então eu não estou reclamando.
Voltando para dentro do meu verdadeiro ARC SoC, eu copiei todos os arquivos libc
(.so) do novo pacote sobre os padrões de squeeze e
tentou chroot ...
# chroot squeeze/
root@ttsiodras:/#
Sim! Funcionou! (ou assim parecia)
Minha libc customizada é reportada 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 - eu copiei um arquivo, invoquei ls ...
Mas quando tentei usar apt-get para instalar alguns aplicativos de 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 . Isso soa como o relatório do GLIBC
que coisas básicas não estão funcionando ...
Consegui avaliar (não pergunte como) e descobri que todas as funções -at
estão falhando: openat , mkdirat , renameat , etc - todos eles estão relatando ENOSYS.
Parece que tive apenas sucesso parcial - algumas chamadas do sistema estão falhando
no meu novo GLIBC.
É impossível compilar um squeeze ou wheeze GLIBC para executar sob 2.6.17?
Quaisquer idéias / indicações sobre o que eu fiz de errado e / ou como proceder seriam muito apreciadas ...