todo/root/ReSukiSU-install.md

date	tags	aliases	link
2026-07-18	root android kernelsu sukisu install	Установка ReSukiSU ReSukiSU install Прошивка ReSukiSU LKM ReSukiSU	https://resukisu.github.io/guide/install.html

🛠️ Установка ReSukiSU — LKM, AnyKernel3 и ручной патч boot.img

[!info] О чём заметка Пошаговая установка root-решения ReSukiSU на Android по официальной документации проекта (по состоянию на июль 2026). Что такое ReSukiSU, чем он отличается от Magisk/KernelSU и какие у него возможности (KPM, SUSFS, метамодули) — в обзорной заметке root/ReSukiSU. Здесь — только прошивка: где взять менеджер, три способа установки и запасной ручной патч через magiskboot.

[!danger] Нужны базовые навыки прошивки Официальная документация прямо исходит из того, что вы уже умеете прошивать образы через fastboot и знаете, как выводить устройство из «кирпича». Если это не так — сначала разберитесь с азами для вашей конкретной модели. Прошивка несовместимого образа ядра — частая причина того, что устройство перестаёт загружаться. Заранее сохраните резервную копию заводских boot.img / init_boot.img.

[!important] Обязательное условие: разблокированный загрузчик Прошить пропатченный образ через fastboot можно только на разблокированном загрузчике (bootloader). Без этого fastboot flash откажет, и root не поставить никакими способами. Проверьте/включите заранее:

1. Настройки → Для разработчиков → «Заводская разблокировка» (OEM unlocking) — переключатель должен быть включён.
2. Разблокировка делается из fastboot командой fastboot flashing unlock (подтвердить на экране телефона кнопками громкости/питания).

Разблокировка загрузчика стирает все данные устройства (полный wipe) и снижает часть защит — поэтому её делают до настройки телефона или с бэкапом. На кастомных ROM вроде LineageOS загрузчик уже разблокирован (иначе ROM бы не встал), так что отдельно ничего делать не нужно. Некоторые операторские/залоченные устройства разблокировку не позволяют вовсе — тогда kernel-root недоступен.

TL;DR

• Менеджер (APK) на июль 2026 ещё в разработке и не публикуется в GitHub Releases — сборку берут из CI (nightly.link или GitHub Actions), только из ветки main.
• Способ 1 — LKM-установка (ядра ≥ 5.10): менеджер сам патчит boot/init_boot/vendor_boot, вы прошиваете результат. Самый простой путь; большинству устройств достаточно init_boot.
• Способ 2 — AnyKernel3 (GKI и non-GKI): встроенная установка из менеджера, но требует уже полученного root (иначе кнопка не покажется).
• Запасной путь — ручной патч boot.img через magiskboot, когда автопатч не срабатывает. Делается либо прямо на Android-устройстве, либо на ПК.
• Конкретика сильно зависит от модели — сверяйтесь с официальной инструкцией.

Шаг 0. Где взять менеджер (APK)

Менеджер — это приложение, через которое вы управляете root-правами, ставите модули и настраиваете SUSFS. На июль 2026 менеджер ReSukiSU ещё в разработке и намеренно не выкладывается в GitHub Releases (по объяснению авторов — в менеджере слишком много незавершённого). Поэтому сборку берут из непрерывной интеграции (CI — Continuous Integration, автосборка при каждом коммите):

• через nightly.link: https://nightly.link/ReSukiSU/ReSukiSU/workflows/build-manager/main/Manager-release.zip — позволяет скачать файл без входа в GitHub-аккаунт;
• либо напрямую из GitHub Actions проекта (workflow build-manager, ветка main).

[!warning] Только ветка main — стабильная По прямому предупреждению самого проекта: кроме ветки main, все остальные ветки — тестовые (testing branches). Берите сборку менеджера из main. По тестовым веткам авторы просят не присылать баг-репорты, если работа с ними не была запрошена отдельно.

Что лежит в сборке CI и какой файл качать

Одна сборка build-manager в GitHub Actions выкладывает сразу несколько артефактов — не только APK менеджера, но и готовые LKM-модули и служебные бинарники. Обычному пользователю из всего списка нужен только Manager-release (это тот же файл, на который ведёт nightly.link-ссылка выше). Остальное — либо служебное, либо менеджер подтягивает его сам.

Пайплайн собирает менеджер в двух вариантах — normal и spoofed (это отдельные джобы в матрице сборки), плюс отдельными джобами собирает ksuinit, LKM и ksud под каждую архитектуру. В конце есть шаг upload-telegram — то есть свежие сборки могут автоматически публиковаться и в Telegram-канал проекта (в наблюдаемом прогоне от июля 2026 этот шаг был пропущен, так что не полагайтесь на него как на гарантированный канал).

!

Артефакт	Что это	Нужен вручную
Manager-release	Релизный APK менеджера	✅ его и качают
Manager-debug	Отладочный APK (крупнее, с логами) — для разработки	нет
Manager-mappings	Файлы деобфускации R8/ProGuard для расшифровки стектрейсов крашей	нет
Spoofed-Manager-release	Вариант менеджера с «замаскированным» именем пакета/иконкой	опционально — см. ниже
Spoofed-Manager-mappings	Deobfuscation-mappings для spoofed-варианта	нет
androidXX-Y.Z-lkm	Готовые LKM-модули под конкретный KMI (версия Android + ядра): android12-5.10, android13-5.15, android14-6.1, android15-6.6, android16-6.12 и т.д.	нет — менеджер сам подберёт при LKM-патче
ksud-<arch>-linux-android	Userspace-бинарник ksud (демон/CLI KernelSU) под aarch64 / armv7 / x86_64	нет — входит в состав
ksuinit	init-компонент	нет — входит в состав

[!note] Про Spoofed-вариант Наличие двух сборок подтверждается матрицей CI: джобы build-manager (normal, …) и build-manager (spoofed, …) собираются раздельно. Что именно делает «spoofed» — вывод по названию: почти наверняка это сборка со «спуфнутым» (изменённым) именем пакета и иконкой, чтобы приложения-проверяльщики (банки, античиты, Play Integrity) не опознавали сам менеджер по стандартному package name — распространённая функция «скрытия менеджера» в форках KernelSU. Точную механику именно этой сборки уточняйте в документации/сообществе проекта.

[!info] Размеры и хеши — свои в каждой сборке В интерфейсе Actions рядом с каждым артефактом показаны размер и sha256 (например, Manager-release — около 29 МБ). Эти значения меняются от сборки к сборке, поэтому ориентируйтесь на имя артефакта, а не на конкретный размер или хеш из чужого билда.

Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой

LKM (Loadable Kernel Module — загружаемый модуль ядра) — способ добавить ReSukiSU без пересборки всего ядра: менеджер сам патчит загрузочный образ и подгружает модуль. Подходит для ядер версии 5.10 и новее.

Проще говоря: вам не нужно ничего компилировать. Менеджер по параметрам ядра (KMI — Kernel Module Interface, «интерфейс» совместимости) сам подбирает нужный LKM-файл, встраивает его в ваш образ и отдаёт готовый файл — остаётся только прошить.

[!tip] Что значит «ядро ≥ 5.10» и как узнать свою версию Ядро — это версия ядра Linux внутри Android (самый нижний слой системы). Знак ≥ 5.10 означает «версия 5.10 или новее»: подходят 5.10, 5.15, 6.1, 6.6, 6.12 и т.д. Именно с ядра 5.10 Google ввёл GKI 2.0 (Generic Kernel Image — единый образ ядра для многих устройств) со стандартным интерфейсом модулей, поэтому для таких ядер и существуют готовые LKM-файлы. Если ядро старше (например, 4.19, 4.14, 3.18) — LKM-способ не сработает, ставьте через #Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер) или собирайте ядро вручную.

Как проверить свою версию: Настройки → «О телефоне» → «Версия ядра»; либо в терминале/ADB-shell команда uname -r. Смотрите первые два числа: строка вида 5.15.123-android13-… означает ядро 5.15, то есть условие ≥ 5.10 выполнено.

Реальный пример (Google Pixel 9 Pro XL, кодовое имя komodo, LineageOS 23.2): «Версия ядра» показывает 6.1.174-android14-11-g6d16a8dea9bf. Здесь 6.1 — версия ядра (≥ 5.10, значит GKI 2.0 и LKM-способ подходит), а метка android14 — это GKI/KMI-ветка ядра, а не версия Android. Google называет ветку по релизу, с которого она стартовала; ветка не меняется при обновлении ОС, поэтому устройство может работать на более новом Android (в этом примере — LineageOS 23.2, то есть Android 16), сохраняя ядро ветки android14-6.1. Именно пара 6.1 + android14 (а не версия ОС) определяет нужный LKM и точно соответствует имени артефакта из CI — [[#Что лежит в сборке CI и какой файл качать|android14-6.1-lkm]]. Менеджер подберёт его автоматически при LKM-патче, выбирать вручную не нужно.

• Установить и открыть менеджер ReSukiSU (APK из #Шаг 0. Где взять менеджер (APK)).
• Если ядро ≥ 5.10, при статусе «Not Installed» нажатие переведёт на экран установки с опцией «LKM patching/installation».
• Выбрать по подсказкам менеджера файл boot / init_boot / vendor_boot от вашего устройства и нажать «Далее».
• Менеджер быстро определит LKM-файл по KMI, пропатчит образ и сохранит результат KernelSU_patched_*.img в папку загрузок.
• Прошить полученный образ в соответствующий раздел подходящим методом (обычно fastboot).

[!info] Какой файл патчить Устройств, которым нужен патч именно vendor_boot, довольно мало — как правило, достаточно пропатчить init_boot.

«Установить» / «Починить» и откуда берётся сам LKM

На экране LKM-установки менеджер обычно предлагает два действия. Важно понимать: сам LKM-модуль искать и скачивать не нужно — он уже вшит в APK менеджера (это те самые артефакты androidXX-Y.Z-lkm из #Что лежит в сборке CI и какой файл качать). По вашему KMI менеджер выберет нужный .ko сам. От вас требуется только загрузочный образ, в который этот модуль встроят.

• «Установить» (Install) — первичная установка: выбираете init_boot.img, менеджер патчит его и отдаёт KernelSU_patched_*.img.
• «Починить» (Repair/Fix) — повторно наложить патч, когда root слетел (например, после обновления прошивки — см. #Как сделать, чтобы root не слетал после обновлений).

Проще говоря: «Установить LKM» = «возьми мой init_boot.img и вставь в него готовый модуль ядра». Модуль у менеджера уже есть — ему нужен только ваш образ.

Где взять init_boot.img (на примере Google Pixel)

Образ обязан точно соответствовать прошивке, которая сейчас стоит на телефоне — иначе устройство может не загрузиться. На Pixel с Android 13+ патчат именно init_boot, а не boot.

• Сток (заводская прошивка): скачать factory image для вашей модели с 🔗 Google Developers → Factory Images, распаковать архив и достать из него init_boot.img.
• LineageOS: обычно init_boot.img лежит отдельным файлом на странице сборки — качается напрямую, распаковывать payload.bin не нужно. Пример для Pixel 9 Pro XL (кодовое имя komodo): страница download.lineageos.org/devices/komodo/builds → рядом со сборкой ссылка вида …/full/komodo/<дата>/init_boot.img. Дата в ссылке должна совпадать с установленной сборкой.
• Другой кастом (если отдельного init_boot.img нет): взять его из zip/payload.bin той же сборки, что прошита. Если внутри payload.bin — распаковать через 🔗 payload-dumper-go и достать init_boot.img.
• Сохранить оригинальный init_boot.img отдельно — понадобится для отката.

[!warning] Версия образа должна совпадать с установленной Патчить нужно init_boot ровно того билд-номера, что сейчас на устройстве. init_boot от другой версии Android или патча безопасности может не загрузиться. Билд-номер смотрите в Настройки → «О телефоне» → «Номер сборки». После обновления прошивки образ меняется — поэтому root и «слетает», и патч приходится накладывать заново (кнопка «Починить»).

Как прошить пропатченный образ через fastboot

После того как менеджер отдал KernelSU_patched_*.img, его нужно записать в раздел init_boot через fastboot. Понадобятся adb и fastboot из Android platform-tools и #Обязательное условие: разблокированный загрузчик.

• Перевести телефон в режим fastboot (bootloader). Командой adb reboot bootloader (если включена отладка по USB и ПК авторизован) либо вручную: выключить телефон и зажать Volume Down + Power.
• Убедиться, что fastboot видит устройство: fastboot devices — должна появиться строка с серийником и словом fastboot. (В fastboot-режиме подтверждение авторизации, как в ADB, не требуется.)
• Прошить образ в init_boot: fastboot flash init_boot путь/к/KernelSU_patched_*.img. На A/B-устройствах (все современные Pixel) это запишется в активный слот автоматически.
• Перезагрузиться: fastboot reboot.
• После загрузки открыть менеджер ReSukiSU — статус сменится с «Not Installed» на установленный (покажет версию, Working). Проверить root любым приложением, запрашивающим суперпользователя.

[!example] Реальный пример: Pixel 9 Pro XL (komodo) на LineageOS

# 1. в bootloader
adb reboot bootloader
# 2. проверка
fastboot devices          # → 52041FDAS…  fastboot
# 3. прошивка (образ от менеджера)
fastboot flash init_boot kernelsu_patched_20260718_140228.img
# → Sending 'init_boot_a' ... OKAY / Writing 'init_boot_a' ... OKAY
# 4. перезагрузка
fastboot reboot

Раздел записался как init_boot_a (активный слот A), после ребута менеджер ReSukiSU показал рабочий root. Серийный номер устройства здесь скрыт — публиковать его не нужно.

[!note] Если fastboot — Windows-бинарник (например, из WSL) fastboot.exe понимает только Windows-пути. Путь вида /mnt/d/... (WSL) он не найдёт — передавайте образ Windows-путём в кавычках: fastboot.exe flash init_boot 'D:\downloads\KernelSU_patched.img'.

[!danger] На случай бутлупа и про блокировку загрузчика

• Если после прошивки устройство не загружается (висит на логотипе, бутлуп) — прошейте обратно оригинальный (непатченный) init_boot.img той же сборки: fastboot flash init_boot init_boot.img. Поэтому оригинал и просят сохранить заранее.
• Не блокируйте загрузчик (fastboot flashing lock) с кастомным init_boot — это почти гарантированный «кирпич». Загрузчик должен оставаться разблокированным, пока стоит root.

Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер)

AnyKernel3 — универсальный формат установочного архива, который сам находит нужный раздел и подменяет ядро. В менеджере ReSukiSU встроен способ установки через AnyKernel3, но эта опция не показывается, если у менеджера нет root-доступа. Чтобы её включить, обычно нужно:

1. Сначала получить root через LKM-установку (#Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой), затем прошить AnyKernel3, чтобы выдать root.
2. Либо вручную пропатчить boot.img через magiskboot (см. ниже).

Проще говоря: встроенная AnyKernel3-установка — «для тех, у кого root уже есть». Если root ещё нет, начните с LKM-установки, а AnyKernel3 примените уже поверх неё.

Ручной патч boot.img через magiskboot (если LKM не подходит)

Запасной путь, когда автоматический патч не срабатывает. magiskboot — утилита из проекта Magisk для распаковки/сборки загрузочных образов. Раздел ниже основан на официальной документации KernelSU, на которую ссылается сам ReSukiSU.

Понадобятся два инструмента:

• 🔗 magiskboot — официальная сборка (входит в состав Magisk);
• 🔗 magiskboot_build — отдельная сборка, если хотите запускать magiskboot на ПК.

[!note] Официальный magiskboot — только под Android (и Linux) Официальная сборка magiskboot рассчитана на запуск на Android-устройстве. Если нужно на ПК — берите magiskboot_build. Исключение: под Linux официальная сборка тоже работает нормально, так что пользователи Linux могут взять официальную.

Подготовка

• Получить заводской boot.img для вашей модели — у производителя или из прошивки. Если прошивка идёт единым payload.bin, образ достают инструментом 🔗 payload-dumper-go.
• Распаковать AnyKernel3-архив ReSukiSU и достать из него файл Image — это и есть ядро KernelSU/ReSukiSU.

Вариант А. Прямо на Android-устройстве

Использует библиотеку libmagiskboot.so, спрятанную внутри APK Magisk.

• Скачать свежий Magisk из GitHub Releases.
• Переименовать Magisk-*(версия).apk в Magisk-*.zip и распаковать.
• Закинуть libmagiskboot.so на устройство через ADB: adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot.
• Закинуть туда же заводской boot.img и файл Image из AnyKernel3.
• В ADB-shell перейти в каталог и сделать бинарник исполняемым:

cd /data/local/tmp/
chmod +x magiskboot
./magiskboot unpack boot.img
mv -f Image kernel
./magiskboot repack boot.img

• Прошить полученный new-boot.img через fastboot.

Вариант Б. На ПК (Windows / macOS / Linux)

• Скачать бинарник magiskboot под вашу ОС из ookiineko/magiskboot_build (релиз last-ci); под Linux можно взять официальную сборку.
• Положить рядом заводской boot.img и Image.
• Собрать новый образ:

chmod +x magiskboot
./magiskboot unpack boot.img
mv -f Image kernel
./magiskboot repack boot.img

• Прошить полученный new-boot.img через fastboot.

Что делают команды: unpack распаковывает boot.img и достаёт из него kernel (ваше заводское ядро); mv -f Image kernel заменяет заводское ядро на ядро ReSukiSU; repack собирает образ обратно в new-boot.img.

Root и обновления прошивки (OTA, кастомные ROM)

Частая жалоба: root «слетает» — обычно после обновления прошивки (OTA), особенно на кастомных ROM вроде LineageOS с их частыми апдейтами. Важно понимать, что это не баг конкретного root-решения, а следствие того, как root устроен.

Почему слетает. И Magisk, и ReSukiSU в #Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой патчат раздел boot/init_boot. Обновление прошивки перезаписывает этот раздел свежим образом — и патч вместе с ним исчезает. Поэтому смена Magisk → ReSukiSU сама по себе проблему потери root после OTA не решает: механика у них одинаковая.

Проще говоря: LKM-root — это «заплатка поверх загрузочного образа». Приходит обновление, кладёт новый образ — заплатки больше нет. Так у всех, кто патчит boot/init_boot.

Как сделать, чтобы root не слетал после обновлений

• Пере-патчить после каждого апдейта. Стандартный путь: обновили ROM → снова прогнали LKM-патч свежего init_boot (кнопка «Починить» в менеджере — см. #«Установить» / «Починить» и откуда берётся сам LKM) → прошили. Ручная работа, но надёжно.
• Встроить root прямо в ядро сборки. Если использовать ядро/сборку с уже вкомпилированным KernelSU (не LKM, а собранное ядро — путь #Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер)/ручной сборки), root становится частью ядра и переживает обновления ROM. Требует подходящего kernel-образа под вашу модель — ищите в сообществе устройства.

[!warning] ReSukiSU на кастомных ROM — без гарантий KernelSU-семейство на GKI-устройствах в целом работает независимо от прошивки, но ReSukiSU — молодой форк (root/ReSukiSU#Цепочка форков: KernelSU → SukiSU-Ultra → ReSukiSU), и на конкретной сборке LineageOS его совместимость заранее не гарантирована. Возможны краевые случаи (нестандартное ядро сборки, конфликты). Держите резервную копию оригинального init_boot.img для отката.

Если root не поднялся (Not Installed): диагностика

Бывает, что образ прошит правильно, устройство загрузилось, но менеджер вверху показывает целиком «Not Installed», и никакое приложение root не получает. Частый случай именно на кастомных ROM (LineageOS и т.п.) при #Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой. Ниже — как отличить «не прошилось» от «прошилось, но модуль не загрузился», на примере реального разбора (Pixel 9 Pro XL, LineageOS).

Шаг 1. Проверить, загрузился ли модуль в ядро

С компьютера по ADB (root для этих команд не нужен):

adb shell 'ls /sys/module | grep -iE "ksu|kernelsu"'   # пусто → модуль НЕ загружен
adb shell getprop ro.boot.slot_suffix                   # активный слот (_a / _b)
adb shell uname -r                                      # версия ядра

• /sys/module пуст по ksu/kernelsu → ядерная часть KernelSU не поднялась. Это и есть причина «Not Installed».
• Слот должен совпадать с тем, куда вы шили (fastboot flash init_boot пишет в активный слот). Если слот переключился — патч ушёл в неактивный.
• uname -r при LKM не меняется — LKM подгружает модуль в готовое ядро, а не заменяет его. Так что неизменная строка ядра здесь не признак сбоя.

Шаг 2. Посмотреть, не падает ли ksud

adb logcat -d | grep -iE "ksud|kernelsu|libksud"

Характерный симптом провала — падение демона ksud:

libc: Fatal signal 31 (SIGSYS), code 1 (SYS_SECCOMP), syscall 142 in tid … (libksud.so)

Что это значит: libksud.so (ksud) — userspace-демон KernelSU. Когда ядерная часть есть, он запускается из init-контекста без seccomp-ограничений. Если ядерной части нет, менеджер пытается дёрнуть ksud как обычный процесс приложения, тот натыкается на seccomp-фильтр Android и убивается сигналом SIGSYS. То есть падение ksud с SECCOMP — следствие того, что модуль не загрузился, а не отдельная поломка.

Почему LKM не грузится на кастомном ROM (LineageOS и т.п.)

LKM — это готовый бинарный модуль (androidXX-Y.Z-lkm), собранный под стоковое ядро Google. Он загрузится только в совместимое ядро. А кастомные прошивки, в отличие от стока, собирают ядро из исходников сами (LineageOS не берёт готовый GKI-образ Google, а компилирует свой — это видно из процесса сборки Pixel-ядер). Самосборное ядро имеет другой vermagic/KMI, и generic-модуль в него не встаёт.

Для LineageOS есть даже точный диагноз в трекере KernelSU: 🔗 issue #2685 (июль 2025). LineageOS (и производные — /e/OS, iodéOS) обрезают в строке версии ядра поле androidXX-N — например, вместо 5.15.176-android13-8-g… получается 5.15.176-g…. Из-за этого менеджер не может автоматически определить KMI, и подобрать/загрузить нужный LKM не выходит. В LKM-режиме на таких ROM приходится выбирать KMI вручную при каждом OTA, и ошибка выбора грозит бутлупом.

Проще говоря: LKM — «деталь под заводское ядро». LineageOS ставит своё, самосборное ядро — деталь к нему не подходит, root не активируется. Ошибки в ваших командах при этом нет.

[!tip] Что делать, если LKM не поднялся

• Проверьте слот и версию образа — что шили в активный слот и что init_boot был от ровно той сборки, что стоит.
• На кастомном ROM надёжнее не LKM, а GKI-mode — ядро с уже вкомпилированным KernelSU/ReSukiSU (#Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер)). Самый надёжный вариант — собрать ядро из исходников самой LineageOS с интегрированным KernelSU (тогда vermagic совпадёт). Готовые generic-GKI ядра (WildKernels, ShirkNeko/SukiSU, Sultan) собраны под сток, заменяют ядро LineageOS и могут ломать OTA, датчики или вызывать бутлуп — берите их только с бэкапом стоковых boot.img/init_boot.img и строго под вашу KMI-ветку.
• Проще всего — root/Magisk-install. Он патчит рамдиск init_boot и не зависит от vermagic ядра, поэтому на LineageOS заводится там, где LKM-KernelSU нет. Плата — тот же #Root и обновления прошивки (OTA, кастомные ROM). Подробнее о выборе — в root/ReSukiSU#KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать.
• Откат: прошейте обратно оригинальный (непатченный) init_boot.img той же сборки — fastboot flash init_boot init_boot.img — и телефон вернётся к состоянию без root.

После прошивки: SUSFS и KPM

[!note] SUSFS и KPM настраиваются отдельно Страница установки описывает только базовую прошивку ReSukiSU. Настройка SUSFS (скрытие root от приложений-проверяльщиков) и работа с KPM-модулями (код в пространстве ядра) делаются уже после установки — через сам менеджер и совместимое ядро. Что это за технологии и какие у них ограничения — в обзорной заметке root/ReSukiSU#Возможности; конкретные шаги ищите в соответствующих разделах документации и в Telegram-сообществе проекта.

[!danger] Осторожно с прошивкой ядра Прошивка несовместимого образа — частая причина «кирпича» (устройство не загружается). Ставьте образ только под точную модель и версию вашего устройства и заранее сохраните резервную копию заводских boot.img / init_boot.img. Root снимает часть защит устройства и может влиять на гарантию и работу банковских/платёжных приложений.

📚 См. также

• root/ReSukiSU — обзорная заметка: что это, цепочка форков KernelSU → SukiSU → ReSukiSU, возможности (KPM, SUSFS, метамодули), поддерживаемые устройства
• Zapret/android — смежная тема: DPI и блокировки на телефоне (root не требуется, но иногда с ним удобнее)
• 🔗 Инструкция по установке ReSukiSU — официальный первоисточник этой заметки
• 🔗 Документация KernelSU — откуда взят раздел ручного патча magiskboot
• 🔗 payload-dumper-go — извлечение boot.img из payload.bin
• 🔗 magiskboot_build — сборка magiskboot для ПК
• 🔗 KernelSU issue #2685 — почему LKM не грузится на LineageOS (обрезанная строка KMI), июль 2025
• 🔗 Building Pixel Kernels (source.android.com) — подтверждение, что кастомные ROM собирают ядро сами
• 🔗 Rescue from bootloop (KernelSU) — восстановление при бутлупе

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.