Install of 3.3.3 fails when trying to load default data
Added by Anonymous about 7 years ago
Hi,
I tried to install redmine 3.3.3 with mysql. Created the database and granted the permission, then did all steps from the "Installing Redmine" document. The "RAILS_ENV=production bundle exec rake db:migrate" command runs without errors, the last output is "12 AddCommentsPermissions: migrated" (log file attached).
Afterwards, the following tables exist:
+------------------------+ | Tables_in_redmine | +------------------------+ | attachments | | auth_sources | | comments | | custom_fields | | custom_fields_projects | | custom_fields_trackers | | custom_values | | documents | | enumerations | | issue_categories | | issue_statuses | | issues | | journal_details | | journals | | members | | news | | permissions | | permissions_roles | | projects | | roles | | schema_migrations | | tokens | | trackers | | user_preferences | | users | | versions | | workflows | +------------------------+
Now, when trying to load the default data with "RAILS_ENV=production bundle exec rake redmine:load_default_data" this fails with
Error: Mysql2::Error: Unknown column 'roles.builtin' in 'where clause': SELECT 1 AS one FROM `roles` WHERE `roles`.`builtin` = 0 LIMIT 1 Default configuration data was not loaded.
Can anyone give me a hint what I'm doing wrong?
cu,
Frank
migrate.log (5.05 KB) migrate.log | |||
migrate.log (5.05 KB) migrate.log |
Replies (3)
RE: Install of 3.3.3 fails when trying to load default data
-
Added by Anonymous about 7 years ago
So the problem is that the migration process stops after 12 files. 012_add_comments_permissions.rb is the last one that is executed.
If I do "mv 017_create_settings.rb 012_create_settings.rb", remove 012_add_comments_permissions.rb and execute "delete from schema_migrations where version=12;" in mysql and call the migration again, now the new 012 file is added:
hilbert:/usr/share/redmine/db/migrate # RAILS_ENV=production bundle exec rake db:migrate (in /usr/share/redmine) == 12 CreateSettings: migrating =============================================== -- create_table(:settings, {:force=>true}) -> 0.0078s == 12 CreateSettings: migrated (0.0079s) ======================================
But everything with numbers higher than 12 is not executed, although there isn't any error message. Is there a file or config flag that tells redmine which migration files to execute and which not? Querying the status shows this:
database: redmine Status Migration ID Migration Name -------------------------------------------------- up 001 Setup up 002 Issue move up 003 Issue add note up 004 Export pdf up 005 Issue start date up 006 Calendar and activity up 007 Create journals up 008 Create user preferences up 009 Add hide mail pref up 010 Create comments up 011 Add news comments count up 012 Create settings down 013 Create queries down 014 Add queries permissions down 015 Create repositories down 016 Add repositories permissions ... and so on
We are using mariadb-10.0.30 btw. (SuSE Linux Enterprise 12 SP2).
cu,
Frank
RE: Install of 3.3.3 fails when trying to load default data
-
Added by Anonymous about 7 years ago
I could solve this myself. In the shell envinronment the variable $VERSION was defined with value 12 (due to SLES 12). This makes the redmine install script stop after the first 12 migration tasks. I figured this out when I saw that one could give "VERSION=.." as parameter to the rake call.
So unsetting the variable solved the problem.
Maybe it's not the best idea to read a variable name as common as "VERSION" from the environment. Sth. like "REDMINE_VERSION" would avoid such problems.
cu,
Frank
RE: Install of 3.3.3 fails when trying to load default data
-
Added by Mischa The Evil about 7 years ago
Frank Steiner wrote:
[...]
So unsetting the variable solved the problem.
Thanks for reporting back the cause of and your solution to the problem you encountered.
Maybe it's not the best idea to read a variable name as common as "VERSION" from the environment. Sth. like "REDMINE_VERSION" would avoid such problems.
I see your point. Though, this seems not related to the Redmine core source. This is a default Rails/Rake behaviour/naming which can't/shouldn't be modified by downstream Redmine IMO. You might want to investigate some more and see if it's reported already somewhere upstream and, if not, report it yourself.