Problem after FreeNAS-9.3-STABLE-201501150211 update

[Chris Dawalt]

I get this when I try to look at System / Boot


{"events": [], "error": true, "message": "Error: table system_advanced has no column named adv_boot_scrub"}

In fact, General, System, Email and System Dataset all give a similar error

 

[escrima]

I had the same thing happen just now. Freenas said the update failed. Here is the contents of update.failed

Code:

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
ps: empty file: Invalid argument
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:
- Migrating forwards to 0040_auto__del_field_ldap_ldap_use_default_domain.
> directoryservice:0035_pwencrypt
- Migration 'directoryservice:0035_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: directoryservice:0035_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)
- Migrating forwards to 0040_auto__del_field_ldap_ldap_use_default_domain.
> directoryservice:0035_pwencrypt
- Migration 'directoryservice:0035_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: directoryservice:0035_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, **o

 

[dlavigne]

Please create a bug report at bugs.freenas.org and post the issue number here.

 

[jlpellet]

7527

I too have update fail, as shown below - may be different issue. Created bug # above.

When attempting to update 201501150211 Stable train to 1844 as shown on the update page in the GUI, I get the following error. Have confirmed on multiple systems.

Jan 15 16:20:01 fn0 updated.py: [freenasOS.Update:699] Unable to mount boot-environment FreeNAS-9.3-STABLE-201501151844
Jan 15 16:20:08 fn0 updated.py: [freenasOS.Update:741] Update got exception during update: Unable to mount boot-environment FreeNAS-9.3-STABLE-201501151844
Jan 15 16:20:10 fn0 manage.py: [middleware.exceptions:38] [MiddlewareError: Unable to mount boot-environment FreeNAS-9.3-STABLE-201501151844]

 

[Joe-freenas]

Previous to latest update introduced a bug which makes new updates fail.
They already put a patch in the latest nightly build, but if updates cannot be appplied....what to do!?
Thanks to ZFS, the solution is easy...simply reboot and choose the previous boot environment at boot time and then simply apply latest update and presto!
Thanks ZFS, thanks FreeNAS team and you are welcome! ;-)

 

[jlpellet]

My issue was a typo in /usr/local/lib/freenasOS/Update.py (arts = should be args = ). I edited the file in shell & update worked & was more work but quicker that changing the boot & rebooting. YMMV, depending on console familiarity. Thanks.

 

[Chris Dawalt]

My issue was a typo in /usr/local/lib/freenasOS/Update.py (arts = should be args = ). I edited the file in shell & update worked & was more work but quicker that changing the boot & rebooting. YMMV, depending on console familiarity. Thanks.

Can you expand a little on your shell editing technique?

 

[jlpellet]

What I did was open a Putty ssh session from my Win7 desktop (you can use the GUI shell command on the left pane of the GUI) then use the built-in editor (nano) to edit the file. The command would be "nano /usr/local/lib/freenasOS/Update.py" without the "". I'd suggest before doing so, making a backup copy of the original, such as "cp /usr/local/lib/freenasOS/Update.py /usr/local/lib/freenasOS/Update-py.orig" to male it easy to recover, if needed. nano basic commands are shown at the bottom of the screen. I recommend doing some research if one is not familiar with the command line use - it's easy to brick things.

 

[Chris Dawalt]

Good idea - I will read up on it first. Thanks!

 

[DrKK]

I can confirm:

If you know you have the update that breaks future updates:

1) Go into system->boot
2) Select the previous boot image before the last update,
3) Click "Activate" (may take a minute).
4) Reboot.
5) Go to system->update, and update as normal.

And all is well, and you have circumvented it.

If you never had the bad update, then none of this affects you.

 

[Chris Dawalt]

Actually - if you look at the first post in this thread - I can't access the Boot options. I was able to go into the console and boot to an earlier rev, and that took care of the update issue, but I still have the boot option problem...

 

[Jaroslav Jasek]

Hi,
I have also problem starting FreeNAS after updating from 9.2.1.8 to 9.3.x - after starting FreeNAS stop wit message :
Unable to load a kernel.

I look this message - I found answer, that I must have 9.3 image on the USB.
My question - which from file fro download have image for USB ?
- Installing FreeNAS
- Upgrading FreeNAS

On the last versions was also image for USB - now in 9.3 is not any file with this description :-(

Thanks
Jaro

 

[Dave Genton]

I also ran into this problem so waited and sure enough today there is another update for the Stable release train. Today's release however is also failing with unable to mount boot image then gives the version with today's date etc... I was hoping todays would fix it, but it did not, is there a next move ?? On my backup FreeNAS box I rebooted it using boot environment prior to yesterdays release issue but today's still fails on that box just as it is with same error on my main "production" box.

Dave

 

[dlavigne]

Worth creating a bug report at bugs.freenas.org. If you do, post the issue number here.

 

[Dave Genton]

Worth creating a bug report at bugs.freenas.org. If you do, post the issue number here.

I certainly can but figured it was already know getting 2 immediate responses with fix and exact cause of issue being known. If despite this there is still nothing documenting this in the bug app and people will continue to get bit by this, by all means I will do so if you confirm this to STILL be the case at this time. Please let me know if you need me to do so, I still have most the info close by.

 

[Dave Genton]

Worth creating a bug report at bugs.freenas.org. If you do, post the issue number here.

Went ahead not seeing it, #7545 created and posted sir,

thanks again guys,
dave

 

[cyberjock]

dlavigne isn't a sir. ;) Hehe. She gets that all the time though, so don't feel bad.

 

[Chris Dawalt]

Latest update today took care of all my problems.

FreeNAS-9.3-STABLE-201501162230

Running smoothly - thanks to all who fixed it.