adop "fs_clone" Failures in Oracle EBS R12.2 — Common Causes and Fixes

If you've worked with Oracle E-Business Suite R12.2's online patching (ADOP) for any length of time, you've probably hit a failure during the fs_clone phase at least once. It's one of the most common places adop breaks — and one of the most confusing, because the error messages don't always point you to the real root cause.

This post walks through why fs_clone exists, what it actually does, and the most frequent reasons it fails, along with practical fixes.

1. What Is fs_clone and When Do You Run It?

In R12.2's dual file system architecture, you have two complete copies of the application tier — fs1 and fs2 — so patching can happen on the idle file system while the other stays live. adop phase=fs_clone is the step that synchronizes the patch file system with the run file system after a patching cycle completes, or before a new node (like a DMZ node) is added.

You typically run it:

• After completing a full adop cycle (prepare → apply → finalize → cleanup)
• Before cloning the application tier to a new node
• When the two file systems have drifted out of sync and need to be realigned

Important

Always complete cleanup_mode=full before running fs_clone. Skipping cleanup is the single most common cause of fs_clone failures.

 2. Common Cause #1: Skipped or Incomplete Cleanup

If a previous adop cycle wasn't fully cleaned up — meaning adop phase=cleanup cleanup_mode=full was never run, or it failed midway — the patch file system still has leftover state from the last cycle. Running fs_clone on top of that inconsistent state is asking for trouble.

Fix: Run a full cleanup cycle before attempting fs_clone again:

$ adop phase=cleanup cleanup_mode=full

$ adop phase=fs_clone

Check the cleanup log under $APPL_TOP/admin/<SID>/log to confirm it completed without errors before moving forward.

3. Common Cause #2: Filesystem Space Issues

fs_clone copies large volumes of data between file systems. If the destination file system (fs2, typically) doesn't have enough free space, the clone will fail partway through — often with a generic I/O or copy error that doesn't immediately say "disk full."

Fix:

• Check available space on both fs1 and fs2 before starting: df -h
• EBS R12.2 application tiers generally need significant headroom (tens of GB free) for clone operations — check Oracle's sizing guidance for your specific version
• Clear out old log files, temp patch directories, and stale .adop workspaces if space is tight

Tip

Don't just check the mount point — check the actual partition $APPL_TOP and $COMMON_TOP reside on. A full root partition can silently fail operations that look unrelated.

4. Common Cause #3: Locked or Running Application Services

fs_clone expects application services to be in the correct state. If services are still running on the file system being cloned from, or a previous adop session wasn't closed properly, the clone process can hang or fail with lock-related errors.

Fix:

• Confirm no adop session is currently active: adop -status
• Stop application services cleanly before retrying if instructed by the error log
• If a stale adop session is stuck, check ad_adop_sessions in the database and consult MOS before manually clearing session state — don't do this blindly on production

5. Common Cause #4: Database Connectivity or TNS Issues

Since fs_clone interacts with the AD schema to track patching state, a database connectivity hiccup mid-process — a dropped TNS connection, a database bounce, or a network blip — can leave the clone in a broken, partially-completed state.

Fix:

• Verify TNS connectivity from the apps tier before starting: tnsping <db_alias>
• Check the database alert log for any unexpected restarts during the clone window
• If the clone fails due to a DB issue, don't just rerun blindly — check the adop log first to see exactly which step failed before retrying

6. Common Cause #5: Out-of-Sync Context Files

If the run and patch context files have drifted — say, a manual edit was made to one but not the other, or AutoConfig wasn't run consistently — fs_clone can fail validation checks partway through.

Fix:

$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

$ sh adautocfg.sh

Run this on both file systems before attempting fs_clone again, and avoid manual context file edits outside of AutoConfig wherever possible.

Summary

Most fs_clone failures trace back to one of five things: incomplete cleanup, insufficient disk space, locked sessions or running services, database connectivity blips, or out-of-sync context files. Read the adop.log first, fix the root cause, and only then retry. Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.