How to resolve Module MountEpemeralDrive failed with code 32 during on-prem YNP provisioning

Problem

When you add a node or replace a node on an on-premises universe through YBA (for example via Universes → Nodes → Add Node or Replace Node), the task fails during the YNP provisioning subtask. The failure occurs even though data disks are already mounted and pre-flight checks pass.

This is most common when:

• The on-prem provider uses YNP auto-provisioning (the provider is not set to Manually provision nodes).
• Data volumes are presented through LVM (Logical Volume Manager) rather than raw block devices.

Error / alert observed:

The primary YNP failure line (note the module name spelling in the log MountEpemeralDrive, not MountEphemeralDrive):

Module MountEpemeralDrive failed with code 32

This appears in node-agent YNP logs on the target DB node during Add Node or Replace Node, typically under:

/opt/yugabyte/node-agent/logs/

Immediately above or below that line, the underlying shell error is often an lsblk failure when the host uses LVM for root or data disks:

lsblk: /dev/<device: not a block device

Exit code 32 is the lsblk return code when the parsed root device path is invalid or empty, common on LVM layouts where the mount script cannot resolve a raw block device name.

In YBA Tasks or on the YBA host in application.log, the same failure surfaces as a YNPProvisioning task error:

Failed to execute task ... YNPProvisioning ...
Installation failed
Command ... node-agent-provision.sh --extra_vars config.json --cloud_type onprem ... execution failed

On affected builds, pre-flight checks may pass and provisioning still fails on the next step:

Pre-flight checks successful
Module MountEpemeralDrive failed with code 32

Impact: Add Node and Replace Node operations stall. The replacement node never completes provisioning, leaving the universe under-replicated or blocking recovery workflows.

Cause

YNP (Yugabyte Node Provisioning) is the automation framework YBA uses to prepare DB nodes. The MountEphemeralDrive module is intended for cloud providers (AWS, GCP, Azure) where ephemeral instance-store volumes must be discovered and mounted before YugabyteDB starts.

On on-premises deployments, customers mount data disks themselves (often at paths like /data or /mnt/d0). YNP should not run MountEphemeralDrive on on-prem.

Diagnosis

Run these checks before applying a workaround to confirm this article applies.

1. Confirm YBA version (must be ≤ 2025.2.2.x, or 2025.2.4 with auto-provisioning):

   In YBA UI: Admin → Releases or check the platform version in Tasks → failed task details.

2. Confirm the provider is auto-provisioned (YNP path):

   Integrations → On-Premises Datacenters → [your provider] → Edit

   If Manually provision nodes is disabled, YBA runs YNP during Add/Replace Node, this is the failing path.

3. Confirm the failure is in YNP provisioning:

   On the target DB node, search node-agent YNP logs:

   grep -E 'MountEpemeralDrive|MountEphemeralDrive|failed with code|lsblk' \
     /opt/yugabyte/node-agent/logs/*.log 2/dev/null | tail -20

   Output when this issue is present:

   lsblk: /dev/<device: not a block device
   Module MountEpemeralDrive failed with code 32

   On the YBA host, search application.log around the failed task timestamp:

   grep -E 'MountEphemeral|MountEpemeral|node-agent-provision|YNPProvisioning|Return Code: 32' \
     /opt/yugabyte/data/yb-platform/logs/application.log | tail -30

   Output when this issue is present:

   Pre-flight checks successful
   ... YNPProvisioning ...
   Module MountEpemeralDrive failed with code 32
   Installation failed

4. Check for LVM (common secondary trigger):

   On the target DB node:

   lsblk
   df -h

   Output when LVM is involved: data mount (for example /data) sits on an LVM logical volume (/dev/mapper/... or /dev/<vg/<lv) rather than a raw /dev/sdX or /dev/nvme* device.

Resolution

WARNING: Take a universe snapshot before Replace Node or any operation that removes a live node. Add Node to an existing universe is lower risk but still warrants a recent backup if the cluster is production.

Choose one workaround below. Prefer Option A (upgrade) for a permanent fix.

Option A — Upgrade YBA to 2025.2.3.0 or later (recommended)

Upgrade the YBA platform to 2025.2.3.0+, which ships the corrected config.j2.

Reason: The fix is in the node-agent YNP template shipped with the platform release; no manual patching is needed after upgrade.

Value rationale: 2025.2.3.0 is the first stable line with the on-prem guard; later 2025.2.x builds retain the fix.

After upgrade, retry Add Node or Replace Node. No node-agent tar patching is required.

Option B — Enable "Manually provision nodes" on the provider

1. In YBA: Integrations → On-Premises Datacenters → [provider] → Edit.
2. Enable Manually provision nodes.
3. Save the provider.
4. Retry Add Node or Replace Node.

Reason: When manual provisioning is enabled, YBA skips the YNP auto-provisioning subtask that injects is_cloud=true and invokes MountEphemeralDrive.

Value rationale: This is the fastest UI-only workaround when an immediate YBA upgrade is not possible. It shifts node preparation to the manual node-agent-provision.sh workflow documented for on-prem.

Note: After enabling manual provisioning, ensure the node meets on-prem software requirements per Prepare server nodes (on-prem).

Option C — Patch the node-agent release on the YBA host

Use this when you cannot upgrade YBA immediately and Option B is not suitable (for example, the provider must stay on auto-provisioning).

WARNING: Back up the original node-agent tar before editing. Work on a copy; keep the original tar for rollback.

1. Identify the node-agent release tar on the YBA host (this is the path YBA uses at runtime not the installer package cache):

   ls /opt/yugabyte/data/yb-platform/node-agent/releases/

   Example:

   node_agent-2026.1.0.0-b118-linux-amd64.tar.gz

2. Extract, edit, and repackage:

   YBA_RELEASE="/opt/yugabyte/data/yb-platform/node-agent/releases/node_agent-<version-linux-amd64.tar.gz"
   WORK=/tmp/node-agent-patch
   rm -rf "$WORK" && mkdir -p "$WORK" && cd "$WORK"
   
   tar xzf "$YBA_RELEASE"
   CONFIG=$(find . -path '*/scripts/ynp/configs/config.j2' | head -1)
   cp "$CONFIG" "${CONFIG}.bak"

   Edit $CONFIG and either delete the unconditional module header:

   [MountEphemeralDrive]

   (Some builds spell it [MountEpemeralDrive] — remove whichever appears), or wrap it with the 2025.2.3 guard:

   {%- if ynp_config['extra'].cloud_type != "onprem" %}
   [MountEphemeralDrive]
   {%- endif %}

   Reason: Prevents YNP from running the cloud-only ephemeral-drive module when --cloud_type onprem is passed.

3. Repack and replace (preserve ownership):

   sudo cp "$YBA_RELEASE" "${YBA_RELEASE}.orig"
   tar czf /tmp/node_agent-patched.tar.gz -C "$WORK" .
   sudo mv /tmp/node_agent-patched.tar.gz "$YBA_RELEASE"

4. Retry Add Node or Replace Node in YBA.

Option D — Manual provisioning via node-agent-provision.sh

If Add Node through the UI continues to fail, provision the node manually using the on-prem script, then register it in YBA.

Reason: The manual script path sets is_cloud=false for on-prem and skips MountEphemeralDrive entirely, even on affected YBA versions.

Follow Prepare server nodes (on-prem) and ensure the YAML provider name, region/zone, instance type, and mount points match the existing provider.

Verification

After any workaround:

1. In YBA Tasks, confirm the Add Node / Replace Node task completes without a YNPProvisioning failure.

2. On the new node, confirm the node agent is healthy:

   curl -sk https://$(hostname -i):9070/health

   Expected output (healthy): HTTP 200 with a healthy status response.

3. In YBA Universes → [universe] → Nodes, confirm the node shows Live and the universe returns to a healthy replication state.