@bingo600 thank you, it was zabbix. I removed Zabbix package only, then performed the upgrade without any problem and reinstalled Zabbix (I confirm that settings are remembered). thank you

@solution said in Downgrade 2.7-dev to 2.6: I would like to avoid reinstallation as it is in production at a remote location. I don't use dev in production but when the intern heard "upgrade" he selected 2.7. If anyone has already successfully downgraded please share it with us. Thank you very much. translation using google translate Do NOT attempt a downgrade. That is highly likely to go badly at this point since the 2.7 DEVELOPMENT tree code is now a bit different from the 2.6.0 production code. Maybe on the same day or the next day after 2.6.0 was released a downgrade might have been fine, but not at this point in the cycle. So obtain a current config backup and do the full reinstall. Unless you trust your intern at the site, sounds like a road trip is in your near future .

@gertjan Sorry, that was a typo. It's about reboot, not shutdown. AFAIK, at the end of install, when it asks about "reboot", that's what it intends to do. The reboot does not complete. Instead it gets as far as I showed, and stops. I had to manually finish. UPDATE: I have found it never reboots. Separate topic...

@taylor_wright2022 If the ticket's result was to get you the firmware image it is related to the process of fixing your other issue. If you did not get the firmware image from that ticket but are using an older image (not 22.01 or 21.05.2) please open a new ticket.

Never mind. Followed this: https://forum.netgate.com/topic/170151/update-error-another-instance-is-already-running-aborting/4?_=1646339942879 and I'm good.

If you define the proxy settings in the GUI (System > Advanced, Misc tab) it should work, though if you are testing from the CLI you need to log out and back into the console or SSH shell after changing the settings in the GUI. Updates use pkg which uses libfetch which relies on the proxy being set in environment variables, not like cURL. The variables are set dynamically by the scripts which get run when a shell is started, they don't update after that. The update check in the GUI should work so long as the proxy is properly defined in the settings as well.

@d3messiah https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#packages-netgate-com-has-no-a-aaaa-record

@karlfife My point was it’s actually a lot worse (theoretically) than your suggested penalty, but that very fact, may also mean that the wear the current page size brings, might not be much smaller with smaller page sizes - because the block erase penaly could still be triggered on almost the same scale.

Since the recovery process is relatively straightforward, I can attempt it again. Is there anything else you'd like me to gather to aid in diagnosis?

There have not been any changes in this regard.

@steveits That is good information to have. Sounds like I got lucky then on the power cycle not bricking it…

@jimp Worked for me thank you

If IPv6 is a factor, that's easy to change as well. System > Advanced, Networking tab, check Prefer IPv4 over IPv6, then save and try again.

@micma_ That's how it should work - unless you do something to your system that changes the NDI.

@helloha If you have tow instances "pkg-static" running. "pfSense-upgrade" uses "pkg-static". So, again, if they seem to 'do not', kill them. kill 14712 kill 14819 And try again. Btw : do a local resolver test like dig google.com +short You should get back an IPv4.

@markgca What does the system log say about those OpenVPN gateways? The 20 minute reboot indicates to me that it's hanging on something to do with interfaces. What have you found from plugging into the console port during a reboot cycle?

The -d switch there only enables debugging output. It shouldn't make any difference in itself. But I'm glad you were able to get past that anyway. Steve

@mururoa said in System update failed !: It is a know bug https://redmine.pfsense.org/issues/12796