chroot-ed 데비안 armel
환경에서 뭔가 이상한 것을보고 있습니다.
그러나 먼저, 약간의 배경 이야기 … 이것은 길지만 질문은 복잡하고 잠재적 인 도움은 전체 이야기를 아는 것에 달려 있습니다.
Linux를 실행하는 임베디드 ARM SoC가 있는데, 특히 armel
2.6.17 커널에서 Debian Lenny가 있습니다. 데비안 배포판 자체는 이후 버전 ( sudo apt-get dist-upgrade
)으로 쉽게 업그레이드 할 수 있으므로 속도, armel
버전
squeeze
또는 심지어 업그레이드 할 수 있습니다 wheezy
.
문제는 커널이 커스텀 커널이라는 것입니다. 문제의 ARM SoC는 메인 라인 커널의 일부가 아니므로 2.6.17에서 거의 포기되었습니다.
Linux와 GLIBC의 작동 방식을 알고 있다면 이미 문제가 있음을 알 수 있습니다. GLIBC 버전은 최소 지원 커널 버전으로 컴파일되어 있습니다. 2.6.17을 넘어 섰습니다. 예를 들어 chroot를 데비안 스퀴즈로 만들려고하면 …
$ # 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
… 우리는 GLIBC squeeze
에서이 오래된 커널 (2.6.17)과 작동하도록 컴파일되지 않았다는 메시지를 보았습니다 .
스퀴즈보다 최신이기 때문에 wheezy에서도 동일한 문제가 발생하며 실제로 GLIBC가 2.6.17 커널에서 작동하지 않기 때문에 실제로는 모든 데비안 버전에서 발생합니다.
처음에는 이것이 거래 차단기라고 생각했지만 이론 상으로는 SoC가 사용하는 이전 커널과 함께 작동하도록 GLIBC를 다시 컴파일 할 수 있음을 깨달았습니다 …하지만 libc6을 빌드하는 데 사용 된 것과 동일한 환경이 필요합니다 데비안 스퀴즈와 같은 패키지.
나는 GLIBC의 컴파일과 libc6_2.11.3-4.deb 파일의 준비가 데비안의 신들이 발명 한 자동화 된 크로스 컴파일 기계를 통해 수행된다고 생각합니다.
나는 신이 아닙니다 … Google에서 하나가되는 방법, 즉 Core i5를 호스트로 사용하는 방법, 패키지 버전 (Debian 내부 squeeze
) 과 정확히 동일한 설정을 사용하여 GLIBC를 크로스 컴파일하는 방법에 대해 아무것도 찾을 수 없습니다. 사용.
그래서 나는 그것을 속였다-Core i5에서 정적 버전의 qemu-arm
바이너리 를 사용하는 기술 인 ARM 버전의 Debian squeeze를 설정하는 방법을 알아 냈습니다 .
x86 호스트 버전의을 루트로 만들었 으면 Debian-armel-squeeze
간단하게 …
$ 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
… 그리고 3 시간 후에 (핵심 i5 호스팅 chrooted 버전은
Debian-armel-squeeze
기본 시스템보다 훨씬 느립니다 …) libc6 .deb 패키지를 얻었습니다. 내 SoC 에서이 빌드를 수행하는 데 3 개월이 걸리므로 불평하지 않습니다.
내 실제 ARM SoC 내부로 돌아가서 새 패키지의 모든 libc 파일 (.so)을 기본 압축 파일 위에 복사하고 chroot하려고했습니다 …
# chroot squeeze/
root@ttsiodras:/#
예! 효과가 있었다! (또는 그렇게 보였다)
내 사용자 정의 libc가 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/>.
일이 작동하는 것 같습니다-파일을 복사하고 호출했습니다 ls
…
하지만 apt-get
에서 일부 앱을 설치 하려고 할 때 squeeze
예기치 않은 오류가 발생하기 시작했습니다.
# 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)
오 … 한 무리 Function not implemented
. 그것은 GLIBC가 기본적인 것들이 작동하지 않는다고보고하는 것처럼 들립니다 …
내가 strace를에 관리 (어떻게 묻지 않는 것) 알아 낸 모든 것을 -at
기능이 실패 : openat
, mkdirat
, renameat
, 등 – 그들은 모두보고 ENOSYS 있습니다.
부분적으로 만 성공한 것으로 보입니다. 새 GLIBC에서 일부 시스템 호출이 실패했습니다.
2.6.17에서 실행하기 위해 squeeze
또는 wheeze
GLIBC 를 컴파일 할 수 없습니까?
내가 잘못한 일 및 / 또는 진행 방법에 대한 아이디어 / 포인터는 대단히 감사하겠습니다 …
답변
나는 그것을 만든 🙂
나는 기본적으로 Gilles의 조언을 따르고 올바르게 수행하기로 결정했습니다. 즉 GLIBC의 완전한 크로스 컴파일을 관리합니다. 나는 crosstool-ng에서 시작하여 처음에는 실망했습니다. 이전 커널이 이전 커널을 지원하지 않는 것을 보았습니다. 그래도 기본 arm-gnueabi 빌드 구성에서 다음과 같이 변경하기 위해 crosstool-ng에 의해 저장된 구성 파일을 수동으로 편집했습니다.
$ ct-ng arm-unknown-linux-gnueabi
$ ct-ng menuconfig
...
$ vi .config
$ cat .config
...
CT_KERNEL_VERSION="2.6.17"
CT_KERNEL_V_2_6_17=y
CT_LIBC_VERSION="2.13"
CT_LIBC_GLIBC_V_2_13=y
CT_LIBC_GLIBC_MIN_KERNEL_VERSION="2.6.9"
CT_LIBC_GLIBC_MIN_KERNEL="2.6.9
...
$ ct-ng +libc
여러 번의 테스트와 실패한 시도로 위의 변경 사항이 적용되었습니다. 커널에서 작동하는 컴파일 된 버전의 GLIBC를 가져 와서 결과 파일을 Debian Lenny ARM 머신에 복사했습니다.
$ cd .build/arm-unknown-linux-gnueabi/build/build-libc-final/
$ tar zcpf newlibc.tgz $(find . -type f -iname \*.so)
$ scp newlibc.tgz root@mybook:.
나는 계속해서 꽉 쥐었다. 나는 / wheezy를 debootstrapped 한 다음 매우 조심스럽게 armel-debootstrapped의 GLIBC 버전을 /wheezy
내 자신으로 덮어 썼다 .
# # In the ARM machine
# cd /wheezy/lib/arm-linux-gnueabi/
# mv /var/tmp/ohMyGod/libc.so libc-2.13.so
# mv /var/tmp/ohMyGod/rt/librt.so librt-2.13.so
...
… 등, 공유 라이브러리를 놓치지 않았는지 확인하십시오.
마지막으로, ldd
및 ldconfig
바이너리 (GLIBC의 일부이기도 함)를 복사하고 내 / wheezy 안에 chroot했습니다.
효과가있었습니다.
나는 x86 내부의 chroot-ed ‘qemu-arm’에뮬레이션에서 GLIBC를 컴파일한다고 가정 할 수 있습니다. 어쩌면 엉망이되었습니다. 어쩌면 configure
프로세스가 실행중인 환경에서 일부 항목을 감지 할 수 있습니다. .
그래서 당연히 나는 다음 단계로 이동하고하는 비지 박스 정적 쉘을 사용하는 대신 은 {/ 빈 / sbin에, …}는 씩씩 거리는 사람과 나의 오래된 레니의 폴더 – 내 새로운 위지으로 다시 🙂
나는 내 WD MyBook World Edition 이 데비안 Wheezy를 실행하는 지구상에서 유일한 것이라고 주장합니다. 🙂 다른 사람이 관심이 있다면 libc 파일의 tarball을 어딘가에 업로드 할 수 있습니다.