conda env create fails with Solving environment: failed PackagesNotFound

Not specified by the original author.

TL;DR

For "Solving environment: failed with initial frozen solve. Retrying with flexible solve.": press CTRL-C to abort. hanging for a long time → the classic solver is struggling (class B), or a real conflict it will eventually report (class A). Your installed version is: 2.35 attached to a __glibc complaint → the system glibc is too old for the requested builds (class A, system-level).

Solving environment: failed with initial frozen solve. Retrying with flexible solve.
...
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.

When to use

You are seeing this: The three signatures: ` UnsatisfiableError: The following specifications were found to be incompatible with each other: → a genuine version conflict (class A). ` Solving environment: failed with initial frozen solve. Use this skill when you run into "Fix conda / Bioconda install conflicts and solver failures".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Use this when conda install or conda create with Bioconda packages fails with UnsatisfiableError, hangs on Solving environment, or reports Found conflicts!. These errors look alike but have four distinct causes with different fixes. Classify from the exact error text FIRST, the fix for a genuine version conflict is the opposite of the fix for a slow solver.

0. Read the error text, not just "it failed"

The three signatures:

UnsatisfiableError: The following specifications were found to be incompatible with each other:

→ a genuine version conflict (class A).

Solving environment: failed with initial frozen solve. Retrying with flexible solve.
...
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.

hanging for a long time → the classic solver is struggling (class B), or a real conflict it will eventually report (class A).

Your installed version is: 2.35

attached to a __glibc complaint → the system glibc is too old for the requested builds (class A, system-level).

1. Class A, genuine version conflict (UnsatisfiableError)

The solver is telling the truth: the requested combination cannot exist. Common triggers seen on Biostars:

• Installing into an existing environment (especially base). The existing packages pin half the dependency tree. Almost every "conda error" thread is fixed the same way, install into a fresh environment:

  conda create -n sratools -c conda-forge -c bioconda sra-tools
  conda activate sratools

• Over-pinned versions. samtools=1.9 on a new conda-forge stack fails because the old recipe's libgcc-ng/libstdcxx-ng/zlib pins collide with what modern python pulls in. Unless you have a hard reason for the old version, drop the pin and let the solver pick; then pin the resolved versions (conda list --export) for reproducibility.

• Python version drift. Bioconda currently builds for Python 3.10 3.13; old recipes expecting older Pythons conflict with the current stack. If you must have an old package, create the env with an old python explicitly (conda create -n old -c conda-forge -c bioconda python=3.9 [pkg]) instead of fighting the default.

• System glibc too old. Errors naming __glibc (e.g. recipe needs >=2.17 and the system reports something older) cannot be solved by channel juggling, you need a newer OS image or a container.

Do not "fix" class A by adding more channels or --force; that hides the conflict until runtime.

2. Class B, solver hangs or crawls (no UnsatisfiableError yet)

The classic conda solver is slow on Bioconda's large dependency graph. Check the solver first:

conda --version

• conda 23.10 or newer: the libmamba solver is already the default. If solving still hangs, it's probably a genuine conflict (class A), let it finish or Ctrl-C and read the report.

• conda older than 23.10: install the faster solver and make it default:

  conda update -n base conda
  conda install -n base conda-libmamba-solver
  conda config --set solver libmamba

or use it for one command only:

  conda install -c conda-forge -c bioconda [pkg] --solver=libmamba

• Alternative: mamba / micromamba are drop-in replacements that use the same libsolv-based solver and the same channels:

  mamba create -n tools -c conda-forge -c bioconda samtools bcftools

3. Class C, wrong channel order / priority

Bioconda's documented setup (bioconda.github.io), order matters because conda config --add prepends, so add in this exact sequence to end up with conda-forge at highest priority:

conda config --add channels bioconda
conda config --add channels conda-forge
conda config --set channel_priority strict

Resulting priority (highest first): conda-forge, bioconda. Rationale from the docs: Bioconda heavily depends on conda-forge, so conda-forge must win for general-purpose libraries; strict priority "avoids cryptic errors" by respecting that order during solving instead of mixing channels per package.

Diagnose: conda config --show channels, if bioconda outranks conda-forge, or channel_priority is flexible/disabled, fix it with the three commands above.

Without touching .condarc, pass the same policy per command (note: on the command line, -c flags are read in decreasing priority order, the reverse of conda config):

conda create -n myenv -c conda-forge -c bioconda --strict-channel-priority samtools bwa

4. Class D, environment YAML won't resolve

For conda env create -f env.yml conflicts:

1. Check the channels: list in the YAML, it must list conda-forge before bioconda (same priority rule as class C).

2. Loosen or drop version pins on the tools (samtools, rsubread); over-pinning transitive deps (libgcc-ng=...) is the usual culprit remove them first, re-add only what still resolves.

3. Solve with mamba (mamba env create -f env.yml); its error messages name the conflicting chain more precisely than conda's.

Quick decision tree

1. UnsatisfiableError → fresh env, drop pins, check python/glibc (class A).

2. Hangs at Solving environment / Found conflicts! → conda ≥23.10? yes: wait for the real report; no: libmamba solver (class B).

3. Worked before, fails now on a new machine → conda config --show channels; fix order to conda-forge > bioconda + strict priority (class C).

4. YAML create fails → channel order in YAML, unpin tools, solve with mamba (class D).
5. Never install bioinformatics tools into base; never "fix" a conflict with --force.

Variants

Other phrasings of the same problem that show up in reports:

UnsatisfiableError: The following specifications were found to be incompatible with each other:

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Built from Bioconda's official setup docs (channel order conda-forge above bioconda via sequential conda config --add, channel_priority strict) and the conda-libmamba-solver user guide (libmamba default from conda 23.10; --solver=libmamba for older conda), grounded in recurring Biostars threads on UnsatisfiableError, Solving-environment hangs, and YAML conflicts.

Not specified by the original author.

TL;DR

A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

kernel died after installing new conda package

Use this when

• The kernel worked, you installed one conda package, and now it dies on startup or first import.
• conda list --revisions shows a solver run right before the breakage.
• Imports of numpy, scipy, or pandas now segfault or die silently.

Not for this skill when

• The kernel dies only on large data. That is memory pressure, not a bad install.
• The kernel dies on a fresh environment too. That points at the machine, not the package.

Steps

1. List revisions: conda list --revisions. Verify: you can see the revision number from before the bad install.
2. Roll back: conda install --revision [N]. Verify: the kernel starts and the previously working imports succeed.
3. If rollback fails, export the env: conda env export --no-builds > env-backup.yml. Verify: the file lists your packages.
4. Recreate cleanly: conda env remove -n [env], then conda env create -f env-backup.yml. Verify: the new env's kernel starts.
5. Reinstall the new package pinned: conda install [package]=[version] from the main channel only, avoiding pip/conda mixes for numpy/scipy. Verify: imports still work after install.

Variant phrasings

conda install broke jupyter kernel

General phrasing. Rollback is the fastest recovery.

kernel died after pip install conda env

The pip-into-conda variant. Pip can overwrite conda-managed binaries; same rollback applies.

jupyter kernel dies after installing package

Symptom phrasing. Binary clash is the prime suspect.

Compatibility: conda/mamba on Linux and macOS, ipykernel 6.x. Revision rollback needs conda (mamba keeps the same history format).

Why it happens

Conda's solver optimizes for resolving the requested install, and it will happily swap your numpy build from MKL to OpenBLAS or mix pip-installed wheels with conda binaries to make the numbers work. The kernel then loads two incompatible BLAS libraries in one process and dies before any python traceback can print, which is why there is no error message, just a dead kernel.

Edge cases / pitfalls

• Never pip install numpy inside a conda env that already has conda numpy. That single command causes most of these deaths.
• Rollback only works if you have not run conda clean in a way that removed the cached packages. Check the revision list first.
• Rebuilding the env loses unexported pip installs. Export both conda env export and pip freeze before removing.
• If you must mix pip and conda, install conda packages first, then pip, and never pip-install anything conda already provides.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cZ5N5TtNF8z1uCZ8C1NNmA

Resolved from the public thread: https://vectle.com/posts/pst_cZ5N5TtNF8z1uCZ8C1NNmA

Thread query: kernel died after installing new conda package, how to fix

TL;DR: A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

Not specified by the original author.

TL;DR

For "DependencyException: Conda dependency seemingly installed but failed to build job environment.": set conda\auto\install: true in galaxy.yml (globally) or auto\install: true on the conda resolver. - Check the resolver chain in galaxy.yml: a misconfigured early resolver can shadow conda. Delete the broken env directory ([condaprefix]/envs/_[name]@[version] or the mulled-v1-[hash] dir) and rerun the tool, with autoinstall: true Galaxy rebuilds it.

DependencyException: Conda dependency seemingly installed but failed to build job environment.

When to use

You are seeing this: A tool's XML declares requirements like <requirement type="package" version="1.3.1">samtools</requirement>. Use this skill when you run into "Fix Galaxy tool dependency resolution failures (conda, Tool Shed, resolver order)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Use this when a Galaxy tool fails because its software dependencies cannot be found or installed, when Admin shows "Missing repository/tool dependencies" for an installed tool, when a job dies before the tool ever runs, or when the tool binary fails with missing libraries. Most of these look like "the tool is broken" but are one of four distinct resolution-chain problems with different fixes, classify FIRST from observable evidence, then touch configuration.

1. How Galaxy resolves a tool's requirements

A tool's XML declares requirements like <requirement type="package" version="1.3.1">samtools</requirement>. Galaxy passes them through dependency resolvers in order and uses the first success, later resolvers are never tried. The default chain, configured via dependency_resolvers in galaxy.yml, is:

1. tool_shed_packages, legacy packages from tool_dependencies.xml (deprecated; only relevant for old Tool Shed tools)

2. galaxy_packages, admin-curated dirs under tool_dependency_dir
3. conda, versioned match
4. galaxy_packages with versionless: true
5. conda with versionless: true

The conda resolver builds one environment per tool: a single requirement becomes [conda_prefix]/envs/__samtools@1.3.1; multiple requirements become mulled-v1-[hash] (hash derived from the requirement names and versions). Three defaults surprise everyone:

• conda_auto_install defaults to false, Galaxy will not install missing dependencies before a job runs unless you enable it.

• conda_auto_init defaults to true, Galaxy bootstraps its own conda from the web if none is found.

• conda_ensure_channels defaults to iuc,conda-forge,bioconda,defaults, the Bioconda prescribed channel order. Changing the order changes which build of a package you get.

(The old dependency_resolvers_conf.xml file still works but is deprecated; its docs only exist in Galaxy releases prior to 21.09.)

2. Classify from observable evidence

A. Admin shows "Missing repository/tool dependencies"

The tool came from the Tool Shed with legacy tool_dependencies.xml packages that were never installed. Per IUC best practice, all new/updated Tool Shed tools must resolve via conda, so this resolver is legacy-only.

• Fix: Admin → manage the tool's dependencies and install them, or reinstall a current IUC-maintained version of the tool that uses conda requirements.

• Do not hand-edit the tool XML to delete requirements (the mailing-list "arduous" path of vendoring system packages and editing XML is a last resort, not a first step).

B. Job fails immediately and no conda env exists for the tool

Look under [conda_prefix]/envs/ (default [tool_dependency_dir]/_conda/envs/): no __[name]@[version] and no mulled-v1-* for the tool means no resolver produced an environment.

• Check conda_auto_install, with the default false, Galaxy never creates the env and the job fails at setup. Set conda_auto_install: true in galaxy.yml (globally) or auto_install: true on the conda resolver.

• Check the resolver chain in galaxy.yml: a misconfigured early resolver can shadow conda. Turn on conda_debug: true and read the Galaxy log for the exact conda commands attempted.

• Check channels: conda_ensure_channels must keep the Bioconda order (iuc,conda-forge,bioconda,defaults) if it includes bioconda.

C. The env exists but the tool binary fails at runtime

Signatures: command not found for a tool that "installed fine", No module named X, symbol lookup error: .../libreadline.so.6: undefined symbol, or the classic:

DependencyException: Conda dependency seemingly installed but failed to build job environment.

The environment was created but is broken, this is an environment problem, not a resolver problem. Do not reorder resolvers; rebuild the env:

1. Delete the broken env directory ([conda_prefix]/envs/__[name]@[version] or the mulled-v1-[hash] dir) and rerun the tool, with auto_install: true Galaxy rebuilds it.

2. If the failure names a specific library (historically libbz2.so.1.0, libreadline.so.6), activate the env manually and reinstall that package from the top-priority channel (iuc, then conda-forge).

3. PaddingError: Placeholder of length '80' too short in package ... The package must be rebuilt with conda-build > 2.0 means the install prefix path was too long for the package's binary placeholders, keep conda_prefix short and retry.

D. The wrong version of a dependency is picked up

Because resolution is first-success-wins, an older tool_shed_packages or galaxy_packages entry that happens to match the name shadows the conda package you actually want. Inspect which resolver matched (the Admin dependency view shows how each requirement resolves), then reorder dependency_resolvers in galaxy.yml, e.g. conda before galaxy_packages, or remove the stale manual entry.

3. The configuration to check

In galaxy.yml, global keys that matter:

• conda_prefix (default [tool_dependency_dir]/_conda)
• conda_exec (defaults to conda on $PATH, else [conda_prefix]/bin/conda)
• conda_debug, log the conda commands; turn on while diagnosing
• conda_ensure_channels, keep iuc,conda-forge,bioconda,defaults order
• conda_auto_install, must be true for on-demand installs (default false)
• conda_auto_init, bootstrap conda from the web (default true)
• tool_dependency_dir, base for galaxy_packages lookups

Per-resolver keys (inside dependency_resolvers): type, versionless, prefix, exec, debug, ensure_channels, auto_install, auto_init, copy_dependencies, read_only. A common production pattern is two conda resolvers, a read-only curated install first, Galaxy-managed second:

galaxy:
  dependency_resolvers:
    - type: conda
      auto_init: false
      auto_install: false
      read_only: true
      prefix: /hpc/conda
    - type: conda
      auto_init: true
      auto_install: true
      prefix: /galaxy/conda

4. Checklist

1. Classify: A (Admin shows missing Tool Shed deps), B (no env created), C (env exists but broken), or D (wrong version resolved).

2. A → install via Admin or move to a conda-based tool version.

3. B → enable conda_auto_install, verify channels and resolver order, use conda_debug to see the failing command.

4. C → delete the env dir and let Galaxy rebuild; fix channel mix or prefix length if it recurs.

5. D → reorder dependency_resolvers so the intended resolver wins.

6. Tool developers: verify with planemo test before blaming the server a <requirement> naming a package that does not exist on conda fails at class B on every server.

Built from the Galaxy Project admin documentation on Dependency Resolvers (default resolver order and first-success-wins semantics, conda resolver parameters, mulled vs __name@version env naming, Bioconda channel order) and recurring failure signatures from the Galaxy mailing lists and help forum (DependencyException 'failed to build job environment', PaddingError placeholder-length errors, 'Missing repository/tool dependencies' in Admin).