Bug 39178
| Summary: | make-initrd does not include necessary libraries when building image for m-p's VM aarch64 target | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Pavel Nakonechnyi <zorg> |
| Component: | qemu | Assignee: | Alexey Shabalin <shaba> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P5 | CC: | antohami, asheplyakov, boyarsh, glebfm, iv, jqt4, legion, mike, shaba, sin, vt, zerg |
| Version: | unstable | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
make-initrd использует ldd из хост-системы поэтому не может создать initrd для другой архитектуры. Возможно в будущем поддержка кросс-создания образов появится, но сейчас такой поддержки нет. Я думаю, что проблема в qemu, так как на p9 с qemu проблем таких нет. (Ответ для Alexey Gladkov на комментарий #1) > make-initrd использует ldd из хост-системы поэтому не может создать initrd > для другой архитектуры. Возможно в будущем поддержка кросс-создания образов > появится, но сейчас такой поддержки нет. При сборке в mkimage-profiles в качестве хост-системы выступает hasher с qemu binfmt целевой архитектуры. Т.е. кросс-создание образов тут не при чём. (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) Подробности чуть позже. > Подробности чуть позже. Наш /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) Можно писать апстриму и ждать. (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. |
Description
Pavel Nakonechnyi 2020-11-02 22:11:56 MSKНиже, целевая архитектура 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