Project

General

Profile

Bug #10135

Bad/Missing Migration after doing GUI upgrade

Added by Suraj Ravichandran over 5 years ago. Updated about 3 years ago.

Status:
Closed: Cannot reproduce
Priority:
Important
Assignee:
William Grzybowski
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

After a GUI upgrade from 9.3-STABLE-201412240734 to FreeNAS-9.3-STABLE-201506042008,
the new boot environment comes up and starts spewing database errors and tracebacks all over the place.

I am attaching the old config database (.bak) and the current one (which is failing) as in this ticket.

As for the update.failed file, here it is

ps: cannot mmap corefile
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
ps: empty file: Invalid argument
FATAL ERROR - The following SQL query failed: CREATE TABLE "_south_new_services_cifs" ("cifs_srv_guestok" bool NOT NULL, "cifs_srv_dirmask" varchar(120) NOT NULL, "cifs_srv_description" varchar(120) NOT NULL, "cifs_srv_loglevel" varchar(120) NOT NULL, "cifs_srv_guest" varchar(120) NOT NULL, "cifs_srv_filemask" varchar(120) NOT NULL, "cifs_srv_guestonly" bool NOT NULL, "cifs_srv_easupport" bool NOT NULL, "id" integer PRIMARY KEY, "cifs_srv_aio_ws" integer NOT NULL, "cifs_srv_homedir" integer, "cifs_srv_dosattr" bool NOT NULL, "cifs_srv_timeserver" bool NOT NULL, "cifs_srv_homedir_browseable_enable" bool NOT NULL, "cifs_srv_homedir_enable" bool NOT NULL, "cifs_srv_aio_enable" bool NOT NULL, "cifs_srv_largerw" bool NOT NULL, "cifs_srv_aio_rs" integer NOT NULL, "cifs_srv_localmaster" bool NOT NULL, "cifs_srv_netbiosname" varchar(120) NOT NULL, "cifs_srv_workgroup" varchar(120) NOT NULL, "cifs_srv_doscharset" varchar(120) NOT NULL, "cifs_srv_smb_options" text NOT NULL, "cifs_srv_nullpw" bool NOT NULL, "cifs_srv_authmodel" varchar(10) NOT NULL, "cifs_srv_sendfile" bool NOT NULL, "cifs_srv_unixcharset" varchar(120) NOT NULL)
The error was: table "_south_new_services_cifs" already exists
Running migrations for api:
- Nothing to migrate.
 - Loading initial data for api.
Installed 0 object(s) from 0 fixture(s)
Running migrations for freeadmin:
- Nothing to migrate.
 - Loading initial data for freeadmin.
Installed 0 object(s) from 0 fixture(s)
Running migrations for jails:
- Nothing to migrate.
 - Loading initial data for jails.
Installed 0 object(s) from 0 fixture(s)
Running migrations for support:
- Nothing to migrate.
 - Loading initial data for support.
Installed 0 object(s) from 0 fixture(s)
Running migrations for plugins:
- Nothing to migrate.
 - Loading initial data for plugins.
Installed 0 object(s) from 0 fixture(s)
Running migrations for tasks:
- Nothing to migrate.
 - Loading initial data for tasks.
Installed 0 object(s) from 0 fixture(s)
Running migrations for sharing:
 - Migrating forwards to 0034_fix_wizard_cifs_vfsobjects.
 > services:0030_auto__chg_field_ftp_ftp_anonpath__chg_field_rsyncmod_rsyncmod_path__ch
 - Migration 'services:0030_auto__chg_field_ftp_ftp_anonpath__chg_field_rsyncmod_rsyncmod_path__ch' is marked for no-dry-run.
 ! Error found during real run of migration! Aborting.

 ! Since you have a database that does not support running
 ! schema-altering statements in transactions, we have had 
 ! to leave it in an interim state between migrations.

! You *might* be able to recover with:   (migration cannot be dry-run; cannot discover commands)
 ! The South developers regret this has happened, and would
 ! like to gently persuade you to consider a slightly
 ! easier-to-deal-with DBMS (one that supports DDL transactions)
 ! NOTE: The error which caused the migration to fail is further up.
Error in migration: services:0030_auto__chg_field_ftp_ftp_anonpath__chg_field_rsyncmod_rsyncmod_path__ch
Traceback (most recent call last):
  File "/usr/local/www/freenasUI/manage.py", line 42, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/base.py", line 242, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/site-packages/south/management/commands/migrate.py", line 111, in handle
    ignore_ghosts = ignore_ghosts,
  File "/usr/local/lib/python2.7/site-packages/south/migration/__init__.py", line 220, in migrate_app
    success = migrator.migrate_many(target, workplan, database)
  File "/usr/local/lib/python2.7/site-packages/south/migration/migrators.py", line 256, in migrate_many
    result = migrator.__class__.migrate_many(migrator, target, migrations, database)
  File "/usr/local/lib/python2.7/site-packages/south/migration/migrators.py", line 331, in migrate_many
    result = self.migrate(migration, database)
  File "/usr/local/lib/python2.7/site-packages/south/migration/migrators.py", line 133, in migrate
    result = self.run(migration, database)
  File "/usr/local/lib/python2.7/site-packages/south/migration/migrators.py", line 114, in run
    return self.run_migration(migration, database)
  File "/usr/local/lib/python2.7/site-packages/south/migration/migrators.py", line 84, in run_migration
    migration_function()
  File "/usr/local/lib/python2.7/site-packages/south/migration/migrators.py", line 60, in <lambda>
    return (lambda: direction(orm))
  File "/usr/local/www/freenasUI/../freenasUI/services/migrations/0030_auto__chg_field_ftp_ftp_anonpath__chg_field_rsyncmod_rsyncmod_path__ch.py", line 27, in forwards
    db.rename_column('services_cifs', 'cifs_srv_homedir_id', 'cifs_srv_homedir')
  File "/usr/local/lib/python2.7/site-packages/south/db/sqlite3.py", line 245, in rename_column
    self._remake_table(table_name, renames={old: new})
  File "/usr/local/lib/python2.7/site-packages/south/db/generic.py", line 47, in _cache_clear
    return func(self, table, *args, **opts)
  File "/usr/local/lib/python2.7/site-packages/south/db/sqlite3.py", line 110, in _remake_table
    ", ".join(["%s %s" % (self.quote_name(cname), ctype) for cname, ctype in definitions.items()]),
  File "/usr/local/lib/python2.7/site-packages/south/db/generic.py", line 282, in execute
    cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/site-packages/django/db/utils.py", line 99, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute
    return self.cursor.execute(sql, params)
  File "/usr/local/www/freenasUI/../freenasUI/freeadmin/sqlite3_ha/base.py", line 421, in execute
    return Database.Cursor.execute(self, query, params)
django.db.utils.OperationalError: table "_south_new_services_cifs" already exists

History

#1 Updated by Suraj Ravichandran over 5 years ago

  • File freenas-v1.db2014 added

Here is the second attempt at procuring the old database file since the first method may or may not be 100% foolproof of getting the correct file.

Its named freenas-v1.db2014

#2 Updated by William Grzybowski over 5 years ago

  • Status changed from Unscreened to Screened

Just for the record, resume of the IRC conversation:

- The new database attached has timestamp of a just create database. Something is deleting/nuking the databse on upgrade, that doesn't seem to be a problem with the migrations at all.

#3 Updated by Sean Fagan over 5 years ago

With this update; I don't think anyone else has reported anything like it.

What happens if you go to the last known good BE and try again?

#4 Updated by William Grzybowski over 5 years ago

  • Status changed from Screened to Closed: Cannot reproduce

Closing per request and redoing update worked.

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from Unspecified to N/A

#6 Updated by Dru Lavigne over 2 years ago

  • File deleted (freenas-v1.db)

#7 Updated by Dru Lavigne over 2 years ago

  • File deleted (freenas-v1.db.bak)

#8 Updated by Dru Lavigne over 2 years ago

  • File deleted (freenas-v1.db2014)

Also available in: Atom PDF