Bug 39178 - make-initrd does not include necessary libraries when building image for m-p's VM aarch64 target
Summary: make-initrd does not include necessary libraries when building image for m-p'...
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: qemu (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-02 22:11 MSK by Pavel Nakonechnyi
Modified: 2021-04-14 14:10 MSK (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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
Comment 1 Alexey Gladkov 2020-11-02 23:06:05 MSK
make-initrd использует ldd из хост-системы поэтому не может создать initrd для другой архитектуры. Возможно в будущем поддержка кросс-создания образов появится, но сейчас такой поддержки нет.
Comment 2 Антон Мидюков 2021-04-08 17:08:34 MSK
Я думаю, что проблема в qemu, так как на p9 с qemu проблем таких нет.
Comment 3 Антон Мидюков 2021-04-08 17:41:17 MSK
(Ответ для Alexey Gladkov на комментарий #1)
> make-initrd использует ldd из хост-системы поэтому не может создать initrd
> для другой архитектуры. Возможно в будущем поддержка кросс-создания образов
> появится, но сейчас такой поддержки нет.

При сборке в mkimage-profiles в качестве хост-системы выступает hasher с qemu binfmt целевой архитектуры. Т.е. кросс-создание образов тут не при чём.
Comment 4 Ivan A. Melnikov 2021-04-08 18:01:29 MSK
(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)

Подробности чуть позже.
Comment 5 Ivan A. Melnikov 2021-04-08 18:35:33 MSK
> Подробности чуть позже.

Наш /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)


Можно писать апстриму и ждать.
Comment 6 Ivan A. Melnikov 2021-04-13 14:34:21 MSK
(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.
Comment 7 Repository Robot 2021-04-14 14:10:40 MSK
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)