Update Failed

[mskenderian]

i tried to update my box. after the restart i got this message:

"CRITICAL: Update failed. Check /data/update.failed for further details."

so i checked it out, this is what it says:

"
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 storage:
- Nothing to migrate.
- Loading initial data for storage.
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 0158_auto__add_field_afp_afp_srv_homename.
> services:0158_auto__add_field_afp_afp_srv_homename
- Loading initial data for services.
Installed 0 object(s) from 0 fixture(s)
Running migrations for system:
- Nothing to migrate.
- Loading initial data for system.
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 sharing:
- Migrating forwards to 0033_add_periodic_snapshot_task.
> sharing:0032_auto__add_field_cifs_share_cifs_storage_task
> sharing:0033_add_periodic_snapshot_task
- Migration 'sharing:0033_add_periodic_snapshot_task' 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: sharing:0033_add_periodic_snapshot_task
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/sharing/migrations/0033_add_periodic_snapshot_task.py", line 28, in forwards
)[0]
File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 132, in __getitem__
return list(qs)[0]
IndexError: list index out of range
"

i went back a few snapshot of the boot environment and clean up the rest. then after restart i tried to update again. i got the same message above.

any suggestions?

 

[dlavigne]

How big is the boot device? How many boot environments are in it? You may have to prune some of the older ones using System -> Boot.

 

[mskenderian]

I had pruned half of the boot environments. its 16gb.

[root@garni ~]# egrep da0 /var/run/dmesg.boot
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <WDC WD60EFRX-68MYMN1 82.00A82> ATA-9 SATA 3.xda0 at umass-sim0 bus 0 scbus7 target 0 lun 0
da0: <SanDisk Cruzer Fit 1.26> Fixed Direct Access SCSI-6 device
da0: Serial Number 4C5320000009248555210
da0: 40.000MB/s transfers
da0: 15267MB (31266816 512 byte sectors: 255H 63S/T 1946C)
da0: quirks=0x2<NO_6_BYTE>

now i pruned all of them but one, and now i am scrubbing, then i will try again and report.

 

[mskenderian]

So i change the boot snapshot, to an older one. pruned all of the snapshots. scrubbed the boot device, restarted the box. then did an update, after update restart i got the same message to check the logs.

"
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 storage:
- Nothing to migrate.
- Loading initial data for storage.
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 0158_auto__add_field_afp_afp_srv_homename.
> services:0158_auto__add_field_afp_afp_srv_homename
- Loading initial data for services.
Installed 0 object(s) from 0 fixture(s)
Running migrations for system:
- Nothing to migrate.
- Loading initial data for system.
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 sharing:
- Migrating forwards to 0033_add_periodic_snapshot_task.
> sharing:0032_auto__add_field_cifs_share_cifs_storage_task
> sharing:0033_add_periodic_snapshot_task
- Migration 'sharing:0033_add_periodic_snapshot_task' 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: sharing:0033_add_periodic_snapshot_task
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/sharing/migrations/0033_add_periodic_snapshot_task.py", line 28, in forwards
)[0]
File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 132, in __getitem__
return list(qs)[0]
IndexError: list index out of range
"

any suggestions?

 

[mskenderian]

BTW i had reverted to FreeNAS-9.3-STABLE-201501301837.
even after the update failed. i am now on
FreeNAS-9.3-STABLE-201502110455

so i dont get it, it failed but i am on a updated version?

 

[dlavigne]

It looks like that error occurs if you migrate from a newer version to an older version or from a NIGHTLY to a STABLE (see
https://bugs.freenas.org/issues/7884). Though, if it says you're updated, you're updated.

When pruning BEs in the future, always keep the most recent one and possibly the one before that.

 

[Junkyboy]

I got this error and Ive never used Nightly. I use a 8gb usb drive and had about 5 or 6 entries listed in the grub boot menu. I deleted every entry in boot except for the last 2 ( FreeNAS-9.3-STABLE-201501241715 and FreeNAS-9.3-STABLE-201502110455). The information screen shows FreeNAS-9.3-STABLE-201502110455. When I select Services to disable the broken AFP option, I cant even get that far. I see
{"message": "Error: no such column: services_afp.afp_srv_homename", "events": [], "error": true} instead of all of the services.

I scrubbed the boot drive and rolled back to FreeNAS-9.3-STABLE-201501241715. Booted up fine. I ran the upgrade again and got the same error. Verify Install didnt find anything either. At this point I'll roll back again and wait for the next update.
It would be nice to simply run the sqlite db.add_column (from http://permalink.gmane.org/gmane.os.freenas.scm/15992) but since its all wrapped in django I guess thats not an option.

 

[mskenderian]

My alerts still says "CRITICAL: Update failed. Check /data/update.failed for further details.", how do i clear this?

 

[dlavigne]

To silence the alert, uncheck the box next to it.

Are you still having an issue with the update? If installing the latest STABLE does not fix it, create a bug report at bugs.freenas.org and post the issue number here.

 

[mskenderian]

Just updated my main box, seems to be fine. updating my second box now.

 

[Junkyboy]

The recent fix worked for me as well.