On Mon, Jan 18, 2021 at 03:52:08PM +0400, Ivan A. Melnikov wrote:
> On Mon, Jan 18, 2021 at 12:55:51PM +0300, Arseny Maslennikov wrote:
> > С итерацией 2.1 то же самое.
> 
> Хм, а у меня получается. А что у Вас в binfmt-misc? Нет ли там
> случайно флага F например?
> 
> Ну то есть, перезагружаться пробовали?

Не пробовал, но см. ниже.

> 
> Ну и сносить ~/hasher-aa64 со всем содержимым и создавать заново?

Пробовал.

> 
> А ещё, если хотя бы первоначальный чрут создался, работает ли
> 
> /usr/bin/qemu-aarch64.static -L ~/$HASHER_DIR/chroot ~/$HASHER_DIR/chroot/bin/ls

Всё, что я излагал в предыдущих письмах, проявлялось без настройки
binfmt_misc на хосте; я не думал, что он никак не виртуализуется.[1]

Некоторые знатоки успели мне посоветовать настроить binfmt_misc на
хосте, что я и сделал через пакет qemu-user-static-binfmt-aarch64:

# cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/bin/qemu-aarch64.static
flags: F
offset 0
magic 7f454c460201010000000000000000000200b700
mask ffffffffffffff00fffffffffffffffffeffffff

Чрут создался, сейчас собираю там тяжёлый пакет llvm11.0.
Так что, по всей видимости, это ложная тревога; извините.
Если что пойдёт не так, дам знать.

[1] Вообще с этим надо что-то делать.
Может быть, стоит в ядре привязать binfmt-misc-механизм к mount
namespace... Интерфейс останется старый (API FS), но интерпретатор будет
закрепляться за процессами в конкретном mountns. Зарегистрированные за
mountns интерпретаторы будут наследоваться в mountns-потомках.