# Rebar3 release/upgrade problems: ERROR: release\_handler:install\_release failed: {enoent **URL:** \ **Category:** Questions / Help\ **Tags:** rebar3, releases, appup\ **Created:** [November 27, 2024, 5:15am UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214 "2024-11-27T05:15:33Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![KayEss](https://erlangforums.com/letter_avatar_proxy/v4/letter/k/aca169/32.png) [@KayEss](https://erlangforums.com/u/KayEss)\ **Post date:** [November 27, 2024, 5:15am UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214/1 "2024-11-27T05:15:33Z")
I’m trying to work out how the upgrade process works in Erlang so that we can decide when/how we should be doing live updates on some of our deployments, but I run into problems using the generated release tarballs for upgrades. I’m working from a simple repo just to demonstrate and document how this works [https://github.com/BiggestLab/live\_update/tree/main/elixir](https://github.com/BiggestLab/live_update/tree/main/elixir). I can use `rebar3 as prod tar` to create the v1 tarball, and it runs fine using `./bin/luex foreground` (luex is Live Update EXample). I create the v2 just fine and copying it into the releases directory works as it unpacks, but I always get this error: ```erlang $ ./bin/luex upgrade 2.0.0 Release 2.0.0 not found, attempting to unpack releases/luex-2.0.0.tar.gz Unpacked successfully: "2.0.0" ERROR: release_handler:install_release failed: {enoent, "/tmp/luex/releases/1.0.0/relup"} ``` From what I understand of the process it doesn’t make sense to me that it’s looking for a relup file for 1.0.0 (and the console says it can’t find the optional relup file for 2.0.0). How can we get a relup file for the 1.0.0 release when we don’t know what will be in the next version? Presumably I’m doing something daft, but having read through a ton of documentation and tried a ton of things I can’t get anything except this error. Edit to add: Full details of the process I would expect to work are listed in the repo together with the code ---
**Author:** ![holger](https://erlangforums.com/user_avatar/erlangforums.com/holger/32/831_2.png) [@holger](https://erlangforums.com/u/holger)\ **Post date:** [November 27, 2024, 1:03pm UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214/2 "2024-11-27T13:03:47Z")
I have no time to look into your example right now, but FWIW, I’ve published an [example project](https://github.com/weiss/textgroup) with [upgrade docs](https://weiss.github.io/textgroup/operators.html#advanced-upgrading-textgroup) a while ago. Maybe you can figure out a missing piece from there? ---
**Author:** ![matt09](https://erlangforums.com/letter_avatar_proxy/v4/letter/m/b5ac83/32.png) [@matt09](https://erlangforums.com/u/matt09)\ **Post date:** [November 27, 2024, 7:13pm UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214/3 "2024-11-27T19:13:34Z")
You might want to check out [GitHub - thiagoesteves/jellyfish: This library facilitates the creation and management of appup files and releases for Elixir applications, enabling seamless hot upgrades.](https://github.com/thiagoesteves/jellyfish) for hot code upgrades. Since you mentioned deployments, you may also be interested in [GitHub - thiagoesteves/deployex: The ideal project to supervise your Elixir/Erlang/Gleam application](https://github.com/thiagoesteves/deployex) ---
**Author:** ![vances](https://erlangforums.com/user_avatar/erlangforums.com/vances/32/710_2.png) [@vances](https://erlangforums.com/u/vances)\ **Post date:** [November 28, 2024, 1:23am UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214/4 "2024-11-28T01:23:29Z")
I’ve raised the question about the generation of `relup` specifications as a _Day 1_ or _Day 2_ operation in this thread: > [@Release upgrade specifications: day 1 or day 2?](https://erlangforums.com/t/release-upgrade-specifications-day-1-or-day-2/4013): > > We ship software in [releases](https://www.erlang.org/doc/system/release_structure.html). When we ship a new release it may be installed as a fresh system or applied to one which is already in production. The [sasl](https://www.erlang.org/doc/apps/sasl/sasl_app.html) application provides tools for runtime [release handling](https://www.erlang.org/doc/system/release_handling.html). We can use release\_handler:install\_release/1 to upgrade a running system, which leverages the power of hot code [loading](https://www.erlang.org/doc/system/code_loading.html#code-replacement). The release [package](https://www.erlang.org/doc/system/release_structure.html#creating-a-release-package) has to have first been unpacked with release\_handler:unpack\_release/1. A release package may be prepared for shipping using systools:make\_tar/1,2. … As part of the solution to the _Day 1_ approach I submitted pull request [#8973](https://github.com/erlang/otp/pull/8973) which includes all available `appup` specifications in a release package. ---
**Author:** ![KayEss](https://erlangforums.com/letter_avatar_proxy/v4/letter/k/aca169/32.png) [@KayEss](https://erlangforums.com/u/KayEss)\ **Post date:** [November 28, 2024, 4:18am UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214/5 "2024-11-28T04:18:45Z")
Thanks. With that rebar3 plugin you use and the extra commands I’ve gotten a working live upgrade. I’ve documented it all here: [live\_update/erlang at main · BiggestLab/live\_update · GitHub](https://github.com/BiggestLab/live_update/tree/main/erlang) which hopefully should be a nice easy to follow minimal example. Next would be a v3 that upgrades the gen server in such a way that it requires a state migration. I’ve seen some hints at a gen server call back that’s meant to do this, but it might be a few weeks before I get a chance to look at it and manage to get something that works. ---
**Author:** ![KayEss](https://erlangforums.com/letter_avatar_proxy/v4/letter/k/aca169/32.png) [@KayEss](https://erlangforums.com/u/KayEss)\ **Post date:** [November 28, 2024, 4:20am UTC](https://erlangforums.com/t/rebar3-release-upgrade-problems-error-release-handler-install-release-failed-enoent/4214/6 "2024-11-28T04:20:05Z")
Thanks I am interested in Elixir, but we’re primarily using that for Phoenix/LiveView stuff right now, and we can tell from the dev environments that live updates there are likely to break live view pages that are currently in use so we may stick to something more traditional. @vances I think it’s a bit sad that the rebar3 release stuff doesn’t actually work, and that the documentation for how to use it tells you to read the source of a rebar3 plugin that also doesn’t seem to work.