Content
You are here:
Added by Guillermo Avalos over 4 years ago
Hi everyone. I´ve just installed OpenProject on a fresh CentOS 7 VM and it reported that there was an update available (strange because I installed it fresh this morning). I followed the instructions and did:
sudo yum update
sudo yum install openproject
sudo openproject configure
As it turns out, the second line was not necessary since the update already replaces OpenProject with the latest version.
However, after running openproject configure I ran into the following issue:
[openproject] ./bin/postinstall
rake aborted!
NameError: uninitialized constant Project::Scopes::Scoped
/opt/openproject/app/models/project.rb:38:in `<class:Project>'
/opt/openproject/app/models/project.rb:31:in `<top (required)>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.3.0/lib/zeitwerk/kernel.rb:23:in `require'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.3.0/lib/zeitwerk/kernel.rb:23:in `require'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/dependencies/interlock.rb:14:in `block in loading'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/concurrency/share_lock.rb:151:in `exclusive'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/dependencies/interlock.rb:13:in `loading'
/opt/openproject/config/initializers/activity.rb:43:in `<top (required)>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/engine.rb:667:in `block in load_config_initializer'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/notifications.rb:182:in `instrument'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/engine.rb:666:in `load_config_initializer'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/engine.rb:624:in `block (2 levels) in <class:Engine>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/engine.rb:623:in `each'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/engine.rb:623:in `block in <class:Engine>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/initializable.rb:32:in `instance_exec'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/initializable.rb:32:in `run'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/initializable.rb:61:in `block in run_initializers'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/initializable.rb:50:in `each'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/initializable.rb:50:in `tsort_each_child'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/initializable.rb:60:in `run_initializers'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/application.rb:363:in `initialize!'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/railtie.rb:190:in `public_send'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/railtie.rb:190:in `method_missing'
/opt/openproject/config/environment.rb:34:in `<top (required)>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.3.0/lib/zeitwerk/kernel.rb:23:in `require'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.3.0/lib/zeitwerk/kernel.rb:23:in `require'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/application.rb:339:in `require_environment!'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.2/lib/rails/application.rb:515:in `block in run_tasks_blocks'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/cli/exec.rb:74:in `load'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/cli/exec.rb:74:in `kernel_load'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/cli/exec.rb:28:in `run'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/cli.rb:465:in `exec'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/cli.rb:27:in `dispatch'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/cli.rb:18:in `start'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/exe/bundle:30:in `block in <top (required)>'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/opt/openproject/vendor/bundle/ruby/2.6.0/gems/bundler-2.0.2/exe/bundle:22:in `<top (required)>'
/opt/openproject/bin/bundle:104:in `load'
/opt/openproject/bin/bundle:104:in `<main>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
Afterwards the admin panel constantly shows that there´s a database migration pending, but I cannot figure out how to proceed.
Replies (14)
Hi Guillermo,
sorry to hear you're experiencing issues. Indeed we released OpenProject 10.5 today. This explains why you're receiving a new package version.
what's the output of
yum list installed openproject? I just tried the upgrade locally and this does not happen on my machine (granted, it's not Centos7 but Debian 9). The current version is10.5.0-1587652757.a0c90fc3Best
Oliver
Unfortunately I gave up and restored a snapshot prior to the OP install and simply run the installer again to get the latest version. I’m sure I’ll run into the same issue next time, so I’ll take a look at that output.
Thank you!
Hello, I have the same problem:
how I can rollback to previous version (CentOS, rpm based installation)?
Anatol Gafenco wrote:
I was paranoid enough so I created a snapshots= of the VM prior to the base install of OpenProject, so I simply rolled back and installed the newest version. If you don't have a VM snapshot I wouldn't know how to rollback. Completely new to OP.
Oliver Günther wrote:
I'm starting a pilot program on our company to deploy OpenProject, but if everyone agrees to use it I don't want to put it into production if it will break with every update. This was the first time trying to update it and it completely botched the installation. There's another person that reported the exact same issue, so it's reproducible.
Have you received any news from other CentOS/RHEL users?
For me it was solved by openproject removal with yum, removal of /opt/openproject, re-installation and openproject configure.
Anatol Gafenco wrote:
Was there any data loss? Did you have to restore from backups afterwards?
Guillermo Avalos wrote:
No any data loss, I deleted only software without configuration and data (also I had backup before I've started upgrade)
Hey guys,
please follow Ticket #33139 for more information. We're currently building a new package that might fix this issue. However, we were not able to reproduce this on one of our installations yet, so the fix is only an assumption.
Best
Oliver
Oliver Günther wrote:
Thank you! I hope you're able to get to the bottom of this. I'd help but I'm at a loss when it comes to Ruby. No idea where to begin.
Anatol Gafenco wrote:
deleting /opt/openproject and new install solved the problem for me too.
thank you so much Anatol Gafenco
Thanks for your feedback. Indeed removing /opt/openproject following by installing/upgrading the package should be fine, as we store no configurations there that wouldn't be overridden on upgrade.
There's not much in /opt/openproject that would change. If someone is still affected, could you try removing
/opt/openproject/tmponly and see if this works? This would narrow it down to a caching issue.Best
Oliver
Greeting Team,
We have a production openproject 8.1 Debian 9 and we are about to upgrade to 10.5.1. Debian 10
We have an automated role to install and configure this using Ansible.
Ansible will generate the
installer.datin the new server and install all requirements needed.When this command is ran by Ansible or manual on the server
sudo openproject configureit passes a lot of things but in the end it fails with the same trace back mentioned above in this topic.This is a fresh server.
I have to run the same command 2 times to bypass the error i got in the first run. Which is not idle if i want to automate this process.