Почему не может Ubuntu 18.04 chroot в qemu среду?
Я действительно изо всех сил пытаюсь понять то, что виновато с chroot / qemu не, работают над Ubuntu 18.04. Более поздняя работа выпусков (определенно 19,10), но под 18,04 я добираюсь:
cannot run command '/bin/sh' No such file or directory.
Я не могу разработать то, что на самом деле повреждается. Я могу вызвать armhf двоичные файлы, не пробуя к chroot, и все хорошо работает. Я могу загрузить x86_64 эквивалент для той же среды и chroot в нее. Но я не могу chroot в armhf среду.
Мое первое предположение - то, что это - что-то измененное с qemu. Ubuntu 18.04 имеет qemu 2.11, где, поскольку Ubuntu 19.10 имеет qemu 4.0. Но я ничего не вижу о chroot, упомянутом в qemu журнале изменений.
Я действительно хочу смочь зафиксировать это, полностью не обновляя поле до выпуска non-LTS. Если я могу исправить всего одну вещь (даже "просто" ядро) затем, я - удобное выполнение этого; но не зная, что на самом деле повредилось, я просто спотыкаюсь вокруг в темноте.
Воспроизвести ошибку:
- установка
qemu-user-staticна x86_64 машине Ubuntu 18.04.sudo apt-get install qemu-user-static - загрузите руку chroot среда (например: альпийская мини-корневая файловая система armhf)
wget http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/armhf/alpine-minirootfs-3.11.3-armhf.tar.gz - извлечение и chroot в среду
mkdir my_env cd my_env tar -xf ../alpine-minirootfs-3.11.3-armhf.tar.gz chroot . /bin/sh
2 ответа
Вы пропустили один шаг - необходимо скопировать qemu-arm-static исполняемый файл к файловой системе ARMhf.
Таким образом, шаги ниже должны работать:
wget http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/armhf/alpine-minirootfs-3.11.3-armhf.tar.gz
mkdir my_env
cd my_env
tar -xf ../alpine-minirootfs-3.11.3-armhf.tar.gz
sudo cp /usr/bin/qemu-arm-static ./usr/bin/ # this is essential step!
sudo chroot . /bin/sh
И Вы сможете к командам выполнения в этом chroot, например:
# arch armv7l
Примечания:
- Я протестировал этот метод на своем LTS Ubuntu 16.04 и 18.04 LTS. Это основано на моем другом ответе.
- Просто протестированный chroot'ing от предстоящих 20.04 LTS - не нуждается в копировании
qemu-arm-static.
Это различие связано с новой функцией, добавленной в ядро:
http://manpages.ubuntu.com/manpages/eoan/man8/update-binfmts.8.html
--fix-binary yes, --fix-binary no
Whether to open the interpreter binary immediately and always use the opened image.
This allows the interpreter from the host to be used regardless of usage in chroots or
different mount namespaces. The default behaviour is no, meaning that the kernel
should open the interpreter binary lazily when needed. This option requires Linux 4.8
or newer. It cannot be used together with --detector, or with multiple binary formats
that share the same magic number, since the kernel will only open a single interpreter
binary which will then not be able to detect and execute the real interpreter from
inside a chroot or from a different mount namespace.
Поскольку эта опция необходима для правильной работы с chroot и был представлен только в ядре 4.8 (Ubuntu 18.04 имеет только 4.15), чтобы это работало, как описано в моем вопросе, требует обновления ядра.
Конечно, существует обходной путь, упомянутый в другом ответе , где вы копируете qemu-arm-statick в свою среду chroot. Чтобы это работало, он должен находиться в том же месте в среде chroot, что и на вашем хосте. Например:
qemu=$(which qemu-arm-static)
cp ${qemu} ${target}/${qemu}
chroot ${target} /bin/sh
Я еще не тестировал это, но ...
Похоже, вы можете исправить это, установив linux-image-generic-hwe-18.04 . подробности о ядрах из LTS Enablement см. здесь: