SOLVED On 15/12/16 10:29, Christian Bruckmayer wrote:

On 12/14/2016 03:39 PM, Magnus Lewis-Smith wrote:

...

I am trying to update an OBS server, currently running 2.3.8 on SLES11

I am able to update to 2.4 with database migration, but can't get LDAP to work. This is not a problem: on my test machine I was then able to upgrade to 2.5 successfully, with working LDAP.

However, on my live server, the database migration fails:

So you're currently trying to update from 2.3.8 to 2.5, right?

Ultimately, yes, but not directly. I have a live OBS server and a test one, both running 2.3.8 on SLES11 SP4. The live server started as 2.1 and has been upgraded to 2.3.8 long ago and hosts thousands of packages. The test server was installed directly to 2.3.8 and only hosts a couple of packages UPDGRADE 2.3 TO 2.4 I add the OBS:Server:2.4 SLE_11_SP3 repository to the server and update the packages. I follow the instructions in README.UPDATERS - check myql2 in {api,webui} database.yml - move configuration from {api,webui} config/environments/production.rb to appropriate options.yml then migrate api and webui databases # cd /srv/www/obs/api && RAILS_ENV="production" rake db:migrate # cd /srv/www/obs/webui && RAILS_ENV="production" rake db:migrate database migrations successful. I notice that the delayed_jobs table moves from the webui db to the api db Start the services. Can log in as local user but LDAP doesn't work. As I say, I don't care because I have proven on the test machine that a subsequent upgrade to 2.5 does work. Trigger a couple of rebuilds: all good UPDATE 2.4 TO 2.5 I add the OBS:Server:2.5 SLE_11_SP3 repository to the server and update packages. - check BSConfig.pm and api config files database.yml, options.yml (webui config has vanished) # cd /srv/www/obs/api && RAILS_ENV="production" rake db:migrate ... and this time it gets past the error I mentioned before. Weird. I wonder what I did differently this time. Let the 2.4 server run for a few hours, I suppose. The migration still aborts, though, seemingly every time the migration attempts to drop a foreign key, for example == GetRidOfDbPrefix: migrating =============================================== ... -- execute("alter table packages drop FOREIGN KEY packages_ibfk_1") -> 0.4639s -- execute("alter table packages drop index index_db_packages_on_db_project_id") -> 0.0056s -- rename_column(:packages, :db_project_id, :project_id) rake aborted! An error has occurred, all later migrations canceled: Mysql2::Error: Error on rename of './obs_api/#sql-3a68_39cf1b' to './obs_api/packages' (errno: 150): ALTER TABLE `packages` CHANGE `db_project_id` `project_id` int(11) NOT NULL/srv/www/obs/api/db/migrate/20131123113417_get_rid_of_db_prefix.rb:51:in `change' Tasks: TOP => db:migrate (See full trace by running task with --trace) There appear to be mismatches between foreign key names like 'packages_ibfk_1' in the DB and that expected by the migration scripts: dealt with these by hand-editing the sql removing spurious indexes Oh. database has migrated succesfully. Services start. LDAP login works. Test builds ... build.

...

# RAILS_ENV="production" rake db:migrate Mysql2::Error: Table 'obs_api.delayed_jobs' doesn't exist: SHOW FULL FIELDS FROM `delayed_jobs`/srv/www/obs/api/app/models/configuration.rb:95:in `delayed_write_to_backend'

Do you have a more detailed error message? Only with this line it is really hard to debug ...

yeah, I'm sorry. That was a truly terrible bug report -- Magnus Lewis-Smith -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org