나는 현재 함께 일하고 있습니다Armbian 빌드 시스템docker 내의 chroot를 사용하여 armbian 이미지를 교차 빌드합니다(제 경우에는 amd64 호스트에서 aarch64를 사용합니다).
그런데 어떤 이유에서인지 내 컴퓨터에서 빌드 스크립트를 apt-key add -실행하면 단일 CPU 코어를 지속적으로 100% 사용하면서 실제로 몇 시간이 걸립니다.
apt 키는 다음과 같이 호출됩니다. 결과적으로 컨테이너 내부와 유사한 프로세스가 발생합니다 chroot <armbian-rootfs-dir> bash -c 'cat armbian.key | apt-key add -'./usr/bin/qemu-aarch64-static /bin/bash -c cat armbian.key | apt-key add -
apt-key(셸 스크립트) 내에서는 실제로 그만큼 시간이 걸리는 일부 바이너리가 호출됩니다. 예를 들면 다음과 같습니다.
- 여러 번 호출되었습니다
/usr/bin/apt-config. 예:/usr/bin/apt-config shell ARCHIVE_KEYRING_URI APT::Key::Archiv. - 전화
/usr/bin/gpg-conf(/usr/bin/gpgconf --kill all정확히 말하면) ps aux더 있을 수도 있지만 몇 개는 놓쳤을 수도 있습니다(기다리는 동안 가끔 시청하겠습니다).
나는 docker -> chroot -> qemu 를 통해 실행될 때 이러한 호출(최대 몇 초 소요)이 종료하는 데 몇 시간이 걸리는 이유를 정말로 이해하지 못했습니다.
왜 이렇게 느리게 만드는지 정말 이해가 안 됩니다. 추가 디버깅 방법에 대한 조언을 주시면 매우 감사하겠습니다.
편집하다:문제의 단계는 ubuntu 22.04 VM에서 직접 실행할 때 훨씬 더 빠르다는 점을 언급해야 합니다(이 경우 Ubuntu 22.04가 기본적으로 지원되므로 armbian 빌드 스크립트는 docker를 사용하지 않습니다).
편집하다:
다음과 같이 문제를 성공적으로 재현했습니다.
docker run --name armbian-test -d --rm ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest bash -c 'while sleep 1; do true; done'
docker exec armbian-test bash -c 'apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends bash git psmisc uuid-runtime bc binfmt-support bison libc6-dev make dpkg-dev gcc ca-certificates ccache cpio debootstrap device-tree-compiler dialog dirmngr dosfstools dwarves flex gawk gnupg gpg imagemagick jq kmod libbison-dev libelf-dev libfdt-dev libfile-fcntllock-perl libmpc-dev libfl-dev liblz4-tool libncurses-dev libssl-dev libusb-1.0-0-dev linux-base locales lsof ncurses-base ncurses-term ntpdate patchutils pkg-config pv qemu-user-static rsync swig u-boot-tools udev uuid-dev zlib1g-dev file tree expect colorized-logs unzip zip pigz xz-utils pbzip2 lzop zstd parted gdisk fdisk aria2 curl wget axel parallel python3-dev python3-distutils python3-setuptools python3-pip python2 python2-dev gcc-x86-64-linux-gnu gcc-aarch64-linux-gnu gcc-arm-linux-gnueabihf gcc-arm-linux-gnueabi gcc-riscv64-linux-gnu debian-archive-keyring libc6-amd64-cross g++-aarch64-linux-gnu g++ btrfs-progs cryptsetup openssh-client f2fs-tools nilfs-tools xfsprogs zerofree qemu-utils qemu-utils libudev-dev libusb-1.0-0-dev dh-autoreconf build-essential gcc-arm-linux-gnueabi gcc-or1k-elf time'
docker exec armbian-test debootstrap --variant=minbase --arch=arm64 bullseye /debootstrap
docker exec armbian-test time chroot /debootstrap /bin/bash -c '/usr/bin/apt-config shell ARCHIVE_KEYRING_URI APT::Key::Archiv'
답변1
나는 당신과 같은 문제에 직면했습니다. 이는 Google에 표시되는 거의 유일한 결과이기 때문에 상당히 드문 사용 사례인 것 같습니다.
/proc결국 이 문제를 발견했는데 chroot(Docker 컨테이너 내부에서)에 설치하는 것과 관련이 있었습니다.
귀하의 예에서는 /procrootfs를 입력/사용하기 전에 Docker를 chroot에 설치해야 합니다.
mount -t proc /proc <armbian-rootfs-dir>/proc
그러면 chroot에서 기본 암호화 속도를 얻을 수 있습니다.
편집하다: 루트가 변경된 이전 Ubuntu 16.04 이미지에서는 제대로 작동하는 것 같지만 debootstrap.
debootstrap 에 의해 생성된 chroot의 내용을 보면 proc폴더는 /proc.ls /proccannot access 'proc': Too many levels of symbolic links
이 문제를 해결하려면(누군가 이것이 왜 나쁜 생각인지 말해 줄 수 있다고 확신합니다) chroot 외부에서 실행하십시오.
rm <armbian-rootfs-dir>/proc
mkdir -p <armbian-rootfs-dir>/proc
mount -t proc /proc <armbian-rootfs-dir>/proc
그러면 심볼릭 링크가 제거되고 chroot가 /procDocker에 바인딩됩니다./proc
또한 다시 제거 debootstrap --second-stage되는 것처럼 보이므로 /proc해당 단계가 완료되면 (chroot 외부에서) 다시 설치해야 합니다(참조:외부 chroot에서 /proc에 액세스)
노트:umount <armbian-rootfs-dir>/procchrooting이 완료되고 폴더 이미지를 만들고 싶을 때 이 작업을 수행하는 것을 잊지 마십시오.