Android Partition Mounting Process and Common Issues

Previous chapter: Android Partition Mounting Principle (Part 1)

3. Partition Mounting Process Overview

Mount Order

Physical Partition

Mount Point

Logical Partition?

AVB Verification

AVB Info Location

Mount Stage

fstab Effective Location

1

metadata

/metadata

No

No

N/A

init first stage

vendor_boot (ramdisk)

2

super

/system

Yes

Yes

vbmeta_system

init first stage

vendor_boot (ramdisk)

Additional rows omitted for brevity

3.2 Metadata Partition Mounting

The metadata partition is the first partition mounted after boot. The mounting code calls a generic MountPartition function (see source for details).

3.3 System Partition Mounting

The system partition is a logical partition stored inside the super physical partition. The mounting process includes three steps:

Create a dm-linear device that maps the physical address of the system image to a device node.

Check whether dm‑verification (AVB) is required.

Mount the system partition like a regular partition.

3.4 Userdata Partition Mounting

Userdata relies on dm‑based metadata encryption (default‑key). The mounting flow differs between the first boot and subsequent boots:

First boot: encryptFstab creates a dm device with a default key, formats it as f2fs, and mounts it.

Subsequent boots: mountFstab attempts to mount the already‑encrypted userdata; if the superblock cannot be read, it falls back to the encrypted path.

4. Common Issues Summary

4.1 set_policy_failed – Occurs when setting the FBE encryption policy for a folder fails (e.g., mismatched policy versions, permission issues, or corrupted policy data). The failure forces the device into recovery mode.

4.2 init_user0_failed – Happens when the init process cannot create or access the master key storage (often because the userdata partition is not mounted or the keymaster service fails).

4.3 enablefilecrypto_failed – Triggered during the fbeEnable step after userdata is mounted; failures are usually due to key creation/read errors or keymaster problems.

4.4 userdata mount failure – Can be caused by missing metadata keys, decryption errors, dm device creation failures, or corrupted dm‑linear devices.

4.5 ServiceManager crash during shutdown – A crash of ServiceManager leaves the binder communication dead, causing vold shutdown timeout and a forced reboot.

For each issue, the article provides typical log snippets, analysis steps, and possible root causes.

Additional recommended reading:

Linux Kernel Concurrency and Synchronization (ARM64) – Part 1

Linux Kernel Concurrency and Synchronization (ARM64) – Part 2

Crash Practice: Using crash to Analyze Kernel Dumps