jdx/mise · error · eyre::Report

elevated bootstrap helper failed with {status}

Error message

elevated bootstrap helper failed with {status}

What it means

Thrown by run_with_input in src/system/sudo.rs after an elevated helper process (spawned through sudo for system-package bootstrap) exits with a non-zero status. stdin carried a private payload while stdout/stderr were inherited from the terminal, so the helper's real diagnostics were already printed above this error. The message embeds the child's ExitStatus, which distinguishes a plain non-zero code from death by signal.

Source

Thrown at src/system/sudo.rs:213

        .chain(args.iter().cloned())
        .collect::<Vec<_>>()
        .join(" ");
    ensure_elevation_available(&manual_cmd)?;
    info!("$ {}", argv.join(" "));
    let mut child = Command::new(&argv[0])
        .args(&argv[1..])
        .stdin(Stdio::piped())
        .stdout(Stdio::inherit())
        .stderr(Stdio::inherit())
        .spawn()?;
    child
        .stdin
        .take()
        .expect("piped stdin is available")
        .write_all(input)?;
    let status = child.wait()?;
    if !status.success() {
        bail!("elevated bootstrap helper failed with {status}");
    }
    Ok(())
}

/// Run one elevated helper with a private stdin payload and capture stdout.
/// Stderr remains attached to the terminal for sudo prompts and diagnostics.
pub(crate) fn run_with_input_output(
    program: &str,
    args: &[String],
    input: &[u8],
) -> Result<Vec<u8>> {
    let argv = argv(program, args);
    let manual_cmd = std::iter::once("sudo".to_string())
        .chain(std::iter::once(program.to_string()))
        .chain(args.iter().cloned())
        .collect::<Vec<_>>()
        .join(" ");
    ensure_elevation_available(&manual_cmd)?;

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

1. Read the terminal output directly above the error - the helper's stderr was inherited, so the package manager's actual failure message is already visible
2. Re-run the printed command manually with the same arguments under sudo to reproduce the underlying failure (mirror outage, dpkg lock, disk full)
3. In scripts/CI, pre-authenticate with `sudo -v` or configure NOPASSWD so a password prompt cannot fail silently
4. If the status mentions a signal, check dmesg/journal for OOM kills and free memory or lower parallelism

// Pre-flight: confirm sudo is usable before triggering a bootstrap that elevates
use std::process::Command;
fn sudo_ready() -> bool {
    Command::new("sudo").args(["-n", "true"]).status().map(|s| s.success()).unwrap_or(false)
}

match mise::system::run_with_input(&prog, &args, &payload) {
    Ok(()) => {}
    Err(err) if err.to_string().starts_with("elevated bootstrap helper failed") => {
        // helper stderr was inherited and already printed; surface manual remediation
        eprintln!("bootstrap helper failed: {err:#}");
    }
    Err(err) => return Err(err),
}

When it happens

Trigger: Any mise operation that needs root (e.g. installing declared system packages) invokes run_with_input(program, args, input); the sudo-launched helper returns a failing status - wrong sudo password, package-manager error (unreachable mirror, held dpkg lock), unknown helper subcommand, or the process being killed by a signal.

Common situations: Mistyping the sudo password; apt/dnf/pacman failing mid-install; running inside a container or restricted environment where the privileged command is not permitted; OOM killer terminating the helper (status shows 'signal').

Related errors

• elevated bootstrap helper failed with {}
• not running as root and system_packages.sudo is disabled. Ru
• {} failed
• sudo not found. Run as root: {}
• Unknown config file type: {}

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/3e302d7fc86d6e08. Report an issue: GitHub.