How do I rollback a version of OPNsense

[bs20707]

I am a newb and maybe I missed it, but I have tried searching for "rollback" "revert" etc but how do I in a supported way rollback to the last working version of OPNsense? 24.7 has issues so I'd like to roll back to just prior to its install.

I have seen posts where folks have tried and seem to have broken with boxes and functionality by doing CLI hack commands.

What is the preferred way by OPNsense to roll back?

And yes I have looked at the FQ page, and I might have missed it, I am old after all.

Thank you

[Patrick M. Hausen]

If you did not install with ZFS and create a boot environment, i.e. a snapshot, before updating, there is no rollback, save by a reinstall and import of your saved config. Rollback within OPNsense is only possible for minor version updates.

[bs20707]

Thank you for your reply. Sadly, no ZFS is not installed. I did not specifically do a backup prior to the install. I assumed (yep I know what that means) that the update would have done that.

So IF there was a backup, I just do a reboot and at the OPNsense boot menu I tell it there to do a roolback / recover of a backup?

[Patrick M. Hausen]

No, you prepare a USB boot stick with the 24.1 version and do a completely fresh install.

[vivekmauli14]

Hi Patrick,

I wanted to ask if designing a rollback mechanism for OPNsense is feasible. Specifically, I'm thinking of a feature similar to what we have with the changelog section in our UI/core/firmware. The idea would be to allow users to revert to a previous version by installing packages from the respective version's repository-pkgs.opnsense.org.

Would it be possible to implement a revert option in the UI, and develop an API to handle the installation of all packages from a selected version?

I'm also interested in understanding the potential security implications of such a feature and whether you think it's doable.

This is being raised as some of my users want a rollback for up to 2 firmware updates. Looking forward to hear from you

Thanks,
VivekSP

[franco]

Rollbacks can rarely be handled in software alone, especially in operating systems with a shifting ABI.


Cheers,
Franco

[Patrick M. Hausen]

It is perfectly possible, since it is just software. Go ahead, clone the repo, develop the feature, submit a pull request.  ;D

If the question is if anyone is working on that - it's not on the publicly available road map. To bring it on the road map you would need to convince Deciso with a clear business case, i.e. money.

For example frequently updates involve a change of the underlying FreeBSD version. No way to just "pkg install" to roll back. Also updates change things in the configuration if the underlying data model changes. How would you roll back that?

It is far too complex to be developed by a spare time community developer alone. That needs a coordinated effort with the core development team. 1 person year minimum would be my educated guess.

You can use ZFS boot environments to do it manually, I documented the entire procedure here:
https://forum.opnsense.org/index.php?topic=25540.msg122731#msg122731

Summary: if you prepare in advance you can always roll back. Just restore from backup/snapshot.

HTH,
Patrick

[meyergru]

Maybe I do not see all implications, but the bectl method could be agumented as follows:

1. On every update, a "bectl create <oldversion_name>" is done (i.e. if OpnSense sits on ZFS).
2. A UI plugin to manage boot environments to create, delete or rollback/reboot to a specific be is built.

[Patrick M. Hausen]

Maybe I do not see all implications, but the bectl method could be agumented as follows:

1. On every update, a "bectl create <oldversion_name>" is done (i.e. if OpnSense sits on ZFS).
2. A UI plugin to manage boot environments to create, delete or rollback/reboot to a specific be is built.

That has a high chance of working in most cases and would be way less work then reinstalling older packages reliably.

Only thing that broke for me once - when directory structures and/or data formats in /var change - these are not part of the BE. By design, because generally you don't want to roll back your logfiles.

But e.g. Elastic might perform an in-place upgrade to a newer version and then your rolled back system will not be able to read the DB, anymore.

[franco]

https://github.com/opnsense/core/pull/7650 ;)

[Patrick M. Hausen]

\o/

[dwoodroofe]

The entire 24.7.x line appears to have major issues.