update to STABLE-201502271818 broken

[bal0an]

Hi,

I have upgraded from STABLE-201502142001 and encountered this issue (from data/update.failed)

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:
- Nothing to migrate.
- Loading initial data for directoryservice.
Installed 0 object(s) from 0 fixture(s)
Running migrations for services:
- Migrating forwards to 0160_pwencrypt.
> services:0160_pwencrypt
- Migration 'services:0160_pwencrypt' 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:0160_pwencrypt
Traceback (most recent call last):
...
​

Anything I can do to fix it?
Should I open a bug?

Regards, Andreas

 

[dlavigne]

What is the size of the boot device? How many boot environments exist in System -> Boot? Does removing all but the last two or so boot environments fix the issue?

 

[bal0an]

8GB USB stick, 3 environments, system seems to be up and running without issues.

Andreas

 

[bal0an]

Traceback (cont'd)

Error in migration: services:0160_pwencrypt
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/0160_pwencrypt.py", line 28, in forwards
do_encrypt(orm['services.DomainController'], 'dc_passwd')
File "/usr/local/www/freenasUI/../freenasUI/services/migrations/0160_pwencrypt.py", line 19, in do_encrypt
obj.save()
File "/usr/local/lib/python2.7/site-packages/django/db/models/base.py", line 545, in save
force_update=force_update, update_fields=update_fields)
File "/usr/local/lib/python2.7/site-packages/django/db/models/base.py", line 573, in save_base
updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields)
File "/usr/local/lib/python2.7/site-packages/django/db/models/base.py", line 635, in _save_table
forced_update)
File "/usr/local/lib/python2.7/site-packages/django/db/models/base.py", line 679, in _do_update
return filtered._update(values) > 0
File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 510, in _update
return query.get_compiler(self.db).execute_sql(None)
File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 980, in execute_sql
cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 776, in execute_sql
sql, params = self.as_sql()
File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 945, in as_sql
val = field.get_db_prep_save(val, connection=self.connection)
File "/usr/local/lib/python2.7/site-packages/django/db/models/fields/related.py", line 1236, in get_db_prep_save
connection=connection)
File "/usr/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 350, in get_db_prep_save
File "/usr/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 350, in get_db_prep_save
prepared=False)
File "/usr/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 606, in get_db_prep_value
value = self.get_prep_value(value)
File "/usr/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 613, in get_prep_value
return int(value)
ValueError: invalid literal for int() with base 10: 'None'

 

[cyberjock]

I would put a ticket in. If you could be patient and let the devs see what they need before rolling back, etc. They may be able to figure out why this is happening. We've had a few people with issues like this but so far been unable to get enough information before the user wipes out the evidence.

 

[bal0an]

Bug #8366 created. As the system states the database is in an intermediate state I don't dare to touch the system until a proven path to recover is provided.

Andreas

 

[cyberjock]

If you are worried about your data, you can relax. Your data pools aren't touched during upgrades. So the worst case scenario is you'd have to restore your config from backup or if you have no backup, redo the actual configuration of FreeNAS. But the pool is a simple import away. ;)

 

[bal0an]

Issue went away after modifying the sqlite database as described in original bug ticket. Thanks.