Elixir release fails with :enoent

Hello I’am trying to do a mix release with elixir version Elixir 1.10.2 (compiled with Erlang/OTP 22).
The Application compiles normally and I can also start it with iex -S mix phx.server. But whenever I try to do a mix release I get the following error.

** (Mix) Could not load asn1.app. Reason: :enoent

I already tried to nuke the complete folder and git clone it new.
I also tried the version provided from my package manager opensuse which is version 1.9.4-2.2 and my asdf version which is the version provided above. Both have the same error. I don’t know what is causing this error. Every help is appreciated.

Hi @Eiamnacken can you show your mix.exs file?

defmodule Movementfamilyev.MixProject do
  use Mix.Project

  def project do
    [
      app: :movementfamilyev,
      version: "1.9.0",
      elixir: "~> 1.5",
      elixirc_paths: elixirc_paths(Mix.env()),
      compilers: [:phoenix, :gettext] ++ Mix.compilers(),
      start_permanent: Mix.env() == :prod,
      aliases: aliases(),
      deps: deps()
    ]
  end

  # Configuration for the OTP application.
  #
  # Type `mix help compile.app` for more information.
  def application do
    [
      mod: {Movementfamilyev.Application, []},
      extra_applications: [:logger, :runtime_tools, :cachex]
    ]
  end

  # Specifies which paths to compile per environment.
  defp elixirc_paths(:test), do: ["lib", "test/support"]
  defp elixirc_paths(_), do: ["lib"]

  # Specifies your project dependencies.
  #
  # Type `mix help deps` for examples and options.
  defp deps do
    [
      {:phoenix, "~> 1.4.2"},
      {:phoenix_pubsub, "~> 1.1"},
      {:phoenix_ecto, "~> 4.0"},
      {:ecto_sql, "~> 3.0"},
      {:postgrex, ">= 0.0.0"},
      {:gettext, "~> 0.11"},
      {:jason, "~> 1.0"},
      {:plug_cowboy, "~> 2.0"},
      {:cors_plug, "~> 2.0"},
      {:argon2_elixir, "~> 2.0"},
      {:ex_crypto, "~> 0.10.0"},
      {:stream_data, "~> 0.4.3", only: [:test, :dev]},
      {:credo, "~> 1.0", only: [:test, :dev], runtime: false},
      {:pigeon, "~> 1.3.1"},
      {:kadabra, "~> 0.4.4"},
      {:cachex, "~> 3.1"},
      {:quantum, "~> 2.3"},
      {:timex, "~> 3.0"},
      {:bodyguard, "~> 2.4"},
      {:joken, "~> 2.2.0"}
    ]
  end



  # Aliases are shortcuts or tasks specific to the current project.
  # For example, to create, migrate and run the seeds file at once:
  #
  #     $ mix ecto.setup
  #
  # See the documentation for `Mix` for more info on aliases.
  defp aliases do
    [

      "ecto.setup": ["ecto.create", "ecto.migrate", "run priv/repo/seeds.exs"],
      "ecto.reset": ["ecto.drop", "ecto.setup"],
      test: ["ecto.migrate", "test"]
    ]
  end
end

Maybe you need to add :asn1 to your extra_applications list.

No same error. Also, this configuration worked for some time before.

I have done some more digging.
This is the trace output of Mix.Tasks.Release.run

iex(23)> Mix.Tasks.Release.run([])                                   
** (Mix.Error) Could not load asn1.app. Reason: :enoent
    (mix 1.10.2) lib/mix.ex:392: Mix.raise/1
    (elixir 1.10.2) lib/enum.ex:2111: Enum."-reduce/3-lists^foldl/2-0-"/3
    (mix 1.10.2) lib/mix/release.ex:321: Mix.Release.do_load_app/6
    (elixir 1.10.2) lib/enum.ex:2111: Enum."-reduce/3-lists^foldl/2-0-"/3
    (mix 1.10.2) lib/mix/release.ex:321: Mix.Release.do_load_app/6
    (elixir 1.10.2) lib/enum.ex:2111: Enum."-reduce/3-lists^foldl/2-0-"/3
    (mix 1.10.2) lib/mix/release.ex:321: Mix.Release.do_load_app/6
    (elixir 1.10.2) lib/enum.ex:2111: Enum."-reduce/3-lists^foldl/2-0-"/3
    (mix 1.10.2) lib/mix/release.ex:93: Mix.Release.from_config!/3
    (mix 1.10.2) lib/mix/tasks/release.ex:984: Mix.Tasks.Release.run/1

So it is getting this asn1.app from somewhere but i cant seem to find from where.

Building in docker works fine by using the default elixir:1.10 image. But building on my environment on opensuse TW does not work.

Perhaps the openSuse maintainers removed the asn1 application from their erlang distribution. A lot of dsitribution managers do this for reasons they don’t communicate. You need to find out in which other packages they package that application.

Though maybe, they have stripped it otherwise down, and the requested files are only available in the development/sourcecode packages.

Ok I completely removed elixir and erlang from my machine a took the version from asdf and now it works againg. But there was no evidence that elixir or erlang needed this. There is also no info if this package is provided anywhere I will ask the opensuse community for this.

1 Like

So the solution was to compile erlang from source. With the rpm package provided by opensuse the tests from elixir are failing. Now with the tar.gz release version 22.3 the elixir tests are all ok. So the error really comes from the provided erlang version from opensuse. I will make an issue there.

2 Likes

Hi,

It might be an old topic, but I faced exactly the same issue and tried to dig a bit before I surrender. I found that subsequent installations of erlang leave empty folders of upgraded applications in /usr/lib64/erlang/lib folder. So in my case there was seven empty folders that start with “asn1” and one full. I’m not sure how mix release works, but it somehow tries to merge retrieved path with /ebin/asn1.app (in this specific case of asn1 application). Here is a code fragment of release.ex file:

defp do_load_app(app, path, deps_apps, seen, otp_root, otp_app?, included) do
    case :file.consult(Path.join(path, "ebin/#{app}.app")) do
.....

I’m not sure how the path is resolved, but it seems like it picks one of the empty asn1 folders, then appends the rest and fails. In my case solution was just to remove all empty folders.

My solution seems to be aligned with the solution proposed here, but I guess it is less radical, so I thought I drop some lines for someone desperate just to make his/her live a bit easier.

Greetings,

Pawel

Thanks pickme467 that was it. The empty folders are causing the problem i will update the bug ticket i opened here https://bugzilla.opensuse.org/show_bug.cgi?id=1169240.

I opened a new bug. And now they know what the issue is, it will get fixed.
http://bugzilla.opensuse.org/show_bug.cgi?id=1187546

1 Like