PCEngines APU2/APU3/APU4 running on 20.7

[Ricardo]

I have 2 APU2C4 running here, both on coreboot v4.0.30. No issues so far

You are running
1) legacy 4.0.x BIOS versus the mainline 4.10+ BIOS, and
2) you are behind the latest (4.0.32 is the latest, contains watchdog and PCIE addressing issues)

[dave]

Sorry to hijack this thread, but what does the watchdog feature actually do?

[hirschferkel]

Actually all problems with

https://forum.opnsense.org/index.php?topic=7645.msg34941#msg34941

Code Select Expand

kernel       ath0: stuck beacon; resetting (bmiss count 4)

Are gone, now. So it was actually a software problem of OPNsense.

https://forum.opnsense.org/index.php?topic=13792.msg64395#msg64395

Code Select Expand

Aug 26 00:33:29 kernel: pflog0: promiscuous mode enabled
Aug 26 00:33:29 kernel: pflog0: promiscuous mode disabled
Aug 26 00:32:32 kernel: pflog0: promiscuous mode enabled

These problems are history, too... without changing anything in settings.

[Ricardo]

Updated today to 20.7.2
Sofar it seems I hit the syslog-ng defect, its unable to start, triggering manually results in service coredump. Hence no logs are available under System \ Logging :(
Would be worthy to mentio  in the release notes before people push the update button carelessly.

[franco]

Sure, syslog-ng dlsym() crash was fixed. If you see another one just put in a qualified report and we shall solve it. That said, we expect you ran the workarounds other people shared already?

Judging from your other activity you have a lot of problems with OPNsense in general?


Cheers,
Franco

[Ricardo]

Sure, syslog-ng dlsym() crash was fixed. If you see another one just put in a qualified report and we shall solve it. That said, we expect you ran the workarounds other people shared already?

Judging from your other activity you have a lot of problems with OPNsense in general?


Cheers,
Franco

I was upgrading from 20.1.9 to 20.7.2, and saw the release notes said something about a resolved syslog-ng crash that I wasnt aware . As I did not look for it specifically: if that was fixed among otber fixed things, I did not check each of them whether any of them may still be unfixed. The release notes doesnt have known issues section, so I dont know what to expect. So if you say there is something wrong with syslong-ng on 20.7, then it seems I need to investigate. Adding a "known issues" section to release announcements could improve the experience for upgrades. You can call it "afterupdate-things-to-be-aware" if you dont like to call problematic things as "Known issues". But something should be there to make people aware, that not everything is perfectly working
On twitter I saw explicitly mentioning @opnsense that there are no major upgrade issues with 20.7. Having syslog-ng break just after upgrade is still suspicious for me. At least now I know I have to look after this. Maybe I have some new syslogng problem, maybe its the same as others had.

[jassonmc]

I agree with Ricardo.
There should be a "known issues" section with update infos.
I also ran into the syslog-ng issue, just to find out it was known, but nobody actually cared to tell others, that this happening.

How about a dynamic update info when pressing the update button, that contains that "known issue" section?

Knowingly letting people run into an issue that's known and hoping for them to find a solution on the forums seems to be quite a poor solution...

Cheers
Juri

[franco]

Yes, poor, average, convenient, appropriate, cost effective, free, limited liability, limited warranty. It is all the same.

Since you two agree now you only have to agree which one of you curates that list. ;)

In general there is a bug tracker that tracks open bugs: https://github.com/opnsense/core/issues?q=is%3Aopen+is%3Aissue+milestone%3A21.1+label%3Abug

We fixed 2 syslog-ng issues, if you see a third I'm still happily awaiting your detailed report.


Cheers,
Franco

[jassonmc]

@Franco
That was no offence, just a feedback  :)

I am quite new to OPNsense and would be willing to assist in curating that info, but am not sure if I'm ready for it, since I'm an OPNsense user only since a few weeks.

But back to the point: I think it would be already of great help, if near the top of the update notice, a sticky note says: IMPORTANT: Please consult open bugs list, prior to updating.

There should be a link to github bug tracker.

That what probably already suffice, what do you think?

[franco]

I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)

And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.

We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.

Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.

A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.

All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.

I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.

To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.


Cheers,
Franco

[Ricardo]

I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)

And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.

We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.

Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.

A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.

All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.

I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.

To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.


Cheers,
Franco

@jassonmc: Welcome to the opensense community :D

[franco]

I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)

And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.

We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.

Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.

A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.

All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.

I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.

To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.


Cheers,
Franco

@jassonmc: Welcome to the opensense community :D

Very in-depth, thoughtful and helpful comeback.  ¯\_(ツ)_/¯

[rheller]

I have an old APU1 up and running. Had some incident during the upgrade (it only upgraded base/kernel and not the rest), but with some help in another topic here (Thanks, Franco), that could be easily fixed.

Regards,
Ralph

[Ricardo]

I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)

And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.

We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.

Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.

A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.

All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.

I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.

To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.


Cheers,
Franco

@jassonmc: Welcome to the opensense community :D

Very in-depth, thoughtful and helpful comeback.  ¯\_(ツ)_/¯

I have to admit, that one wasnt my most helpful and constructive post. But sometimes it gets effective, though..

Anyway, to be ontopic:
would be really useful, if there was a page, dedicated to main releases e.g. one for 20.7, a separate one for 21.1, another one for 21.7 and so on, that tracks the most serious / showstopper upgrade-related bugs in that release branch. A simple table, nothing fancy. That describes what is the issue (e.g. Syslog-ng fails after upgrade to 20.7.0), when inside that release branch it was introduced (e.g upgrade from 20.1.x to 20.7.0), how to workaround (e.g. run from CLI: kill syslog-ng), when it was fixed (e.g. upgrade to 20.7.1). And you put a link to the release notes, that says: for any late-breaking upgrade info, check this known issues.

[l8gravely]

Just to chime in here, I'm running 20.7.4 (just updated to it last night) on an APU2 and it's working ok.  In in the USA and have Charter/Spectrum for my WAN and it keeps dropping randomly at times.  I usually have to go into the web GUI and renew the GW lease.  I haven't been able to figure out what's going on here.

I've got the 4gb RAM APU2 with three GigE ports, no Wifi at all, it's just a router and that's it.  I'm using a 64Gb mSATA SSD as my boot device, but I've only got 32gb partitioned and even less in use.  I figure that's a great way to keep up longevity as the wear leveling should keep things going nicely.

I syslog to my main home machine, and I still don't see messages in the logs when the gateway goes down.

Any suggestions on how to debug this better?  Can I reset the WAN DHCP from the console so I can watch for errors?  It's driving me nuts since a reboot tends to fix up the problem right away.

This system has been ugpraded from older releases, so maybe I really need to do a fresh 20.7.4 install on a wiped system.  Should I try to save off the config and restore it?  Or should I just re-enter all my local firewall rules (just a couple for NAT'ing some devices on the inside) and local DNS entries?  It would be nice if there was a way to export/import a list of entries all at once. 

John