TL;DR: What is init_boot? It is the Android 13+ partition that stores the generic ramdisk and first-stage init on devices launched with Android 13 or later. Rooting tools such as Magisk may patch it instead of boot.img. The device’s launch version and exact firmware layout determine which image you need.
By the PrivacyPortal team
Last updated August 2026
If you are asking what is init_boot, the key point is that it separates early Android start-up files from the kernel. On newer devices, boot.img mainly contains the Generic Kernel Image, or GKI. The init_boot ramdisk contains first-stage init and other files needed before Android mounts its main partitions. Magisk can alter this ramdisk to start its root environment. However, an Android 13 update does not create this layout on every older phone. A device launched with Android 12 may still need boot.img after upgrading. Check the factory firmware before patching anything.
Back up your files before starting. Unlocking the bootloader normally wipes all user data. Rooting can also affect warranty support, over-the-air updates, banking apps, Play Integrity checks and device security.
What is init_boot in Android?
init_boot is a physical partition and a matching firmware image named init_boot.img. It was introduced for devices launching with Android 13. Its main purpose is to hold the generic ramdisk separately from the kernel.
A ramdisk is a small, temporary file system loaded during boot. It contains early start-up tools and configuration. First-stage init uses these files to prepare storage, security policy and later parts of Android.
Android’s Generic Kernel Image model lets manufacturers share a more standard kernel design. Moving the generic ramdisk into init_boot helps keep the boot image focused on the GKI kernel. Vendor-specific boot files may also live in vendor_boot.
Android’s boot-image documentation states that devices launching with Android 13 move the generic ramdisk from boot into a separate init_boot image.
The full layout is documented in the Android generic boot partition guidance.
Image caption: A boot-flow diagram showing the bootloader loading boot, init_boot and vendor_boot before Android starts.
init_boot vs boot.img
The right image depends on the device’s launch architecture. It does not depend only on the Android version shown in Settings.
| Image | Typical contents | Common rooting role |
|---|---|---|
| init_boot.img | Generic ramdisk and first-stage init | Usually patched by Magisk on devices launched with Android 13 or later |
| boot.img | Kernel, and on older layouts the generic ramdisk | Patched by Magisk on older layouts; also relevant to kernel-based root |
| vendor_boot.img | Vendor ramdisks and device-specific boot data | Only patch when a device-specific, trusted guide explicitly requires it |
| vbmeta.img | Android Verified Boot metadata | Not a general root image; changing verification creates extra security risk |
A Pixel or other phone launched on Android 13 will usually expose init_boot. A phone launched on Android 12 may keep its older boot layout after an Android 13, 14, 15 or 16 update.
Do not guess from a forum filename. Open the official firmware package for your exact model and build. If it contains init_boot.img, check the root manager’s official instructions before choosing it.
Why Magisk patches init_boot
Magisk gains root by changing early boot files. On an older layout, those files sit in boot.img. On a launch-era Android 13+ layout, they sit in init_boot.img. That is why a current guide may tell you to patch init_boot Magisk-style rather than patch boot.
The Magisk app unpacks the selected image, adds its start-up components and repacks it. It does not turn init_boot into a replacement kernel. The patched image must match the installed firmware build.
Use the stable Magisk release offered through the official project. Magisk v29.0 remains a useful documented reference from 2025, but releases and Android support continue to change. Confirm current requirements in the official Magisk installation guide.
Magisk’s official installation guide says an image must be patched on the same device where it will be installed.
Never download a stranger’s pre-patched image. Even the same retail model can have regional variants or different monthly builds. A mismatched image may cause a boot loop. An untrusted image could also contain persistent malicious changes.
How to patch and flash init_boot with Magisk
This workflow covers a typical bootloader-unlocked device that officially supports fastboot flashing.
- Back up photos, messages, authenticator recovery codes and app data. Confirm the backup can be opened.
- Record the exact model, region and Android build number. Charge the phone before entering the bootloader.
- Download the matching full factory firmware from the device maker. Extract its original init_boot.img.
- Install the official Magisk app listed in the files section. Copy the stock init_boot.img to the phone.
- In Magisk, choose Install, then Select and Patch a File. Select the untouched init_boot.img.
- Copy the resulting magisk_patched image back to the computer. Keep the original image beside it for recovery.
- Install current Android SDK Platform-Tools. Run adb reboot bootloader, then confirm fastboot devices detects one device.
- Check the active slot with fastboot getvar current-slot. Follow the maker’s flashing rules for that model.
- Flash with fastboot flash init_boot magisk_patched.img, using the real generated filename. Do not flash boot.img by habit.
- Run fastboot reboot. Open Magisk after Android starts and complete any prompted setup.
Prerequisites before flashing
You need an unlocked bootloader, the exact stock firmware and a reliable data cable. You also need working OEM USB drivers on Windows. The Android SDK Platform-Tools package supplies adb and fastboot.
Bootloader unlocking normally performs a factory reset. Some manufacturers do not permit unlocking. Others use a waiting period or account approval. Read the maker’s process before enabling OEM unlocking.
Review our bootloader unlocking guide before wiping the device. The appended “Modules, apps & files to try” section should be your checklist for the required app and tools.
Image caption: Magisk’s file-selection screen with a stock init_boot.img ready for local patching.
How to verify the result
First, confirm Android reaches the lock screen and completes one normal reboot. Open Magisk and check that it reports an installed version rather than only an app version.
A terminal check can use adb shell su -c id. Approve the request on the phone. A working root shell normally reports user ID 0. Root-checking apps can help, but they also gain sensitive device information. Use a reputable open-source option.
Test calls, Wi-Fi, Bluetooth, the camera and encryption. Then test any essential work, payment or media apps. Root access does not guarantee that an app will pass Play Integrity or its own security checks.
How to identify the correct image
Use a three-part decision check before patching:
- Launch version: Find the Android version supplied when the model first went on sale.
- Firmware contents: Inspect the exact factory package for init_boot.img and boot.img.
- Manager instructions: Confirm which image your chosen root method expects.
If the phone launched with Android 13 or later and the package includes init_boot.img, Magisk will commonly patch init_boot. If the phone launched earlier and boot.img includes the ramdisk, Magisk will commonly patch boot.
Payload-based firmware may store images inside payload.bin. Use a well-reviewed payload extraction tool and compare the extracted build with Settings. Do not use an image from an incremental OTA unless the extraction method is known to preserve it correctly.
On A/B devices, both slots may hold separate boot-critical images. Check the active slot before flashing. An OTA can switch slots and restore stock images, removing root until the new matching image is patched.
Magisk, KernelSU and APatch are not interchangeable
Magisk, KernelSU and APatch reach root through different parts of the boot chain. A file patched for one manager is not a universal rooted image.
- Magisk: modifies the boot ramdisk. On a suitable Android 13+ layout, this normally means init_boot.img.
- KernelSU: places root support in the kernel. It needs a supported or patched kernel, often involving boot.img rather than Magisk’s init_boot patch.
- APatch: uses kernel-level patching and its own Kernel Patch Module system. Its setup and compatibility rules differ from Magisk.
A Magisk-patched image is not a valid KernelSU image. KernelSU also has different paths for supported GKI kernels, loadable kernel modules and device-specific builds. Read the official KernelSU installation documentation before selecting an image.
Use an original stock image when changing managers. Trying to patch an image already modified by Magisk can produce an error such as “Cannot work with Magisk patched image” or create an unbootable mix.
Common init_boot mistakes and recovery
Flashing an image from the wrong build
A monthly update can change boot-critical files without changing the phone’s marketing name. Patch the image from the build currently installed. Keep the complete stock package before flashing.
If the phone returns to fastboot, flash the matching stock init_boot image using the maker’s documented command. Do not relock the bootloader while modified partitions remain. Relocking in that state can make recovery harder or trigger a data wipe.
Patching boot.img when init_boot is required
This mistake may fail to install root or stop the device booting. Check both the factory package and Magisk’s installation result. The answer to what is init_boot matters because the ramdisk’s real location decides which file Magisk must alter.
A filename copied from an old guide is weak evidence. Guides written for an earlier model can remain highly ranked after the hardware layout changes.
Fastboot reports “Too many links”
On Windows, “FAILED (Status read failed: Too many links)” usually points to USB communication. It does not mean Android contains too many symbolic links.
- Try another cable and a direct USB port. USB 2.0 ports can be more stable.
- Disconnect unneeded USB devices and update the bootloader driver.
- Run fastboot reboot-bootloader, then retry detection.
- Charge the phone first because some models charge slowly in fastboot.
Disabling verification without understanding it
Some MediaTek and device-specific guides alter vbmeta to accept modified images. This weakens Android Verified Boot and is not a routine init_boot step. Never copy a vbmeta command from another model.
Android Verified Boot includes rollback protection to stop a device accepting an older software version that may contain known flaws.
Image caption: A fastboot screen beside labelled stock and patched images, showing why exact filenames and builds matter.
Security, updates and app compatibility
An unlocked bootloader warns that the operating system can be modified. Root then gives approved processes very broad access. A malicious root module can read data or change the system beyond normal Android sandbox limits.
Only install modules you can trace to a reputable project. Check source code, release history and issue reports. Remove abandoned modules before major Android updates.
Over-the-air updates often replace init_boot, boot or both. Root may disappear after an update. Patching an old image over a new build can cause a boot failure. Restore stock state or use the manager’s documented A/B update process.
Banking, work-profile, streaming and contactless-payment apps can use Play Integrity plus private detection. Results vary by device, app release and security policy. No module can promise lasting access to a specific bank.
For a wider risk assessment, see our guide to Android rooting security. PrivacyPortal also offers privacy-first Android phones for readers who want less Google dependence without maintaining a rooted device.
Frequently asked questions
Can I delete init_boot?
No. init_boot is part of the verified boot chain on devices that use it. Erasing it can stop Android starting. Keep an exact stock copy, but do not delete the live partition.
Does every Android 13 phone have init_boot?
No. The rule concerns the Android version at device launch. A phone upgraded from Android 12 can retain a boot image that contains the ramdisk. Inspect its official firmware.
Should I patch init_boot or boot.img with Magisk?
Patch the image containing the generic ramdisk for that device. This is commonly init_boot on phones launched with Android 13 or later. Older launch layouts commonly use boot.img. Magisk’s result and official device firmware should agree.
Can I flash a patched init_boot from another phone?
No. Patch the stock image for your exact device, region and installed build on the device that will use it. A shared patched image may fail to boot or contain unwanted changes.
Can fastboot boot a patched init_boot without flashing it?
Do not assume so. Temporary boot support varies by bootloader and image type. Some devices reject the command or handle it differently. Use the manufacturer’s documented recovery and flashing path.
Will rooting init_boot make banking apps work?
Rooting does not make banking apps work. It may cause them to refuse access. Apps can check the bootloader, Play Integrity results, root components and their own risk signals. Never rely on a promised bypass for a specific bank.
What is init_boot in one sentence?
init_boot is the Android 13-era partition that holds the generic ramdisk and first-stage init on devices built with that launch architecture.
A safe final checklist
- Back up first and confirm the backup works.
- Expect bootloader unlocking to wipe the phone.
- Match the model, region, slot and installed firmware build.
- Use an untouched stock image from an official package.
- Patch the file locally with the intended root manager.
- Keep stock init_boot and boot images ready for recovery.
- Expect possible warranty, OTA, Play Integrity and app issues.
- Never relock while modified boot-critical images remain.
Careful image selection matters more than copying a fastboot command. When the firmware layout or manager support is unclear, stop and research the exact model. A delayed root attempt is far easier to fix than a phone that cannot boot.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
