Upgrade fresh 9.3 after restore config from a previous update 9.3 fail

[Ruda Porto Filgueiras]

Hello,

A did a first install of one FreeNAS server using 9.3, did all config stuff and everything was ok.

After that I did fresh install to do a usb drive mirror, ZFS mirror of the system pool.

Befor the new install I saved the config file and after the reinstall I restore the config, uploading the backup.

But, I dont upgrade the system do the same 9.3 version the config was saved.

Next I did the upgrade and something failed, but I guess it is not a problema because the migration try to create a table that alredy exists.

Follow the failure:

[root@nasalog02] /data# cat update.failed
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 "directoryservice_kerberossettings" ("id" integer NOT NULL PRIMARY KEY, "ks_appdefaults_aux" text NOT NULL, "ks_libdefaults_aux" text NOT NULL)
The error was: table "directoryservice_kerberossettings" 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 directoryservice:
- Migrating forwards to 0042_auto__add_kerberossettings.
> directoryservice:0041_auto__add_field_ldap_ldap_schema
> directoryservice:0042_auto__add_kerberossettings
! 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: = DROP TABLE "directoryservice_kerberossettings"; []

! 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: directoryservice:0042_auto__add_kerberossettings
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/directoryservice/migrations/0042_auto__add_kerberossettings.py", line 15, in forwards
('ks_libdefaults_aux', self.gf('django.db.models.fields.TextField')(blank=True)),
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/generic.py", line 361, in create_table
"columns": ', '.join([col for col in columns if col]),
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 "directoryservice_kerberossettings" already exists

Can I ignore this failure?

And if yes, how to fix the RED alert about an failed upgrade, just delete this file?

 

[DrKK]

You cannot use a config file from a *NEWER* version on an older version of FreeNAS. If your config file is a config for version X, then you can not use it on any FreeNAS of version <X.

Is that your problem?

The other way is fine---FreeNAS can "upgrade" older config files, but it does not "downgrade" newer ones, to my knowledge.

 

[guglez]

I have very similar issue. My old usb flash died. I have 3 different backups. But I can't restore them on a fresh installation of a freenas.
Here is the contents from error file:

[root@freenas] /data# less update.failed
FATAL ERROR - The following SQL query failed: CREATE TABLE "directoryservice_kerberosprincipal" ("id" integer NOT NULL PRIMARY KEY, "principal_keytab_id" integer NULL, "principal_version" integer NOT NULL, "principal_encryption" varchar(120) NOT NULL, "principal_name" varchar(120) NOT NULL, "principal_timestamp" datetime NOT NULL)
The error was: table "directoryservice_kerberosprincipal" 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 support:
- Nothing to migrate.
- Loading initial data for support.
Installed 0 object(s) from 0 fixture(s)
Running migrations for system:
- Migrating forwards to 0096_auto__add_field_systemdataset_sys_uuid_b.
> system:0096_auto__add_field_systemdataset_sys_uuid_b
- Loading initial data for system.
Installed 0 object(s) from 0 fixture(s)
Running migrations for directoryservice:
- Migrating forwards to 0052_change_ad_timeout_defaults.
> directoryservice:0044_auto__add_field_idmap_rfc2307_idmap_rfc2307_ssl__add_field_idmap_rfc23
> directoryservice:0045_auto__add_field_activedirectory_ad_netbiosname_b
> directoryservice:0045_auto__add_field_idmap_rfc2307_idmap_rfc2307_ldap_user_dn_password
> directoryservice:0046_auto__add_kerberosprincipal
! 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: = DROP TABLE "directoryservice_kerberosprincipal"; []

! 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: directoryservice:0046_auto__add_kerberosprincipal
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()

 

[guglez]

I tried to delete table directoryservice_kerberosprincipal from backup and got this:

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 support:
- Nothing to migrate.
- Loading initial data for support.
Installed 0 object(s) from 0 fixture(s)
Running migrations for system:
- Migrating forwards to 0096_auto__add_field_systemdataset_sys_uuid_b.
> system:0096_auto__add_field_systemdataset_sys_uuid_b
- Loading initial data for system.
Installed 0 object(s) from 0 fixture(s)
Running migrations for directoryservice:
- Migrating forwards to 0052_change_ad_timeout_defaults.
> directoryservice:0046_auto__add_kerberosprincipal
> directoryservice:0047_migrate_kerberos_keytabs_to_principals
- Migration 'directoryservice:0047_migrate_kerberos_keytabs_to_principals' 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: directoryservice:0047_migrate_kerberos_keytabs_to_principals
Traceback (most recent call last):
File "/usr/local/www/freenasUI/manage.py", line 42, in <module>
execute_from_command_line(sys.argv)