SOLVED Update causing issues

[TheDubiousDubber]

So I updated to the latest stable release today and it seems to have caused some issues. The alert light is red and when clicked gives the message:

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

Normally I would just roll back to previous software, but the system tab is not loading properly and displays:

{"message": "Error: no such column: system_systemdataset.sys_uuid_b", "events": [], "error": true}

Since the system tab doesn't load I can't reach the boot menu or the update menu. I'm pretty inept without instruction when it comes to the CLI so I have no idea what to do.

 

[dlavigne]

Do you remember which build version you upgraded from?

 

[TheDubiousDubber]

I had upgraded from the latest stable build (6/29) to the new latest stable and apparently installation failed. I'm running a headless unit and haven't gotten IPMI working yet so I was kind of screwed. I managed to run a cable from my box to my TV and rebooted to the previous build and all is well. Might just skip the latest for now.

 

[dlavigne]

Hmm, haven't seen that error before for an upgrade between those two STABLEs. If you get IPMI working and attempt another upgrade, let us know if you can recreate the issue.

 

[TheDubiousDubber]

After the release I upgraded to 9.3.1. The same issue happened. After upgrading I'm getting same errors. CRITICAL: Update failed. Check /data/update.failed for further details.

Under the system tab it shows the following:

{"message": "Error: no such column: system_systemdataset.sys_uuid_b", "error": true, "events": []}

Under the network tab, directory tab and services tab, it shows the following:

{"message": "Error: no such column: network_globalconfiguration.gc_hostname_b", "error": true, "events": []}

Shell keeps outputting this:

freenas alert.py: [system.alert:194] Alert module ' ' failed: table system_systemdataset has no column named sys_uuid_b

Scrolling up further I noticed some other warnings:

freenas root: /etc/rc: WARNING: failed precmd routine for vmware_guestd

some gibberish and then

freenas root: /etc/rc: WARNING: /usr/local/etc/smb4.conf is not readble.

I'm not sure if that is related or relevant, but WARNING tends to stick out so thought might be helpful. It looks like I may just be stuck at 9.3 for the foreseeable future.

 

[dlavigne]

Hmm, that error usually occurs when you try to apply a newer config (from a nightly) to an older build (from a stable). Were you on a nightly at some point? Can you post a screenshot of your System -> Boot?

 

[TheDubiousDubber]

I did move over to a nightly to fix an issue with something (though I forgot what the issue was), but then went back to stable as soon as the next stable release came out.

The stable build that is active works fine without issue. Trying to update to the newer stable resulted in this issue and again after trying to update to 9.3.1. Is there some kind of workaround for this, or am I going to have to trash my config and create a new one?

 

[dlavigne]

Is there some kind of workaround for this, or am I going to have to trash my config and create a new one?

I'm not sure... Were you able to find a workaround?

 

[TheDubiousDubber]

Haven't found a workaround and I haven't had the time needed to redo my config, so I've been sitting at the stable that works. I will likely do a fresh install of the current this weekend, import my pool, and try to reconfigure everything to the way it was. Should be fun...

 

[rogerh]

It might be worth booting from an older stable build, before the excursion into the nightlies, and then try to update from there.

 

[TheDubiousDubber]

It might be worth booting from an older stable build, before the excursion into the nightlies, and then try to update from there.

Hadn't thought of that. Not sure that it will work, but may be worth a try. I would think going from a nightly to a previous stable would cause more problems than a nightly to a newer stable. Though I must admit, when it comes to technology, sometimes stuff works even though it shouldn't.

 

[rogerh]

Hadn't thought of that. Not sure that it will work, but may be worth a try. I would think going from a nightly to a previous stable would cause more problems than a nightly to a newer stable. Though I must admit, when it comes to technology, sometimes stuff works even though it shouldn't.

If you use the System/Boot menu to activate an older stable boot snapshot you are not "going from" a nightly, you are booting exactly what you had when that boot record was last used, config and all. At least, that's how I understand it. I could be wrong.

 

[TheDubiousDubber]

If you use the System/Boot menu to activate an older stable boot snapshot you are not "going from" a nightly, you are booting exactly what you had when that boot record was last used, config and all. At least, that's how I understand it. I could be wrong.

I always thought the config stays persistent, rolling back to a previous boot menu only changes the environment, thus the need to back up configs prior to updates so you can roll that back as well if need be. If not that would be awesome, but I guess I'll just have to mess around with previous environments then try to update and see if anything works. If not, then I'll be building a new config from scratch this weekend.

 

[rogerh]

I always thought the config stays persistent, rolling back to a previous boot menu only changes the environment, thus the need to back up configs prior to updates so you can roll that back as well if need be. If not that would be awesome, but I guess I'll just have to mess around with previous environments then try to update and see if anything works. If not, then I'll be building a new config from scratch this weekend.

You may well be right on that! The manual does not seem to be specific. Can you let us know, perhaps by making a specific minor config change, whether reverting to a previous boot snapshot does keep the current config? It seems a useful thing to know for sure.

 

[TheDubiousDubber]

I have the day off tomorrow so I should have some time to give it a shot. I'll put an update here with the results.

Update -

So I rolled back to a boot environment prior to moving to the nightly build. I setup a new AFP share prior to rolling back and after rolling back the share was no longer there. It would seem you were correct in thinking the config rolls back along with the boot environment, which I guess makes sense now that I think about it more. Trying to update to current from the old boot enviro as suggested. I'll let you know how it goes.

Update 2 -

So I updated to the latest after rolling back and the error is gone. Everything looks green. A few config changes and its back to what it should be. Thanks for the suggestion! Worked like a charm.

One thing to add. Since I rolled back so far, the GUI thinks my plugins need to be updated, but when I try to update it errors out. I was up to date prior to rolling back so I'm guessing it recognizes that it's up to date and that is why it is erroring out. Oh well. It works for now.

 

[cyberjock]

The config file is stored IN the environment. So if you roll back the environment, you roll back the config file. This is necessary because the config file format may change from build A to build B, and if you roll back the OS to build A but keep the config for build B then bad things can happen. :P