Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Contributor II

Upgrade path for 7.2.5 to 7.2.8

The upgrade path from 7.2.5 is to first go to 7.2.7 then to 7.2.8.

What is actually happening during the 7.2.7 upgrade that it is required as part of the process?


If the recommended upgrade path is 7.2.5->7.2.7->7.2.8, the upgrade software is not written to handle at least some part of database structure conversion from 7.2.5's or earlier 7.2 versions' directly to 7.2.8's. But the software is capable to convert from 7.2.5's to 7.2.7's, then it's capable to convert from 7.2.7's to 7.2.8's.



Contributor II

Thank you for the response.

Can I get a staff members verification on this?

Does 7.2.7 provide some type of system update that is not available if moving from 7.2.5 to 7.2.8.  If it is... what exactly is being updated?


Firmware updates are not mere code replacements, but (occasionally) enhanced by scripting. This is to automatically take care of changes in syntax, variable names or default settings.

That's why there is a Recommended Upgrade Path in the first place. One wouldn't need it if code was merely replaced by the newest firmware image. (Which, btw, is the case for other Fortinet devices, like FortiSIEM).

And, as a consequence, downgrades do not work gracefully as scripting is a one way procedure.


The Release Notes will give you at least hints which features have been changed - sections "New features or enhancements" and "Resolved issues". While new features are easy to spot (example later), bug fixes may involve multiple changes, like in variables, engines, dependencies etc. To adapt these to a live configuration, the current config may need to be taken into account. Thus FTNT introduced scripting.


IMHO Fortinet will not disclose each and every change and it's dependencies in public. What for, if we don't know how FortiOS is written in full?

If you are asking for this info to justify longer update procedures (or higher cost), then let management know it is "Best practice" with this vendor.


Now for a particular v7.2.7 to v7.2.8 update, as an example:

IIRC in v7.2.7, a new feature was introduced, auto-updating to the latest (minor) patch version. The update set this to be "enabled". Suprise, surprise.

In an enterprise/production environment, this doesn't chime nicely. Obviously, FTNT noticed the negative feedback despite the well-meant intention, and in v7.2.8, on initial login you are now asked whether you want to enable this, and at which time and day. As far as I've seen, on small models, the default now is "enabled", on XXX models and up it is "disabled".

This new feature is a very simple addition of a parameter, not needing any scripting. You could happily jump from v7.2.5 to v7.2.8 directly if this was the only change.

But it isn't, and gladly so. Thus, Recommended Upgrade Path.


edit: just learned that the auto-upgrade feature was introduced in v7.2.6. But the general reasoning still applies.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Top Kudoed Authors