Hi,
I was trying to update my FreeNAS 9.3 (FreeNAS-9.3-STABLE-201501090144 - that's what it says now in system information) using the new update functionality in the WebUI. It performed the update, but when the machine rebooted, I noticed that the update apparently failed and a file /data/update.failed was created. These are the contents of the file:
When I go to the "Update" section of the system settings now, it says there are no updates. Apparently, the database could not be migrated - and now I think I am left with an inconsistent DB state. Anyone knows what to do?
Another thing: If I wasn't present when the system rebooted, I wouldn't even know about the update failure. The WebUI doesn't show any errors (I would have expected to see something in the "Alerts" in the top right corner).
I was trying to update my FreeNAS 9.3 (FreeNAS-9.3-STABLE-201501090144 - that's what it says now in system information) using the new update functionality in the WebUI. It performed the update, but when the machine rebooted, I noticed that the update apparently failed and a file /data/update.failed was created. These are the contents of the file:
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 directoryservice:
- Nothing to migrate.
- Loading initial data for directoryservice.
Installed 0 object(s) from 0 fixture(s)
Running migrations for services:
- Migrating forwards to 0157_auto__del_field_iscsitarget_iscsi_target_logical_blocksize.
> services:0156_auto__add_field_iscsitargetextent_iscsi_target_extent_blocksize__add_f
! 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:
! 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:0156_auto__add_field_iscsitargetextent_iscsi_target_extent_blocksize__add_f
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/0156_auto__add_field_iscsitargetextent_iscsi_target_extent_blocksize__add_f.py", line 22, in forwards
for target in orm['services.iSCSITarget'].objects.all():
File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 96, in __iter__
self._fetch_all()
File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 857, in _fetch_all
self._result_cache = list(self.iterator())
File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 220, in iterator
for row in compiler.results_iter():
File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 713, in results_iter
for rows in self.execute_sql(MULTI):
File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 786, in execute_sql
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/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 452, in execute
return Database.Cursor.execute(self, query, params)
django.db.utils.OperationalError: no such column: services_iscsitarget.iscsi_target_logical_blocksize
When I go to the "Update" section of the system settings now, it says there are no updates. Apparently, the database could not be migrated - and now I think I am left with an inconsistent DB state. Anyone knows what to do?
Another thing: If I wasn't present when the system rebooted, I wouldn't even know about the update failure. The WebUI doesn't show any errors (I would have expected to see something in the "Alerts" in the top right corner).