You may have upgraded just as we were switching the repos to RC and hence could not access the pkgs after upgrade.

The patches tab is part of the System Patches package, it look like that also failed to reinstall.

Those PHP errors are normal during the upgrade and are usually removed/hidden. Something during your upgrade prevented that happening. I would assume the same repo access problem.

Are you still seeing issues? Are you able to retest upgrading?

Steve

@stephenw10 said in No logs of pppoe process:

You can check it using: pppcfg pppoe0

That will return nothing if it's not an if_pppoe interface.

Based on that I misunderstood that still I should get nothing when running kernel too.
Thanks for clearing it up

@marcosm said in PHP Fatal Error Kea2Unbound:

When pfBlockerNG is in unbound mode the records it adds are considered local.

Thanks for insisting on that one.
I had to switch back to the old "Unbound mode" = one big DNSBL file, read into unbound during startup, to see what the difference is.
All these DNSBL entries are now considered local .... and indeed, the file became pretty big.

I really thought that the 'Unbound mode' wasn't used anymore, as 'way better' = 'Python mode' exists.

Thanks for the clarification.

So, the weird thing is that with the original 2.7.2 pfSense guest, the multicast packets traversed the Proxmox linux bridge fine. In the 2.8.0 pfSense guest, they do not get through the linux bridge.

My multicast setup has IGMP v3/MLD v2 enabled on all my HP V1910 switches. The central switch runs the IGMP/MLD queriers. This switch is connected to the Proxmox host which runs the standard linux bridge setup. pfSense is plugged into that bridge via virtio network interfaces (one for each VLAN).

I'm happy to run without snooping on the Proxmox bridge and have set the following in /etc/network/interfaces on the Proxmox host to turn off snooping permanently.

But I'm none the wiser why the 2.7.2 system was fine but the 2.8.0 system is not.

@dennypage

@dennypage said in Excessive bogon leading to interface down:

Arpwatch has two ways to deal with this. The first way is the -n flag, which allows adding additional local networks. This would make sense when using a virtual IP addresses, but this option is not exposed in the pfSense Arpwatch package interface. The second way is the -N option, which disables all bogon reporting. This option is exposed in the package as "Disable bogons", and I would always recommend enabling this option.

Great info, which i wish was in the UI to be honest. It's not clear how "bogons" are interpreted for internal network interfaces.

Thank you for the assistance with testing. The issue should be addressed as part of https://redmine.pfsense.org/issues/16180.

@louis2 said in When will 2.8 dev snapshot be available:

I also wonder why there is nu beta download !!

I planned to install the beta in a VM today so looking for the beta download .... no where ......

And for what reason ????

Just download installer, run it, and chose pfsense 2.8 beta from the menu. It is that simple.

You can also check the github history: https://github.com/pfsense/pfsense/commits/master/

Responding to myself here. It was a case of user error - I was simply too impatient.

I ran the same upgrade on a different system where I could watch the upgrade process on a console (an APU). I saw that after the browser session said "Success" and the system reboots, then starts a complete reinstallation, some steps taking considerable time (like "Skipping untrusted certificates"). At the end of that process, another reboot, and success!

So lesson learned - have patience. Lots of it.

I mean the qemu conf file for the VM which I expect to look pretty much the same in any host OS. Like:

It does look like we might be on to something upstream though. But first we need to replicate the failure which is proving difficult.

Edited. Thanks for testing!

@jimp

Ok. Yes, i had the patches package installed.

Thanks for the help.

@badders

Try helping your pfSense by informing it :

66fb872a-8555-4dac-8707-5dd20e8790de-image.png

@TampertK RSS pins flows to specific CPU cores, so if you're testing with a single flow this is what you'd expect to see.
Repeat your test with more flows and you'll see more of your CPU cores doing work.

packetcapture-vtnet0-20250411155701.pcap -> contains a prefix delegation change initiated by a WAN interface save&apply. You should see the request from the pfSense and the answer from the upstream internet router in this capture file.

IPv6 prefix assigned to upstream internet router by internet provider: 2003:e2:8703:e000::/56
Delegated to pfSense: 2003:e2:8703:e0f8::/61

@marcosm Thanks.
Yes, I have tried doing an override in the custom config of unbound but the result is as you say. Did a DNS Lookup from the GUI and it showed only a CNAME. From a client the query failed.

I will look into making a request.

@marcosm I manually edited rc.update_bogons.sh to apply the two changesets shown in the redmine. (I first manually applied the first changeset, then I manually applied the one with "additional improvements", which was clearly an edit on top of the first one.)

Both the bogonsv4 and bogonsv6 now update correctly. Here are my logs:

Thanks!

@bimmerdriver Your whole argument is going in the same circles. You don't see new snapshot -> you say it's dead. You simply ignore that there was and is work done with 2.8. The screen above simply shows that. That public builds of the snapshot stopped because it's no time to test them while being unstable is no proof for your "it's dead" circle. And there were multiple patches and fixes for 2.7.2 afterwards via system patches. Simply repeating stuff over and over doesn't make it more true 🤷

@Patch said in Opensource 2.8 Dead...:

I do not doubt Netgate only focus on the close source software branch now. Describing the CE as a split off from Plus is not really what Redmine shows

It's exactly what they outlined in their blog about Plus as it was introduced. In the past the so-called factory edition (the Plus before there was the new naming) already existed but was dependend on CE being ready, then after it being ready and frozen it could then be fork/merged over to the FE branch and the custom things from the factory edition could be integrated. That intention was changed with Plus and communicated. With faster release cycles, now Plus is the "main" release and CE gets forked when plus is in a specific and stable state and without the additional plus-thingies. If they wouldn't work on a CE anymore you couldn't up/downgrade cleanly between Plus & CE, a thing they just introduced last year and would be stupid to drop already as it's in their own intent to keep that ability. That's why we already had two? three? joint-releases where Plus and CE followed after each other to have the same config revision and allow easy up/downgrades as needed.

And merging changes from a branch brings merge conflicts to resolve etc. that's just normal so you don't make that even more complicated by actually doing things twice or thrice if you don't have to. So the simples thing is: be done with one release and branch (plus) so the second one (CE) can be merged over, conflicts solved, then you have a state that is actually testable and won't just break by incompatible changes from OS updates, PHP updates etc etc. Simple development logic.

Cheers

@Viper_Rus said in When will the CE 2.8.0 Development Snapshot be available?:

I'll wait for the CE 2.8 snapshot ;)

Have CE as snapshot again would be awesome!