Виртуализация Android‑устройства в Termux с QEMU: эмуляция разных архитектур, тестирование ядра Linux и отладка драйверов

Termux превратился в удобную «лабораторию» на Android: пакетный менеджмент, скрипты, компиляция и запуск пользовательских сервисов. Одно из самых полезных направлений — виртуализация внутри телефона/планшета с помощью QEMU. Это позволяет эмулировать различные CPU‑архитектуры, загружать гостевые системы Linux, проверять ядро и воспроизводить ошибки, не влияя на основную систему.

В этой статье мы разберём типовой сценарий: установка QEMU в Termux, подготовка образов, запуск виртуальных машин для разных архитектур (x86_64 и ARM64 в первую очередь), а также подходы к тестированию ядра Linux и подготовке среды для отладки драйверов.

Что можно и нельзя в рамках Termux+QEMU

Важно ожидать реалистичные ограничения:

На Android QEMU часто работает в режиме программной эмуляции (Tонировка производительности зависит от устройства и настроек). Для сложных сетевых сценариев и «тяжёлых» образов потребуется оптимизация.
Эмуляция архитектуры, отличной от вашей (например, ARM64 на x86‑платформе), обычно значительно медленнее, но полезна для тестов сборок и поведения ядра.
Отладка «железных» драйверов через QEMU упирается в модель аппаратной платформы (emulated devices). Однако большинство проблем интерфейса подсистем можно воспроизвести.

С юридической и безопасностной точки зрения: используйте образы и исходники ядра, которые вы имеете право использовать, а виртуальные сети — только для локальной изоляции лаборатории.

Подготовка среды в Termux

Начнём с базовой подготовки: обновление пакетов и установка необходимых компонентов.

pkg update
pkg upgrade -y
pkg install -y qemu-utils qemu-system-x86_64 qemu-system-aarch64 qemu-utils wget curl tar xz-utils git

Если пакет для конкретной архитектуры недоступен в вашей конфигурации Termux, используйте доступные пакеты QEMU или собирайте нужный вариант из исходников. Для практического старта x86_64 и aarch64 обычно достаточно.

Далее подготовим рабочие директории под образы и конфиги.

mkdir -p ~/lab/qemu/images ~/lab/qemu/work ~/lab/qemu/iso ~/lab/qemu/logs

Образы: что нужно для запуска гостевой системы

Есть два основных пути:

С загрузочным ISO: если нужно быстро проверить инсталлятор или загрузку пользователя.
С заранее подготовленным диском (QCOW2/raw): удобнее для повторяемых тестов ядра и драйверов.

Для тестирования ядра Linux чаще всего используют:

корневой файловый образ (например, ext4) либо initramfs;
образ ядра vmlinuz;
initrd (если требуется);
параметры загрузки (cmdline), которые управляют логированием и отладочными опциями.

Создадим дисковый образ под гостевую систему (пример для ext4 в raw). Формат можно заменить на qcow2 при наличии инструментов.

cd ~/lab/qemu/images
qemu-img create -f raw disk-aarch64.img 4G

Дальше этот диск потребуется разметить и заполнить (например, через установочный ISO). Для лабораторных тестов ядра иногда достаточно initramfs без полноценного rootfs, но это зависит от вашей цели.

Сеть в QEMU на Android: локальная лаборатория

Для удобства можно поднять локальную сеть внутри виртуальной лаборатории. Один из практичных вариантов — пользовательский NAT или «виртуальный коммутатор» (в зависимости от возможностей сборки QEMU и разрешений). Если вы планируете взаимодействие с гостем из Termux, проще всего оперировать так, чтобы у хост‑системы был предсказуемый доступ.

Ниже приведён пример подхода: поднимать гостя с user‑networking и отдельным порт‑форвардингом (в локальном контуре). Это не является обходом блокировок; это обычная настройка тестовой сети.

Запуск VM x86_64: быстрый старт

Для x86_64 часто удобнее начинать с minimal‑образов и initramfs. Допустим, у нас уже есть ядро и initrd (пусть даже самодельные для ваших тестов).

Пример командной строки QEMU для x86_64 с UEFI/BIOS зависит от того, какие файлы у вас подготовлены. Ниже — базовый пример загрузки ядра с initrd и rootfs, заданным параметром kernel cmdline.

qemu-system-x86_64 \
  -m 1024 \
  -smp 2 \
  -nographic \
  -kernel ~/lab/qemu/work/bzImage \
  -initrd ~/lab/qemu/work/initrd.img \
  -append "console=ttyS0 root=/dev/sda rw loglevel=7 panic=10" \
  -drive file=~/lab/qemu/images/disk-x86_64.img,format=raw,if=virtio \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -device e1000,netdev=net0 \
  -d guest_errors,unimp,pcall,cpu_reset

Обратите внимание:

-nographic отправляет консоль в stdout/stderr, что удобно в Termux.
console=ttyS0 и loglevel=7 помогают получить максимальный вывод.
hostfwd полезен для локального доступа к SSH‑службе внутри гостя, если она установлена.

Запуск VM ARM64 (aarch64): эмуляция другой архитектуры

Эмуляция ARM64 в QEMU позволяет тестировать сборки под aarch64 и поведение ядра в другой архитектуре. Для лабораторной работы обычно используют virt‑платформу (generic ARM virt).

qemu-system-aarch64 \
  -M virt \
  -cpu cortex-a57 \
  -m 1024 \
  -smp 2 \
  -nographic \
  -kernel ~/lab/qemu/work/Image \
  -initrd ~/lab/qemu/work/initrd.img \
  -append "console=ttyAMA0 root=/dev/vda rw loglevel=7 panic=10 earlyprintk" \
  -drive file=~/lab/qemu/images/disk-aarch64.img,format=raw,if=virtio \
  -netdev user,id=net0,hostfwd=tcp::2223-:22 \
  -device virtio-net-pci,netdev=net0 \
  -dtb ~/lab/qemu/work/dtbs/virt.dtb

Пояснения:

-M virt — «виртуальная» платформа QEMU, подходящая для тестов.
Для ARM обычно нужен dtb (-dtb) или соответствующая связка с вашей сборкой/boot‑компонентами.
console=ttyAMA0 характерно для последовательной консоли в ARM virt‑среде.

Если у вас нет отдельного dtb, проверьте, умеет ли ваш boot‑путь его подхватывать из структуры ядра. Для «голого» kernel+initrd часто dtb требуется.

Подготовка ядра Linux для тестов в QEMU

Чтобы тестирование было продуктивным, заранее продумайте параметры:

максимальный лог‑уровень (loglevel=7);
останов при панике для быстрее воспроизведения (panic=10);
отладочные опции подсистем (зависят от того, что именно вы тестируете);
включение/отключение драйверов (параметрами загрузки) — для A/B сравнения.

Пример расширенного cmdline для отладки памяти/подсистем:

-append "console=ttyAMA0 root=/dev/vda rw loglevel=7 panic=10 initcall_debug dynamic_debug=+p earlycon"

Важно: не все опции поддерживаются в вашем конкретном ядре и конфигурации. Начните с логов и initcall_debug, затем добавляйте точечно.

Тестирование драйверов: подходы через emulated устройства

QEMU эмулирует конкретный набор устройств. Поэтому «отладка драйвера» в вашем контексте чаще всего означает:

проверку корректности инициализации устройства;
проверку DMA/IRQ‑поведения в рамках модели;
верификацию handling ошибок/таймаутов;
проверку sysfs/debugfs интерфейсов (если они есть).

Практический цикл:

Определите, какой virt‑девайс в QEMU соответствует вашему драйверу (например, virtio‑net, virtio‑blk, некоторые UART).
Убедитесь, что драйвер собран в ядро или доступен как модуль (и загрузка модулей включена).
Запустите VM с максимально подробными логами.
Соберите «минимальное воспроизведение»: ограничьте число устройств и сервисов.
Сравните логи между версиями ядра/патчами.

Сбор логов и диагностика

Для ускорения анализа сохраняйте вывод в файлы. В Termux можно собирать консольный вывод в лог.

qemu-system-aarch64 \
  -M virt -cpu cortex-a57 \
  -m 1024 -smp 2 \
  -nographic \
  -kernel ~/lab/qemu/work/Image \
  -initrd ~/lab/qemu/work/initrd.img \
  -append "console=ttyAMA0 root=/dev/vda rw loglevel=7 panic=10" \
  -drive file=~/lab/qemu/images/disk-aarch64.img,format=raw,if=virtio \
  -dtb ~/lab/qemu/work/dtbs/virt.dtb \
  2> ~/lab/qemu/logs/arm64-run.log | tee ~/lab/qemu/logs/arm64-run.stdout.log

Дальше ищите ключевые строки: попытки инициализации, ошибки probing, сообщения от подсистем irq/mmio, и следы падений.

Отладка: gdbstub, serial console и быстрые проверки

QEMU поддерживает удалённую отладку через gdbserver‑подобный механизм. Точные опции зависят от версии QEMU и архитектуры. Общий принцип: включить gdbstub, подключить gdb из Termux (либо кросс‑gdb при необходимости) и поставить точки останова на нужных участках.

Сначала включите gdbstub на нужном порту (примерно; проверяйте актуальный синтаксис вашей сборки):

qemu-system-aarch64 \
  -M virt -cpu cortex-a57 \
  -m 1024 -smp 2 \
  -nographic \
  -kernel ~/lab/qemu/work/Image \
  -initrd ~/lab/qemu/work/initrd.img \
  -append "console=ttyAMA0 root=/dev/vda rw loglevel=7 panic=10" \
  -drive file=~/lab/qemu/images/disk-aarch64.img,format=raw,if=virtio \
  -dtb ~/lab/qemu/work/dtbs/virt.dtb \
  -S -gdb tcp::1234

-S означает «стартовать, но остановиться в начале» — это удобно для ранней диагностики.

Затем в другом окне Termux:

# Убедитесь, что у вас есть gdb подходящей конфигурации.
# Часто для ARM64 нужен aarch64-linux-gnu-gdb (может отсутствовать в базовых репозиториях).

gdb ~/lab/qemu/work/vmlinux
(gdb) target remote :1234
(gdb) continue

Если gdb не подходит из-за отсутствия инструментов кросс‑таргета, используйте анализ по serial‑логу и символам, а также добавляйте printk/tracepoints точечно.

Практический чек‑лист для успешного запуска и тестирования

Проверьте, что ядро запускается в целевой архитектуре (Image/bzImage + правильные параметры консоли).
Убедитесь в корректности связки: kernel/initrd/dtb/rootfs.
Включите подробные логи (loglevel=7, console=ttyS0/ttyAMA0).
Начните с minimal‑состава устройств: virtio‑blk и virtio‑net обычно закрывают базовые сценарии.
Сохраняйте вывод и сравнивайте логи между версиями ядра.
Если что-то «висит», проверьте ожидание консоли и наличие root устройства (root=/dev/vda для virtio‑blk в ARM virt).

Заключение

Виртуализация Android‑устройства через Termux и QEMU — реальный способ организовать переносимую лабораторию для тестирования ядра Linux, воспроизведения сетевых сценариев и подготовки почвы для отладки драйверов в рамках emulated устройств. Начинайте с x86_64 или ARM64 (virt), закрепите рабочие образы и научитесь «снимать» консольные логи, после чего добавляйте gdbstub и точечные отладочные опции по мере необходимости.

Если вам нужно ускорить настройку, подобрать конфигурацию QEMU под вашу цель (архитектура, типы устройств, формат rootfs), а также оформить воспроизводимый тестовый стенд — обратитесь в РыбинскЛАБ. Мы помогаем с настройкой Termux/QEMU‑лабораторий и сопровождением работ по ядру и драйверам.