"stable" branch will not downgrade - fails on db:migrate

Philip_Colmer · January 1, 2018, 12:01pm

I’m trying to set up a new installation of Discourse using the stable branch. The installation completes successfully if I leave app.yml set to “tests-passed”. However, if I change that to stable and rebuild, it fails with:

I, [2018-01-01T11:55:35.349654 #13]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
URGENT: type Failed to initialize site default
rake aborted!
ArgumentError: type
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `eval'
/var/www/discourse/lib/site_setting_extension.rb:221:in `block (2 levels) in refresh!'
/var/www/discourse/lib/site_setting_extension.rb:220:in `map'
/var/www/discourse/lib/site_setting_extension.rb:220:in `block in refresh!'
/var/www/discourse/lib/site_setting_extension.rb:216:in `synchronize'
/var/www/discourse/lib/site_setting_extension.rb:216:in `refresh!'
(eval):6:in `block (2 levels) in run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `eval'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `block (2 levels) in run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:58:in `block in open'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:57:in `open'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:57:in `open'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:36:in `block in run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/transactions.rb:220:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:35:in `run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:26:in `block in run'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:25:in `each'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:25:in `run'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu.rb:29:in `seed'
/var/www/discourse/lib/tasks/db.rake:8:in `block in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rake-11.3.0/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2018-01-01T11:55:39.870156 #13]  INFO -- :
== Seed from /var/www/discourse/db/fixtures/001_categories.rb

I, [2018-01-01T11:55:39.870684 #13]  INFO -- : Terminating async processes
I, [2018-01-01T11:55:39.870854 #13]  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/9.5/bin/postmaster -D /etc/postgresql/9.5/main pid: 44
2018-01-01 11:55:39.871 UTC [44] LOG:  received fast shutdown request
2018-01-01 11:55:39.871 UTC [44] LOG:  aborting any active transactions
2018-01-01 11:55:39.871 UTC [51] LOG:  autovacuum launcher shutting down
I, [2018-01-01T11:55:39.871055 #13]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 159
159:signal-handler (1514807739) Received SIGTERM scheduling shutdown...
2018-01-01 11:55:39.874 UTC [48] LOG:  shutting down
2018-01-01 11:55:39.890 UTC [48] LOG:  database system is shut down
159:M 01 Jan 11:55:39.894 # User requested shutdown...
159:M 01 Jan 11:55:39.894 * Saving the final RDB snapshot before exiting.
159:M 01 Jan 11:55:39.903 * DB saved on disk
159:M 01 Jan 11:55:39.903 # Redis is now ready to exit, bye bye...


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

I have tried rebuilding multiple times and I’ve tried completely destroying the installation and starting again but it always fails this way. Changing the branch back to tests-passed allows the rebuild to complete.

Falco · January 1, 2018, 4:16pm

We don’t support downgrades, so to move to stable you need to start on a brand new install.

Philip_Colmer · January 2, 2018, 7:46am

I’ve tried it on a brand new install. I deleted the Discourse directory, pruned Docker of any existing images, cloned the git repository, edited app.yml to specify the desired branch and it will not build.

codinghorror · January 2, 2018, 7:46am

The database storage is outside the container, though, and it looks like you didn’t nuke that?

Philip_Colmer · January 2, 2018, 8:03am

OK … that is a possibility, although if it isn’t stored within /var/discourse (or whereever the git repository gets cloned), where is it stored since I haven’t specified another path?

fefrei · January 2, 2018, 10:50am

It should be in there. Try this:

cd /var/discourse
Stop the container in case it is still running: sudo ./launcher stop app
Delete the database: sudo rm -rf shared/standalone/
This step will delete all Discourse-related data!
Make sure app.yml is on the stable version
Run sudo ./launcher rebuild app to bootstrap and start the container, which will create a fresh database

The important thing is not to bootstrap any newer version before having selected stable, or deleting the shared folder in-between – anything else would be a downgrade of a (mostly empty) Discourse database, which is unsupported.

Philip_Colmer · January 2, 2018, 1:39pm

I’ve realised where I’ve been going wrong … the yml config file references “/var/discourse/shared” but we’re actually using /srv/discourse … so I forgot to update those paths.

Now that I’ve sorted that all out (and properly removed the previously build database), I can correctly set up Discourse on the stable branch.

Sorry for the noise

Topic		Replies	Views
Discourse Rebuild Failed to Bootstrap installation	6	401	August 31, 2023
Cannot install v1.8.1 (newer version works) installation	3	956	June 23, 2017
Fail to install Discourse via Docker installation	3	560	July 7, 2021
Rebuild fails on db:migrate "relation "form_templates" already exists" installation	10	289	October 25, 2023
Recently added post migration causes bootstrap to fail bug	14	879	November 19, 2018

"stable" branch will not downgrade - fails on db:migrate

Related Topics