Estoy viendo algo realmente extraño dentro de un armelentorno Debian chroot-ed .
Pero primero, un poco de historia de fondo ... Esto es largo, pero la pregunta es compleja y cualquier ayuda potencial depende de conocer la historia completa.
Tengo un SoC ARM incorporado que ejecuta Linux, más específicamente, un Debian armelLenny en un kernel 2.6.17. La distribución de Debian en sí es fácilmente actualizable a versiones posteriores ( sudo apt-get dist-upgrade) y, por lo tanto, puede actualizarse, incluso a armelversiones de
.squeezewheezy
El problema es que el kernel es personalizado ... El SoC ARM en cuestión no es parte del kernel de la línea principal, por lo que está prácticamente abandonado en 2.6.17.
Si sabe cómo funcionan Linux y GLIBC, ya puede ver el problema: las versiones de GLIBC están compiladas con una versión de kernel mínima admitida ... que ha superado 2.6.17. Entonces, si intentamos, por ejemplo, hacer chroot a un apretón de 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 un mensaje del GLIBC squeezeque nos dice que no fue compilado para funcionar con este núcleo antiguo (2.6.17).
El mismo problema también ocurre con wheezy, ya que es más nuevo que squeeze, y de hecho ocurrirá con cualquier versión de Debian de ahora en adelante, ya que su GLIBC no funcionará en mi kernel 2.6.17.
Al principio pensé que esto era un factor decisivo , pero luego me di cuenta de que, en teoría, puedo recompilar GLIBC para trabajar con el núcleo más antiguo que usa mi SoC ... Pero necesitaría un entorno idéntico al que se usó para construir el libc6. paquete en, por ejemplo, Debian Squeeze.
Supongo que la compilación de GLIBC y la preparación del archivo libc6_2.11.3-4.deb se realiza a través de la maquinaria automatizada de compilación cruzada inventada por los dioses de Debian.
No soy Dios ... ni pude encontrar nada en Google sobre cómo ser uno, es decir, cómo usar mi Core i5 como host, compilar GLIBC de manera cruzada usando exactamente la misma configuración que la versión empaquetada (dentro de Debian squeeze). utilizando.
Así que lo engañé: descubrí cómo configurar la versión ARM de Debian Squeeze en mi Core i5 (una técnica que usa una versión estática del qemu-armbinario).
Una vez que hice el chroote en mi versión alojada en x86 Debian-armel-squeeze, pude simplemente ...
$ 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
... y después de 3 horas (la versión chrooteada alojada en Core i5
Debian-armel-squeezees mucho más lenta que una máquina nativa ...) obtuve mi paquete libc6 .deb. Probablemente tomaría 3 meses hacer esta compilación en mi SoC, por lo que no me quejo.
Volviendo al interior de mi ARM SoC real, copié todos los archivos libc (.so) del nuevo paquete sobre los predeterminados de squeeze e intenté hacer chroot ...
# chroot squeeze/
root@ttsiodras:/#
¡Si! ¡Funcionó! (o eso parecía)
Mi libc personalizada informó desde dentro del 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/>.
Las cosas parecían funcionar: copié un archivo, invoqué ls...
Pero cuando intenté usar apt-getpara instalar algunas aplicaciones squeeze, comencé a recibir ... algunos errores 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 ... un montón de Function not implemented. Eso suena como GLIBC informando que las cosas básicas no están funcionando ...
Logré strace (no preguntar cómo) y la cuenta de que todas las -atfunciones están fallando: openat, mkdirat, renameat, etc - son todas ENOSYS de informes.
Parece que solo tuve un éxito parcial: algunas llamadas al sistema fallan en mi nuevo GLIBC.
¿Es imposible compilar un squeezeo wheezeGLIBC para ejecutar bajo 2.6.17?
Cualquier idea / puntero sobre lo que hice mal y / o cómo proceder sería muy apreciada ...
fuente
Respuestas:
Lo hice :-)
Básicamente seguí el consejo de Gilles y decidí hacerlo correctamente: es decir, gestionar una compilación cruzada completa de GLIBC. Comencé con crosstool-ng, y al principio me decepcioné al ver que no era compatible con mi núcleo anterior. Sin embargo, seguí adelante: editando manualmente el archivo de configuración guardado por crosstool-ng para hacer cambios como estos en la configuración de compilación predeterminada de arm-gnueabi:
Después de numerosas pruebas e intentos fallidos, los cambios anteriores lo hicieron: obtuve una versión compilada de GLIBC que funcionaría con mi kernel y copié los archivos resultantes en mi máquina Debian Lenny ARM:
Fui todo el camino y superé el apretón: debootrastrapé un / wheezy y luego, con mucho cuidado, sobrescribí las versiones GLIBC del armel-debootstrapped
/wheezycon el mío:... etc, asegurándome de no perder ninguna biblioteca compartida.
Finalmente, copié los binarios
lddyldconfig(que también formaban parte de GLIBC), y los incluí en mi / wheezy.Funcionó.
Solo puedo suponer que la compilación de GLIBC a partir de una emulación 'qemu-arm' chroot-ed dentro de un x86, de alguna manera arruinó las cosas, tal vez el
configureproceso detecta algunas cosas del entorno de ejecución, mientras que la compilación cruzada no se puede engañar .Así que, naturalmente, pasé al siguiente paso y utilicé un shell busybox-static para reemplazar las carpetas {/ bin, / sbin, ...} de mi viejo lenny con las sibilantes, y reinicié mi nuevo Wheezy :-)
Por la presente, afirmo que mi WD MyBook World Edition es el único en el planeta que ejecuta Debian Wheezy :-) Si alguien más está interesado, puedo cargar un tarball de los archivos libc en algún lugar.
fuente