39178 2020-11-02 22:11:56 +0300 make-initrd does not include necessary libraries when building image for m-p's VM aarch64 target 2021-04-14 14:10:40 +0300 1 1 4 Development Sisyphus qemu unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 zorg shaba antohami asheplyakov boyarsh glebfm iv jqt4 legion mike shaba sin vt zerg qa-sisyphus oldest_to_newest 193712 0 zorg 2020-11-02 22:11:56 +0300 Ниже, целевая архитектура aarch64, хост -- x86_64. make-initrd, будучи вызван в процессе сборки VM образа инструментом mkimage-profiles (см. features.in/build-vm/image-scripts.d/17-kernel), не добавляет необходимых библиотек. Из-за этого полученная система оказывается неспособной загрузиться. Простой способ воспроизвести проблему наверное не предложу. Скорее всего достаточно создать минимальный chroot для целевой архитектуры и сгенерировать образ initrd в нем. Пример проблемного результата: $ sudo initrd-ls initrd-4.14.98-pico-imx8mq-alt3.img | grep "\./lib64" | awk '{ print $11; }' ./lib64 ./lib64/libz.so.1.2.11 ./lib64/libz.so.1 ./lib64/libselinux.so.1 ./lib64/libresolv.so.2 ./lib64/libresolv-2.30.so ./lib64/libpthread.so.0 ./lib64/libpthread-2.30.so ./lib64/libpcre.so.3.15.12 ./lib64/libpcre.so.3 ./lib64/libnss_files.so.2 ./lib64/libnss_files-2.30.so ./lib64/libnss_dns.so.2 ./lib64/libnss_dns-2.30.so ./lib64/libmount.so.1.1.0 ./lib64/libmount.so.1 ./lib64/liblzma.so.5.2.5 ./lib64/liblzma.so.5 ./lib64/libkmod.so.2.3.5 ./lib64/libkmod.so.2 ./lib64/libgcc_s.so.1 ./lib64/libdl.so.2 ./lib64/libdl-2.30.so ./lib64/libcrypto.so.1.1 ./lib64/libc.so.6 ./lib64/libc-2.30.so ./lib64/libblkid.so.1.1.0 ./lib64/libblkid.so.1 ./lib64/libacl.so.1.1.2253 ./lib64/libacl.so.1 ./lib64/ld-linux-aarch64.so.1 ./lib64/ld-2.30.so В моем случае потребовалось вручную (через PUT_FILES) добавить следующие файлы: /lib64/libreadline.so.7.0 /lib64/libreadline.so.7 /lib64/libtinfo.so.5.9 /lib64/libtinfo.so.5 /lib64/libcryptsetup.so.12.6.0 /lib64/libcryptsetup.so.12 /lib64/libcrypt.so.1.1.0 /lib64/libcrypt.so.1 /lib64/libsmartcols.so.1.1.0 /lib64/libsmartcols.so.1 193713 1 legion 2020-11-02 23:06:05 +0300 make-initrd использует ldd из хост-системы поэтому не может создать initrd для другой архитектуры. Возможно в будущем поддержка кросс-создания образов появится, но сейчас такой поддержки нет. 197645 2 antohami 2021-04-08 17:08:34 +0300 Я думаю, что проблема в qemu, так как на p9 с qemu проблем таких нет. 197649 3 antohami 2021-04-08 17:41:17 +0300 (Ответ для Alexey Gladkov на комментарий #1) > make-initrd использует ldd из хост-системы поэтому не может создать initrd > для другой архитектуры. Возможно в будущем поддержка кросс-создания образов > появится, но сейчас такой поддержки нет. При сборке в mkimage-profiles в качестве хост-системы выступает hasher с qemu binfmt целевой архитектуры. Т.е. кросс-создание образов тут не при чём. 197651 4 iv 2021-04-08 18:01:29 +0300 (In reply to Антон Мидюков from comment #2) > Я думаю, что проблема в qemu, так как на p9 с qemu проблем таких нет. Да. Сейчас в qemu-user-static для aarch64 падает ldd. Можно посмотреть из host-системы, сделав hsh --init на aarch64: $ qemu-aarch64.static -L ./chroot ./chroot/lib64/ld-linux-aarch64.so.1 --list /bin/bash Segmentation fault (core dumped) Подробности чуть позже. 197654 5 iv 2021-04-08 18:35:33 +0300 > Подробности чуть позже. Наш /lib64/ld-linux-aarch64.so.1, когда не пытается выполнять вверенный ему ELF, очень хочет загрузить его по адресу 0x400000. И это ему удаётся, не смортя на то, что где-то там уже находится код qemu-user. Естественно, с qemu-user при этом оказывается всё плохо, и оно падает. == Почему оно работает в обычной ситуации? == Потому что сам qemu-user притворяется ASLR и отправляет загружаемый бинарник на некий случайный адрес, по которому ничего полезного нет. Для статических "гостевых" бинарников, которым нужен фиксированный адрес, есть особые трюки. == Почему оно работало раньше? == До qemu 5.0 статически собранный qemu-user был статически собран особым образом с применением особого linker script'а, что убирало его с адреса 0x400000 на 0x60000000, и /lib64/ld-linux-aarch64.so.1 мог использовать кусок адресного пространства начиная с 0x400000 как хотел. Но не мог 0x60000000, однако и не пробовал, так что чаще всего всем везло. Начиная с qemu 5.0 апстрим решил, что такие трюки с linker script'ами больше не нужны и удалил их: http://git.altlinux.org/gears/q/qemu.git?a=commitdiff;h=ee5195ee0fc87858088313f2c6f327ac41f5912f > This adjustment was random and unnecessary. Угу. == Что делать? == Можно попробовать накостылить что-нибудь вокруг этого параметра: $ qemu-aarch64.static --help | grep BASE -B address QEMU_GUEST_BASE set guest_base address to 'address' Вот так, например, работает: $ qemu-aarch64.static -B 0x60000000 -L ./chroot ./chroot/lib64/ld-linux-aarch64.so.1 --list /bin/bash libreadline.so.7 => /lib64/libreadline.so.7 (0x0000005501839000) libdl.so.2 => /lib64/libdl.so.2 (0x000000550189a000) libc.so.6 => /lib64/libc.so.6 (0x00000055018ae000) /lib64/ld-linux-aarch64.so.1 => ./chroot/lib64/ld-linux-aarch64.so.1 (0x0000005500000000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000005501a25000) Можно писать апстриму и ждать. 197887 6 iv 2021-04-13 14:34:21 +0300 (In reply to Ivan A. Melnikov from comment #5) > Можно писать апстриму и ждать. Ну или как альтернативный вариант -- можно попробовать вернуть перенос кода qemu-user вверх: http://git.altlinux.org/people/iv/packages/?p=qemu.git;a=commitdiff;h=13106489e9205fef9833d471b61413556fd68e84 Сделано только для qemu-user, зато для всех. Проверил для нескольких архитектур из интересных мне, на первый взгляд работает. Все желающие приглашаются потестировать задачу #269840. 197910 7 repository-robot 2021-04-14 14:10:40 +0300 qemu-5.2.0-alt5 -> sisyphus: Mon Apr 12 2021 Ivan A. Melnikov <iv@altlinux> 5.2.0-alt5 - Move qemu-user-static text segment to 0x60000000 (ALT #39178) - Drop qemu-aux dependency from qemu-user-static (ALT #39815) - Drop qemu-mipsn32*.conf from binfmt config packages (ALT #39619)