vphone-cli/research/boot_launchd_data_volume_lookup_analysis.md

launchd Boot Sequence Analysis (mount-phase-1 / data volume lookup)

Date: 2026-03-06
Target binary in IDA: launchd (Darwin Bootstrapper 7.0.0, libxpc_executables-3089.42.1~6)

Scope

This analysis focuses on the log segment:

• mount-phase-1
• failed to lookup data volume - Attribute not found
• mount: data volume missing, but not required in env: 1

and answers where launchd is involved vs where mount/APFS is actually failing.

Ground Truth from launchd (IDA)

1) Boot task source is embedded plist in launchd

• Embedded config plist string contains:
  • Boot dictionary
  • mount-phase-1 -> Program=/sbin/mount, ProgramArguments=["mount","-P","1"]
  • data-protection -> Program=/usr/libexec/init_data_protection, CSIdentityOverride=com.apple.seputil

2) Boot task dictionary wiring

• sub_10004D978:

  • reads launchd __TEXT,__config
  • extracts Boot dictionary
  • stores into qword_10007F138

• sub_100047B94:

  • lookup task from qword_10007F138
  • runs gate check (sub_100047C8C)
  • executes task by calling sub_100047DD0

3) Boot sequence order (relevant slice)

• start -> sub_1000489A4 -> async sub_100048590
• sub_100048590 task order includes:
  • mount-phase-1
  • data-protection
  • finish-obliteration
  • detect-installed-roots
  • mount-phase-2

4) Task execution and failure handling

• sub_100047DD0:

  • logs Doing boot task
  • posix_spawnp() actual executable
  • for non-async tasks waits via sub_100049180

• sub_100049180:

  • checks exit status
  • if RequireSuccess=true and exit is failure -> calls sub_100048D0C

• sub_100048D0C:

  • logs Boot task failed: %s
  • logs Panicking in 3 seconds.
  • then panics

Key Conclusion: where the quoted error originates

failed to lookup data volume - Attribute not found is not generated by launchd internals.

In this path, launchd is only the orchestrator:

1. launchd runs /sbin/mount -P 1 for mount-phase-1
2. mount prints failed to lookup data volume...
3. launchd only sees child exit result, then decides whether to panic based on RequireSuccess

So this error’s primary fault domain is in mount + APFS/IOKit interactions, not in launchd task scheduler code.

mount -P 1 call chain (IDA-verified)

Target binary: research/artifacts/launchd_23B85/mount.from_vm_disk.current

• start @ 0x100003DC8
  • phase path calls sub_100003480(&env) then sub_100003674()
• sub_100003480 @ 0x100003480
  • reads IODeviceTree:/filesystems/fstab property os_env_type
  • calls APFSContainerGetBootDevice(&CFString)
  • builds /dev/<boot-container> string in global buffer
• sub_100003674 @ 0x100003674
  • calls APFSVolumeRoleFind(<bootdev>, 0x40, &CFArray)
  • on non-zero return:
    • fprintf("%sfailed to lookup data volume - %s\n", ..., strerror(ret & 0x3fff))
  • if single match, converts CFString -> data volume path

Important:

• 0x40 is the queried role selector in this build.
• Attribute not found corresponds to ENOATTR (93) after ret & 0x3fff.
• phase-1 can continue with warning, but this often cascades into data-protection failure in your failing trace set.

Updated Causality (with new control evidence)

User-provided control result:

• cfw_install (without JB extras) reproduces the same failure.
• TXM path is known-good in this setup.

Implication:

• JB-only userspace deltas are no longer primary suspects for this error.
• Current highest-confidence differentiator is kernel state/patch delta.

Plausible causes (re-ranked)

A. kernel-side causes (highest probability now)

1. APFS role/device lookup path is denied/altered by kernel policy path for mount (IOUC AppleAPFSUserClient ... MACF class of failure).
2. Kernel APFS patch interaction causes role metadata read path to return "attribute not found".
3. Kernel patch ordering or overlap in fw_patch_jb modifies behavior that minimal/non-JB flow does not.

B. mount userspace path causes (still relevant, but secondary to A)

1. mount -P 1 phase logic expects Data role metadata that is unavailable under current kernel behavior.
2. Userspace APFS query path receives transformed errno/status from kernel and prints attribute-missing message.

C. launchd-level causes (currently de-prioritized)

1. launchd task definition mismatch.
2. spawn-level failures before mount logic.
3. task gating differences.

These are less consistent with the new control result and with observed mount-origin log text.

Practical meaning

• For this failure, launchd reverse already gives enough certainty that launchd is orchestrator only.
• Next decisive work should move to APFS userspace API return-site tracing and corresponding kernel handlers.
• Detailed mount -P 1 failure/hang matrix is documented in:
  • research/boot_mount_phase1_failure_matrix.md

Most likely kernel-side silent-fail line (current ranking)

1. APFSVolumeRoleFind path reaches APFS userclient method and gets transformed deny/error (most consistent with IOUC AppleAPFSUserClient failed MACF ... mount history).
2. Base APFS entitlement bypass patch (patch_apfs_get_dev_by_role_entitlement, patch #16) matched the wrong deny branch or altered control flow for role lookup.
3. Base sandbox-op stubs (mount/vnode related) hit an unintended target due ops-table drift.

Lower probability for this exact string:

• launchd plist/task ordering itself
• fstab format/ramdisk missing (would produce different dominant signatures)

Artifact notes

Current extracted launchd sample (for reproducible local reference):

• research/artifacts/launchd_23B85/launchd.from_vm_disk.current
  • sha256: 411d730c95d99a088e94b673eff3fa73d6d3cc778b24b476cd0b7866cd037443
• research/artifacts/launchd_23B85/launchd.plist.from_vm_disk.current
  • sha256: dc972e30220b3e9e8323d23ce4a4737d849893dd79e305693de902ff65ddacab

Observed in this sample:

• no /cores/launchdhook.dylib load command
• launchd embedded boot task plist present and readable