Построение кастомного ядра Linux в Termux: кросс‑компиляция, патчинг, модульная загрузка и отладка через gdb‑server

Termux позволяет запускать множество инструментов сборки в среде Android без установки полноценной виртуальной машины. Однако сборка кастомного ядра Linux требует аккуратной кросс‑компиляции, грамотной подготовки исходников, а также понимания ограничений платформы Android/ARM.

В этой статье рассмотрим практический, легальный и инженерный подход: подготовка окружения в Termux, выбор и настройка кросс‑компилятора, патчинг исходников Linux, сборка ядра и модулей, модульная загрузка при наличии совместимого окружения, а также отладка через gdb‑server. Материал ориентирован на работу с исходниками, которые вы можете законно скачать/получить, и на эксперименты в рамках ваших устройств и вашей инфраструктуры.

Требования и оговорки по платформе

Архитектура: чаще всего для Android/Termux встречаются ARMv7/ARM64. Для каждого варианта нужен корректный toolchain.
Версия ядра: выбирайте ветку, совместимую с вашей платформой и (если вы используете) с конфигурациями, соответствующими устройству.
Среда исполнения: Termux сам по себе не является ядром и не загружает модули “как на обычной Линукс‑системе”. Для модульной загрузки обычно требуется дополнительная среда/права/доступ к ядру устройства (например, root и подходящая структура файловой системы). Эти шаги описываются как общие инженерные практики; конкретные команды зависят от вашего окружения.
Отладка: gdb‑server применим, когда у вас есть корректный канал для отладки (локальная сеть и/или доступ к среде, где запущен отладочный сервер). Мы не обсуждаем обход блокировок или несанкционированные действия.

Подготовка Termux: пакеты и базовая структура проекта

Сначала обновим пакеты и установим необходимые инструменты сборки.

pkg update
pkg upgrade -y
pkg install -y git clang make bc bison flex openssl-tool proot-distro pkg-config ncurses-utils

Затем создадим рабочую директорию. Рекомендуется отделять исходники ядра и артефакты сборки.

mkdir -p ~/kernel-work/linux-custom
cd ~/kernel-work/linux-custom

Получение исходников ядра и проверка целевой конфигурации

Скачайте исходники ядра из официального репозитория или из доверенного источника. Пример ниже использует git.

git clone --depth=1 https://github.com/torvalds/linux.git ~/kernel-work/linux-custom/linux

Дальше определите, под какую архитектуру и устройство вы строите ядро. Если у вас есть существующая конфигурация (.config) от целевой системы, используйте её как основу. Если конфигурации нет, потребуется разработка/подбор конфигурации под вашу плату (что выходит за рамки “универсального” рецепта).

Копирование найденной конфигурации в рабочую директорию:

cd ~/kernel-work/linux-custom/linux
# пример: если у вас есть готовый файл конфигурации
cp /path/to/your-config .config

После этого полезно обновить конфигурацию с учётом текущих опций ядра:

make olddefconfig

Кросс‑компиляция: выбор toolchain и настройка окружения

На Android в Termux вы обычно используете clang/llvm либо отдельный cross‑gcc toolchain. В современных процессах сборки ядра часто удобно использовать clang. Ниже приведён подход, который обычно хорошо работает, но при необходимости корректируйте переменные под вашу архитектуру.

Предположим, что вы собираете для ARM64. Убедитесь, что архитектура соответствует вашей задаче.

Установим переменные окружения для сборки. Для ARM64:

export ARCH=arm64
export SUBARCH=arm64

Опционально задайте префикс для toolchain. Для clang обычно достаточно задать CC и при необходимости CROSS_COMPILE (если вы используете gcc toolchain).

export CC=clang
export LD=ld.lld
export LLVM=1

Если вы предпочитаете gcc cross‑toolchain, то задайте CROSS_COMPILE, например:

# Пример для иллюстрации (подставьте свой префикс и пакет/toolchain):
# export CROSS_COMPILE=aarch64-linux-gnu-
# export ARCH=arm64

Важно: для gcc toolchain нужно установить соответствующий набор пакетов (или сборочный toolchain) в Termux. Если вы не уверены, используйте clang‑путь или уточните вашу архитектуру/окружение.

Подготовка системы сборки: clean, дефолтные цели и артефакты

Для контрольной сборки можно использовать чистую подготовку (это полезно при смене конфигурации или toolchain):

make clean

Создание базовой сборки:

make -j$(nproc) Image modules

В зависимости от конфигурации ядра, целевые артефакты могут называться иначе. Для отладки удобнее собирать с отладочными символами и включать нужные опции (см. следующий раздел).

Патчинг ядра: рабочий процесс с git

Кастомизация ядра обычно сводится к патчам. Чтобы это было управляемо, используйте отдельные ветки.

cd ~/kernel-work/linux-custom/linux
git checkout -b custom/termux-kernel

Добавьте патч (например, из файла) или вносите изменения напрямую в исходники. Если патч уже есть:

git apply --stat /path/to/your.patch
git apply /path/to/your.patch

Проверьте, что изменения применились:

git status

Дальше зафиксируйте изменения:

git add -A
git commit -m "Custom changes for experimental kernel build"

Сборка с отладочными символами и поддержкой модулей

Для корректной отладки и удобства анализа (например, в gdb) нужно обеспечить наличие отладочных символов. Практически: включайте в конфигурации ядра опции отладки и сборку модулей.

Обычно полезны:

включение MODULES (поддержка модулей)
включение символов/отладки: опции, связанные с DEBUG_INFO и режимами разработки
выделение модульного ABI/версий (если планируете загружать модули в чужую среду)

Поскольку точные названия зависят от версии ядра и Kconfig, используйте поиск по конфигу после запуска интерактивного конфигуратором:

make menuconfig

После настройки соберите:

make -j$(nproc) Image modules

Собранные модули обычно оказываются в:

~/kernel-work/linux-custom/linux/modules

Но путь к артефактам модулей в реальности зависит от конфигурации; чаще используется:

make modules_install INSTALL_MOD_PATH=/path/to/output-rootfs

Например, чтобы сформировать “корень” для модулярной установки:

mkdir -p ~/kernel-work/out/modules-root
make modules_install INSTALL_MOD_PATH=~/kernel-work/out/modules-root

Модульная загрузка: общий инженерный подход

Загрузка модулей требует, чтобы:

ядро, с которым вы работаете на устройстве, совпадало по ABI/версии (как минимум, модульный интерфейс)
модульный каталог соответствовал формату вашей системы (/lib/modules/$(uname -r))
у вас были необходимые привилегии (часто требуются root или эквивалент доступа к insmod/modprobe)

Обычно следующий сценарий выглядит так (командный каркас):

# 1) Скопировать .ko файлы в целевую среду
# 2) Обновить индексы модулей (если используете depmod/modprobe)
# 3) Загрузить модуль

# пример каркаса (на целевой системе):
depmod -a
modprobe your_module_name

Если вы загружаете модуль напрямую:

insmod /path/to/your_module.ko

Если модуль не загружается, типичные причины:

несовпадение версии ядра и модульного ABI
отсутствие зависимостей (нужно подгрузить другие модули)
несоответствие конфигурационных опций (например, символы/экспорт)

В “боевых” экспериментах важно вести журнал ошибок dmesg (на целевой системе) и сопоставлять его с тем, что вы меняли в коде ядра.

Подготовка для отладки: gdb‑server и локальная сеть

Для отладки удобнее использовать локальную сеть (без обхода блокировок): например, раздачу доступа с точки доступа вашего хоста/устройства, чтобы вы могли связать Termux‑среду и машину разработчика.

В вашем окружении должен быть доступен gdb‑server. В Termux можно попытаться использовать поставляемые пакеты (если они доступны для вашей сборки Termux), либо запустить gdb‑server в той среде, где он уместен.

Каркас запуска gdb‑server обычно выглядит так (адрес и параметры зависят от вашей целевой задачи):

# На стороне, где доступен gdb-server:
gdbserver :1234 /path/to/your/target_binary

Если отлаживается процесс:

# пример каркаса:
gdbserver :1234 --attach <PID>

Подключение отладчика на машине разработки:

# На вашей dev-машине:
gdb /path/to/vmlinux
(gdb) target remote <IP_устройства>:1234
(gdb) break your_function
(gdb) continue

Для ядра критичны:

наличие корректного vmlinux с отладочными символами
совпадение образа и символов (другая сборка — и точки останова будут “мимо”)
правильная архитектура и ABI

Сборка артефактов для отладки: что важно сохранить

Обычно для отладки нужны:

vmlinux (или эквивалентный отладочный бинарник ядра)
образ ядра (Image/Image.gz, зависит от сборки)
модули (.ko) и соответствующие модулярные символы (если включены)

Если у вас включена сборка отладочных символов, сохраните артефакты в структуре “из коробки” для воспроизводимости:

mkdir -p ~/kernel-work/out/debug-artifacts
cp -v arch/$ARCH/boot/Image ~/kernel-work/out/debug-artifacts/ 2>/dev/null || true
cp -v vmlinux ~/kernel-work/out/debug-artifacts/
cp -v System.map ~/kernel-work/out/debug-artifacts/

Типовые проблемы и методы диагностики

Ошибки линковки/компиляции: проверьте ARCH, CC/LLVM, а также версию зависимостей. Полезно сохранять лог сборки в файл.
Несовпадение модулей и ядра: используйте точную версию ядра и одинаковую конфигурацию, следите за uname -r на целевой системе.
Падения при загрузке модуля: смотрите dmesg, включайте больше логирования в ваш модуль/изменения, проверяйте указатели, контракты и экспортируемые символы.
Проблемы с отладкой: убедитесь, что символы совпадают с загруженным образом. Проверьте, что адресное пространство/архитектура корректны, и что отладка действительно поддерживается в выбранной связке.

Заключение

Построение кастомного ядра Linux в Termux — это реалистичная и полезная инженерная задача, но она требует дисциплины: правильная кросс‑компиляция, управляемый патчинг исходников, контроль модульной совместимости и аккуратная отладка с использованием gdb‑server в рамках локального взаимодействия. Следуя описанному подходу, вы сможете системно экспериментировать с ядром и быстрее добиваться воспроизводимых результатов.

Если вам нужна помощь с настройкой окружения, подбором конфигурации под устройство, оптимизацией сборки или организацией отладочного пайплайна, команда РыбинскЛАБ поможет выполнить проект под ключ.