Confused by 26.7 upgrade

Started by Plethodon, August 31, 2026, 12:29:18 AM

Previous topic - Next topic
> Apparently the rules didn't continue to work.

You're convoluting your experience with the technical facts in this particular case. It's futile to go into an argument like that.


Cheers,
Franco

September 09, 2026, 05:05:58 AM #31 Last Edit: September 09, 2026, 05:24:10 AM by defaultuserfoo
Quote from: franco on September 08, 2026, 08:56:50 AM> Apparently the rules didn't continue to work.

You're convoluting your experience with the technical facts in this particular case. It's futile to go into an argument like that.


Cheers,
Franco

I'm not convoluting anything.  IIUC, someone created this thread when he found that he can not enable or disable firewall rules after an upgrade anymore, and was advised to install a plug-in to fix that.  I haven't made this experience, but I made the experience that the firewall rules didn't work after the migration and had all to be redone.  After the painful experience, I was told that it would take many years to come before the migration would be necessary.  In spite of that, now apparently everyone who wants to be able to enable or disable firewall rules needs to do some kind of migration, even if it is only to install the plug-in.

Don't continue to pretend that it is an easy and harmless migration that wouldn't even require a big fat warning.  It is not.

This is not about technical details but about the user experience and about improving it.  From the technical details being clear to the developers, it doesn't follow that users are sufficiently informed even when they read the release notes.  Apparently, this very argument is futile here.  I wonder why that is.
PowerEdge R210II

Regarding the specific topic at hand: The transition to the new rule framework has been a subject of discussion in this forum since January 2026. The migration assistant is a no-brainer; thanks to it—and the available backup and restore options—the transition poses absolutely no risk.

In general, users of the OPNsense Community Edition should be aware that they are, to some extent, testers for new features that eventually make their way into the paid version of OPNsense.
In return, however, they receive a fantastic firewall for free—one that need not shy away from comparison with expensive commercial competitors.
This forum is active and monitored by highly experienced users who are always ready to help—often even when a topic has been discussed repeatedly and the answer could have been found via a simple search.

It is up to the individual whether to adopt changes early during version updates or to wait for reliable, rapid bug fixes.
However, if you use the Community Edition, I believe you also bear some responsibility for regularly reading forum posts; otherwise, you might find yourself facing a problem eight months down the line that has already been thoroughly discussed and addressed. This applies equally to experienced forum members and OPNsense newcomers.
Supermicro M11SDV-4C-LN4F AMD EPYC 3151 4x 2.7GHz RAM 8GB DDR4-2666 SSD 250GB

A great example is the Intel microcode plugin that if I had read the forum properly would have known I should have removed it before upgrading to 26.7.
I didn't, so I had a broken install since it timed out trying to upgrade and I had to use the bootstrap script to fix it.

> IIUC, someone created this thread when he found that he can not enable or disable firewall rules after an upgrade anymore, and was advised to install a plug-in to fix that.

Which is correct, but that's in the release notes. You don't need the plugin to use and/or migrate the rules, but you need the plugin to administrate them.

> but I made the experience that the firewall rules didn't work after the migration and had all to be redone

Which is entirely different.  It may be because of FreeBSD 15.1 or something else.  It looks like we don't know?

> Don't continue to pretend that it is an easy and harmless migration that wouldn't even require a big fat warning.  It is not.

I never pretended it was easy and harmless for you.  This is the core of the issue.  It is your experience.  Not everyone else's.

> I wonder why that is.

Because you don't know what the problem is, but feel entitled to raise your concern in advance?  If I know your exact problem I can probably help or point to the right bits of documentation.

> However, if you use the Community Edition, I believe you also bear some responsibility for regularly reading forum posts; otherwise, you might find yourself facing a problem eight months down the line that has already been thoroughly discussed and addressed. This applies equally to experienced forum members and OPNsense newcomers.

Sometimes perhaps, but I'm surprised at the trivial questions that are being raised seeing the code that was touched and people not realising how many technical issues they would never notice because a) they don't have the setup or b) changes are handled in a way that few regressions arise to begin with.

> A great example is the Intel microcode plugin that if I had read the forum properly would have known I should have removed it before upgrading to 26.7.

It's a very complex issue involving the microcode updates and the operating system that has been going on for years now -- and both are not under our immediate influence.  And here, also, it was clearly in the release notes:

https://github.com/opnsense/changelog/blob/b0be678d6235cb8da05446df7ea233c38cdcd0a7/community/26.7/26.7#L101


Cheers,
Franco

Quote from: franco on September 09, 2026, 09:27:40 AM> IIUC, someone created this thread when he found that he can not
  enable or disable firewall rules after an upgrade anymore, and was
  advised to install a plug-in to fix that.

Which is correct, but that's in the release notes. You don't need the
plugin to use and/or migrate the rules, but you need the plugin to
administrate them.

It's kinda in the release notes: 'Kinda' because it's very well
hidden.  I think it would be something that should be pointed out in
the 'Migration notes, known issues and limitations' section.

If someone doesn't read that section it's his fault.  I wouldn't blame
anyone for not reading the long list of items most or all of which
don't tell users anything.

Quote> but I made the experience that the firewall rules didn't work after
  the migration and had all to be redone

Which is entirely different.  It may be because of FreeBSD 15.1 or
something else.  It looks like we don't know?

Different from what?

It's not because of FreeBSD.  It's because things work differently
with the new rules so that the old ones can not easily be converted
into new ones.  I guess that there may be configurations for which the
migration works: That's only when no conversion is needed.  That
doesn't mean it would work for everyone, and it means that a big fat
warning is needed.

I'm basically using a configuration that goes as described in this post:
https://forum.opnsense.org/index.php?topic=28447.msg138309#msg138309

If you want to use IPv6 and don't have a static prefix, what other
solution is there?  It's working great, and it doesn't migrate.

Quote> Don't continue to pretend that it is an easy and harmless migration
  that wouldn't even require a big fat warning.  It is not.

I never pretended it was easy and harmless for you.  This is the core
of the issue.  It is your experience.  Not everyone else's.

I'm sure I'm not the only one to find out that the migration wasn't
easy and harmless.  Even if I'm the only one to experience that it
wasn't, it does warrant a big fat warning because there can always be
other users for which it won't be harmless and easy.

The core issue is that the migration was made to appear as being
harmless and easy and that the GUI suggested that we better do it
soon, and that we were not informed that we might have to redo our
firewalls and that we don't need to do the conversion anytime soon.

You right now still deny that it is not harmless and easy by
claiming that I'd be the only one for whom it wasn't.  Even if I am
the only one, it proves that your assumption that it is harmless and
easy is wrong.

Quote> I wonder why that is.

Because you don't know what the problem is, but feel entitled to raise
your concern in advance?  If I know your exact problem I can probably
help or point to the right bits of documentation.

I'm not raising my concern in advance.

I did the migration because it was made to appear easy and harmless a
while after there was the entry for the new rules in the GUI,
suggesting that I better migrate my rules as long as it is
possible. Living in the past seldwhen is a good idea, meaning that
things like software keep moving on, and when you don't keep up you
can get so far behind that you eventually find that updating isn't
possible anymore. I've had that happen and it's a situation I really
don't want to be in again.

I'm raising my concern only after I know what the problem is.  The
problem is that the migration can easily go wrong, and my concern is
that there needs to be a big fat warning about it instead of making it
appear easy and harmless.

I don't know exactly in detail what causes the problem, just see
above.  I don't expect you/the developers to fix the cause(s) so that
the problem doesn't exist anymore.  The big fat warning would suffice,
so everyone who planning to do the migration can make backups and set
aside time to try it out and do whatever they deem necessary
beforehand.

The user's approach needs to be 'the migration may go wrong and is
not necessary' instead of 'the migration is harmless and easy and
should be done as soon as possible'.

Quote> However, if you use the Community Edition, I believe you also bear
  some responsibility for regularly reading forum posts; otherwise,
  you might find yourself facing a problem eight months down the line
  that has already been thoroughly discussed and addressed. This
  applies equally to experienced forum members and OPNsense newcomers.

I did that until you drove me away.

Besides, users would have to not only read every post just in case
they might have a problem some months later but also remember it all.
I think that is demanded way too much.

It's like saying that every user of whatever software needs to read
everything about it in case he encounters a problem.

It doesn't work that way.  When I'm encountering a problem, I try to
solve it myself.  Asking questions anywhere is a last resort when
everything else fails.  The internet has mutated from a rather
friendly and helpful domain into the most hostile environment I
know. I don't want to ask questions because it almost always only
stirrs up useless and stupid discussions in which people try to insult
me, call me a troll and censor me.

Even if I wanted to read everything just to keep up to date, every day
would have to be at least a week long.

What if someone uses the business edition?

Quote> Sometimes perhaps, but I'm surprised at the trivial questions that
  are being raised seeing the code that was touched and people not
  realising how many technical issues they would never notice because
  a) they don't have the setup or b) changes are handled in a way that
  few regressions arise to begin with.

And yet you expect these people to read every forum post to be
informed and to remember all the technical issues, regressions and
setups they never encounter or have.

Maybe if the 'Migration notes, known issues and limitations' section were
more exensive and there were only a link to the (rather irrelevant)
long list of items, then people wouldn't have so many trivial
questions.

Quote> A great example is the Intel microcode plugin that if I had read the
  forum properly would have known I should have removed it before
  upgrading to 26.7.

> It's a very complex issue involving the microcode updates and the
  operating system that has been going on for years now -- and both
  are not under our immediate influence.  And here, also, it was
  clearly in the release notes:

https://github.com/opnsense/changelog/blob/b0be678d6235cb8da05446df7ea233c38cdcd0a7/community/26.7/26.7#L101

I guess you mean this:


"The CPU microcode early loading has been known to be flaky on some
setups.  A fix is in the FreeBSD 15.1 boot loader code, but can only
be reached by reinstall or manually updating the boot code of your
system after the upgrade succeeded.  If you want to be on the safe
side during the upgrade itself please remove the plugin before
proceeding."


I still don't know which plug-in this is referring to and how I would
update the boot code.

I can only guess that 'boot code' means the boot manager.  What
exactly am I supposed to do after reading this when I'm about to
update?  Why isn't the boot manager being updated automatically during
the update?

What I might do is figure out how one updates the boot manager of
FreeBSD.  But then, it would be pretty pointless because OPNSense
might be different from FreeBSD, so that might not work.  I wouldn't
take that chance.

I'm finding this also unclear.  It says I should manually update the
'boot code' (boot manager?) *after* updating.  That doesn't make sense
because if this goes wrong, booting wouldn't be possible.  So
obviously, I would need to update the 'boot code' before updating.

So maybe I better remove a plug-in first.  But which one?

Trivial questions?  Maybe, maybe not.  It's certainly not trivial when
I update and the router doesn't boot anymore.

The update shouldn't even start before that issue is somehow resolved
first.  Or perhaps I'm understanding this wrong and nothing can go
wrong when I update because the information is entirely unclear?

Why are the release notes not starting with the important section?
PowerEdge R210II