Does a rollback after a failed upgrade works as I think?

[Solero]

Hi,

I just experienced this bug and got interested in how to roll back to a previous version of FreeNAS.
The manual says that I can mark another boot environment as active in order to boot with it.
Here comes my question:

Is this everything which need to be done?
I am quite familiar with linux and ext4. If I just change the boot environment there then I will be using the previous kernel, but all the system files ( /etc, /bin, ... ) will be the same. If the whole FreeNAS System is inside the boot environment this will work, of course. But I don't know if this is the case.

Is it really that simple to revert an update or do I have to consider anything else?

Solero

 

[dlavigne]

Is it really that simple to revert an update or do I have to consider anything else?

Yup, that's the beauty of boot environments.

 

[Solero]

Cool.
Thanks for the super fast reply.

Solero

 

[Ericloewe]

Is it really that simple to revert an update or do I have to consider anything else?

You will lose any configuration changes made after the update that generated the boot environment you're rolling back to.

 

[Solero]

You will lose any configuration changes made after the update that generated the boot environment you're rolling back to.

So what I should do is make a config backup of my current settings, switch to the old environment and apply the config back to the system, right?
I guess this only works as long as there are no changes in the structure of the db which holds the settings. Is this correct?

 

[danb35]

You should not expect that a configure database from a newer version will work with an older one.

 

[Ericloewe]

So what I should do is make a config backup of my current settings, switch to the old environment and apply the config back to the system, right?
I guess this only works as long as there are no changes in the structure of the db which holds the settings. Is this correct?

See danb35's reply.

In practical terms, this means you'll want to manually backup the config after major changes, before updates.

 

[Solero]

Ok, please excuse my stupid question, but can I consider the following as best practice?

I have the environments: 'old', 'now' and 'new'

1. Update 'new' gets announced by FreeNAS
2. I do a manual backup config of 'now'
   
3. I do the update to 'new' and if I want to revert the update to 'now' then ...
   
4. I switch to the previous environment 'now'
   
5. I load the backup config into FreeNAS otherwise I would have the config state at the moment I updated from 'old' to 'now'
   
6. If I had done changes to the FreeNAS config after the update I should apply these changes via the gui manually

 

[Ericloewe]

Well, yeah, but 6 only applies if you don't have the backup (5).

 

[danb35]

If you want to revert to 'now', pick it from the boot menu. The 'now' environment will exist exactly as it did immediately before you did the upgrade.

 

[Ericloewe]

If you want to revert to 'now', pick it from the boot menu. The 'now' environment will exist exactly as it did immediately before you did the upgrade.

Actually, the snapshots are made during the upgrade that installs now, so it's the state at the time of upgrading from previous to now, not from now to new.

 

[danb35]

Really? That seems awfully unintuitive. Wonder if there's any chance of changing that behavior.

 

[Solero]

Actually, the snapshots are made during the upgrade that installs now, so it's the state at the time of upgrading from previous to now, not from now to new.

That's what I expected.
I hope FreeNAS 10 has a feature to prompt the user to download the config before an update gets started.
Anyway, it sounds wonderful that there is literally no 'risk' in upgrading vom 9.10 to 10 as I can go back so easily. I planned a full day for the server upgrade from debian wheezy to jessy and I needed that time...

 

[Ericloewe]

Really? That seems awfully unintuitive. Wonder if there's any chance of changing that behavior.

IIRC, it was a design choice to aid in recovering from "Oh, "%/#, I ruined my config..." scenarios.

 

[Bidule0hm]

Then why not a snapshot when you upgrade from previous to now but also from now to new?

 

[Ericloewe]

Then why not a snapshot when you upgrade from previous to now but also from now to new?

I guess they thought it would be unnecessary duplication most of the time.

If you assume that configs change very little between updates, most of the time, the whole process makes a bit more sense:

• It avoids duplication of config files
• It helps to protect against the messed-up config scenario
• It's not inconvenient in most scenarios

 

[cyberjock]

What is unintuitive about how the boot environments work?

If you are using a boot environment, that environment is kept up-to-date with the applicable changes when you use it. When you stop using it, the environment is not mounted and therefore changes are no longer being made.

Seems very intuitive to me...

 

[danb35]

That sounds just like what I'd expect, but not like what I understand Eric to have said. That would mean that when you create a new BE, and then revert to the previous one, the previous BE would be in the state it was in when you created the new one. Or am I missing something?

 

[cyberjock]

That sounds just like what I'd expect, but not like what I understand Eric to have said. That would mean that when you create a new BE, and then revert to the previous one, the previous BE would be in the state it was in when you created the new one. Or am I missing something?

Nope. The behavior you described is exactly how it is. :D

 

[depasseg]

What is unintuitive about how the boot environments work?

If you are using a boot environment, that environment is kept up-to-date with the applicable changes when you use it. When you stop using it, the environment is not mounted and therefore changes are no longer being made.

Seems very intuitive to me...

I think the confusing part is thinking of the boot environments as snapshots, and trying to identify when a snapshot is taken, and what the data looks like at that time.
Are Boot Environments just snapshots? If yes, then when are they taken, if no, then what are they?

For example (see diagram below), I thought of them as snapshots, and when upgrading from version 1 to 2, I would have thought that a snapshot called "Version 1" was created at point B (and the user guide seems to support this - "5.3. Boot Beginning with version 9.3, FreeNAS® supports a feature of ZFS known as multiple boot environments. With multiple boot environments, the process of updating the operating system becomes a low-risk operation as the updater automatically creates a snapshot of your current boot environment and adds it to the boot menu before applying the update. If the update fails, simply reboot the system and select the previous boot environment from the boot menu to instruct the system to go back to that system state.")"

What I kinda thought I heard above was that the "Version 2" snapshot was created at point C. And that is where my confusion came in.