Error upgrading 2.3.5 to 2.4.2

I’m trying to upgrade from 2.3.5 to 2.4.2 (on bitnami docker container, on google cloud).

Restoring 2.3.5 backup archive into new 2.4.2 flat out failed.

Uncompressed the archive and got the pg_dump file and loaded that into a a new database. It looked good for the most part except for two errors:

> ERROR:  schema "discourse_functions" does not exist
> ERROR:  schema "discourse_functions" does not exist

So something missing…

Tried this anyway…

> /opt/bitnami/apps/discourse/htdocs$ sudo bin/rake db:migrate RAILS_ENV=production
> rake aborted!
> PG::InsufficientPrivilege: ERROR:  permission denied for table site_settings
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :118:in `exec'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :118:in `run'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :82:in `query'
> /opt/bitnami/apps/discourse/htdocs/lib/site_settings/db_provider.rb:19:in `all'
> /opt/bitnami/apps/discourse/htdocs/lib/site_settings/defaults_provider.rb:29:in `db_all'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:277:in `block in refresh!'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:274:in `synchronize'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:274:in `refresh!'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:495:in `block in setup_methods'
> /opt/bitnami/apps/discourse/htdocs/config/initializers/004-message_bus.rb:120:in `<top (required)>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `block in load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:291:in `load_dependency'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:667:in `block i
> n load_config_initializer'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/notificatio
> ns.rb:182:in `instrument'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:666:in `load_co
> nfig_initializer'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:624:in `block (
> 2 levels) in <class:Engine>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:623:in `each'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:623:in `block i
> n <class:Engine>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:32:in `i
> nstance_exec'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:32:in `r
> un'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:61:in `b
> lock in run_initializers'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:50:in `e
> ach'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:50:in `t
> sort_each_child'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:60:in `r
> un_initializers'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:363:in `in
> itialize!'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `public
> _send'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `method
> _missing'
> /opt/bitnami/apps/discourse/htdocs/config/environment.rb:7:in `<top (required)>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.2.2/lib/zeitwerk/kernel.rb:23:in `requi
> re'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.2.2/lib/zeitwerk/kernel.rb:23:in `requi
> re'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:325:in `block in require'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:291:in `load_dependency'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:325:in `require'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:339:in `re
> quire_environment!'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:515:in `bl
> ock in run_tasks_blocks'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
> Tasks: TOP => db:migrate => db:load_config => environment
> (See full trace by running task with --trace)

Any direction appreciated.

I’m sorry but the bitnami package isn’t supportable here. It’s a third-party package, and if you want to continue using it you will need to speak to them to get any assistance.

Our recommendation would be to take a full backup and reinstall using the supported standard installation method.


Hi Stephen,

Should a 2.3.5 backup archive restore into standard 2.4.2 install work without issue?

It should, but don’t take my word for it and leave yourself without a fallback strategy. Remember you’re on an unsupported install, so I can give you suggestions on how to get onto a more supportable track, but Bitnami installs are problematic - it’s best to prepare for the worst.

If you build on a separate server you can test this before making any irreversible changes to your existing installation.

A bit of background:

We have 2.3.5 running in amazon.

We have tried building the standard install package on docker on an Ubuntu 18.0.4 LTS vm both on Google cloud and Virtual box here. Same issue.

We could not build v2.3.5 discourse docker (built-in postgres/redis), nor v2.3.10. They both fail with some Postgres permission issue both on google cloud, and on virtual box vm with Ubuntu 18.0.4.

The stable (2.4.2) builds, however neither docker 2.4.2 image on google cloud nor on virtual box will load. They both fail when building “discourse functions”.

We’ll try the build process according to link you sent us and report back. Should I file each environment attempt as a different topic?

I can then post where each environment hangs up specifically. If it does.

Are google cloud cloud instances with ubuntu 18.0.4 supported? And with their SQL?

Yes, but it’s a more complex environment than DigitalOcean. Installing in DO is a 30 minute process at most and you won’t have to worry about ACLs and network policy.

Look at /var/discourse/templates/web_only.yml (or similar, that’s by memory) for example of how to use an external database.

Once you get an empty site up you could be able to restore a backup with discourse restore.


We tried to build 2.3.5 discourse in ubuntu 18.0.4 vm. Added version: “v2.3.5” to app.yml and fails here:

> FAILED--------------------Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' failed with return #<Process::Status: pid 353 exit 1>Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}a3cebbd8e5a24b8a2b248886f0fa195f401720a6dc7084ad78af6cee345de9a9** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one../discourse-doctor may help diagnose the problem.

Should I try in DigitalOcean or with external database?

Looks like google all in one 18.0.4 LTS instance install of v2.3.5 discourse container died here:

> [2020-05-01T18:54:20.903566 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'/usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.17.3) required by your /var/www/discourse/Gemfile.lock. (Gem::GemNotFoundException)To update to the latest version installed on your system, run `bundle update --bundler`.To install the missing version, run `gem install bundler:1.17.3`        from /usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:294:in `activate_bin_path'        from /usr/local/bin/bundle:23:in `<main>'I, [2020-05-01T18:54:21.234673 #1]  INFO -- : I, [2020-05-01T18:54:21.235321 #1]  INFO -- : Terminating async processesI, [2020-05-01T18:54:21.235582 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 64I, [2020-05-01T18:54:21.235838 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1812020-05-01 18:54:21.236 UTC [64] LOG:  received fast shutdown request181:signal-handler (1588359261) Received SIGTERM scheduling shutdown...2020-05-01 18:54:21.241 UTC [64] LOG:  aborting any active transactions2020-05-01 18:54:21.248 UTC [64] LOG:  worker process: logical replication launcher (PID 73) exited with exit code 12020-05-01 18:54:21.248 UTC [68] LOG:  shutting down181:M 01 May 2020 18:54:21.268 # User requested shutdown...181:M 01 May 2020 18:54:21.269 * Saving the final RDB snapshot before exiting.181:M 01 May 2020 18:54:21.271 * DB saved on disk181:M 01 May 2020 18:54:21.271 # Redis is now ready to exit, bye bye...2020-05-01 18:54:21.288 UTC [64] LOG:  database system is shut down

Why not build stable and test restoring into that?

Ok we’ll try that and report back the error.

Should we use a command line command or through the UI restore action?

Either should work. Whatever is easier.

1 Like

Ok so we were able to build a 2.4.2 environment. However, the backup was done from an Amazon deployment with S3 configured. The restore to a non-amazon environment fails at some S3 scripts.

> Reconnecting to the database...
> Reloading site settings...
> Disabling outgoing emails for non-staff users...
> Disabling readonly mode...
> Clearing category cache...
> Clearing emoji cache...
> Clear theme cache
> Remapping uploads...
> Restoring uploads, this may take a while...
> Migrating uploads to S3 for 'default'...
> Uploading files to S3...
>  - Listing local files
>  => 3 files
>  - Listing S3 files
> . => 3 files
>  - Syncing files to S3
> ...
> Updating the URLs in the database...
> Removing old optimized images...
> Flagging all posts containing lightboxes for reb
> 182 posts were flagged for a rebake
> EXCEPTION: 215 of 295 uploads are not migrated to S3. S3 migration failed for db 'default'.
> /var/www/discourse/lib/file_store/to_s3_migration.rb:131:in `raise_or_log'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:78:in `migration_successful?'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:351:in `migrate_to_s3'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:65:in `migrate'
> /var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
> /var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
> /var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
> /var/www/discourse/lib/backup_restore/restorer.rb:59:in `run'
> script/discourse:143:in `restore'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
> /var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
> script/discourse:284:in `<top (required)>'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invok
> e_command'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
> /usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
> /usr/local/bin/bundle:23:in `load'
> /usr/local/bin/bundle:23:in `<main>'
> Trying to rollback...
> Rolling back...
> Cleaning stuff up...
> Dropping functions from the discourse_functions schema...
> Removing tmp '/var/www/discourse/tmp/restores/default/2020-05-01-230400' directory...
> Unpausing sidekiq...
> Marking restore as finished...
> Notifying 'system' of the end of the restore...
> Finished!
> Restore done.

Now what?

Do a database-only backup and restore and move the local assets by hand.

The sites that I’m having that issue with have assets in two different S3 buckets.

1 Like