Проблема: $ hsh --with-qemu=aarch64 --target=aarch64 --apt-config=apt.conf --initroot-only fakeroot: error while starting the `faked' daemon. hsh-initroot: Failed to create RPM database. Ошибка с fakeroot может меняться на что угодно другое при повторном запуске При этом в dmesg: [ 91.775677] faked[6273]: segfault at 1c968a0 ip 000000000046f950 sp 00007fffa9f64d68 error 4 in qemu-aarch64.static[401000+2f9000] [ 91.775680] Code: b6 c2 1c 00 66 0f 1f 44 00 00 64 83 2c 25 60 ff ff ff 01 74 05 c3 0f 1f 40 00 bf 00 b5 8b 00 e9 e6 d8 1c 00 66 0f 1f 44 00 00 <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b [ 91.775731] audit: type=1701 audit(1603639239.548:121): auid=500 uid=501 gid=501 ses=2 pid=6273 comm="faked" exe="/usr/bin/qemu-aarch64.static" sig=11 res=1 Падать может на попытке запуска любого бинарника, не обязательно faked. При этом сам chroot обычно создаётся и в него можно "зайти" и даже запускать имеющийся там софт. Как воспроизвести: * подготовить локальную сборочницу для сборки aarch64 * apt.conf примерно следующего вида: Dir::Etc::main "/dev/null"; Dir::Etc::parts "/var/empty"; Dir::Etc::SourceParts "/var/empty"; Dir::Etc::sourcelist "/some path/sources.list"; * соответствующий sources.list: rpm [alt] file:///mnt/data Sisyphus/aarch64 classic rpm [alt] file:///mnt/data Sisyphus/noarch classic Запустить hasher как указано выше. $ rpm -qif /usr/bin/qemu-aarch64.static Name : qemu-user-static-aarch64 Version : 5.1.0 Release : alt1 DistTag : sisyphus+256281.100.1.1 Architecture: x86_64 Проверялось на разном железе и на следующих ядрах: 5.4.72-std-def 5.8.8-un-def 5.9.1-un-def
Откатился на Name : qemu-user-static-aarch64 Version : 5.0.0 Release : alt1 DistTag : sisyphus+251637.1700.3.1 С этой версией работает.
У меня ранее с --with-qemu=aarch64 не работало, зато работало без. Так вот, если сделать без, получаем: hsh-initroot: Unpacked initial package list. hsh-initroot: Created entry point: /tmp/.private/antohami/hasher/chroot/.host/entry fakeroot: preload library `libfakeroot.so' not found, aborting. hsh-initroot: Failed to create RPM database. Запускаю ещё раз, получаю: hsh-initroot: Created entry point: /tmp/.private/antohami/hasher/chroot/.host/entry /.host/entry: line 16: 2080394 Segmentation fault rm -f /etc/rpm/macros.db1 hsh-initroot: Failed to create RPM database. Запускаю ещё раз, получаю зависание: fakeroot: error while starting the `faked' daemon. Ещё раз: /usr/bin/fakeroot: line 189: 2084826 Segmentation fault FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@" 0<&0 Ещё раз: '/mnt/myhdd/repo/Sisyphus/aarch64/RPMS.classic/rpm-build-4.0.4-alt151.aarch64.rpm' -> 'chroot/.in/rpm-build-4.0.4-alt151.aarch64.rpm' hsh-initroot: Failed to install build package list. Проблема может возникнуть в любом месте, при выполнении любого бинарника.
Вооружившись git bisect, терпением и недоделаным aarch64-p9-чрутом на x86_64-машине с Сизифом, я пошёл искать, кто виноват. Если идти по истории апстримного гита, то qemu-aarch64 первый раз сломалось на коммите ee94743034bfb443cf246eda4971bdc15d8ee066 linux-user: completely re-write init_guest_space Великолепное summary для коммита, хорошо отражаующее суть и сразу наполняющее оптимизмом. После этого коммита chroot в армовый chroot стал падать, но не с segfault, а с диагностикой: qemu-aarch64: /bin/bash: Unable to allocate 0x10d5f98 bytes of virtual address space Как выяснилось, теперь qemu-user (по крайней мере в некоторых случаях) был нужен /proc/self/maps, чтобы найти в памяти какое-нибудь место, в которое можно замапать что-то нужное (кажется, например, интерпретатор загружаемого elf'а, но тут я не уверен). То есть, если в chroot пробросить /proc, qemu-user начинает работать. Можно проверить и с 5.2.0-alt1, навреняка заработает, хотя вряд ли это поможет hsh --initroot. Заметив эту проблему, апстрим попробовал исправить её и сделать так, чтобы qemu-user работал в чуть более пустых чрутах. Для этого был сделан более скромный коммит того же автора, ad592e37dfccf730378a44c5fa79acb603a7678d linux-user: provide fallback pgd_find_hole for bare chroots Однако тут что-то идёт не так и qemu-user, вместо того, чтобы работать даже с отсутствующим /proc/self/maps, начинает иногда падать. Я пока не разбирался, почему это происходит, но явно проблема где-то вокруг pgd_find_hole_fallback. В общем, надо смотреть, что там такое.
Какая-то чать решения, похоже, выглядит так: http://git.altlinux.org/people/iv/packages/?p=qemu.git;a=commitdiff;h=93f9ffdb573c0932aec4559ea0884acf2d1d5171 У меня на машине упорно делает вид, что работает. Есть test-only задача http://git.altlinux.org/tasks/264674/, часа через 2 соберётся и можно будет проверять и на других машинах. Подробности, тикеты в апстрим и нормальный commit message потом.
(In reply to Ivan A. Melnikov from comment #4) > У меня на машине упорно делает вид, что работает. Есть test-only задача > http://git.altlinux.org/tasks/264674/, часа через 2 соберётся и можно будет > проверять и на других машинах. Install check'и ещё идут, но делать apt-repo add 264674 уже можно. У меня hsh --iniroot --with-qemu=aarch64 с Сизифным aarch64 на машине с x86_64 Сизифом и #264674 прошёл. Приглашаются желающие потестировать.
antohami@ проверил работу qemu-user при сборке образов под разные архитектуры: https://lists.altlinux.org/pipermail/devel/2021-January/213412.html 2shaba: прошу аппрув на #264674. Или забери себе http://git.altlinux.org/people/iv/packages/?p=qemu.git;a=commitdiff;h=93f9ffdb573c0932aec4559ea0884acf2d1d5171 Также рекомендую забрать http://git.altlinux.org/people/iv/packages/?p=qemu.git;a=commitdiff;h=aa64b05c2a95d974ee2ef547eefacab245084b14 так как эти sed'ы в спеке поломались после рефакторинга linux-user/main.c кажется где-то в районе 5.0. Я правда не разбирался, какой CPU выбирается для "any" и чем это нам грозит, только адаптировал к изменениям в исходниках.
5.2.0-alt2 в Сизифе.
Спасибо!
