@o51 @Gertjan Comparing pfsense, which is a networking solution, to Windows or MacOS is not correct. I built for the last 30 years networking devices using Linux as the base OS and they always restarted regardless of how bad the previous shutdown was (unless a real hardware failure occurred). And that is what the expectation should be; a network device (and for that matter any embedded device) are expected to survive any soft failure (including cutting the power cord abruptly) including during upgrade. I have 10 or more VMs here. And also various physical servers. After a bad power outage they all went back online, as they should, except for the 4 pfsense VM that I use as routers. The 4 of them died in the same fashion; filesystem corruption. Luckily, I was able to retrieve the latest config.xml and redo the 4 installations from scratch. Not fun, I lost 1/2 day. And not expected for something like pfsense. The only way to make device, like routers, resilient is to have the main filesystem read-only (like squashfs or equivalent), get everything that is disposable (log, etc.) into a ram disk or alternate read-write filesystem (which would be reconstructed at boot time if necessary) and everything that you must not lose in yet another filesystem and have multiple copies. Overlays file system make all this painless. The beauty with pfsense is that everything is in 1 file. Super easy. (I presume there is a fail save mechanism when writing the XML file). IIUC, nano was not exactly that but it is a pity that it was cancelled rather than evolved toward a real networking resilient software stack.

I think we are talking past each other on the base of my poor explanations ;-) I could solve the problem already ... but I cannot understand it: The main problem was that the remote DNS servers have denied dns recursion queries from the pfsense WAN interface. The recursion queries where already allowed for the pfsense OPTDMZ interface. The solution was to allow the recursion from the pfsense WAN interface. So my question was, why this was suddenly necessary without config change. Before all dns queries are coming from the OPTDMZ interface. dig @194.XXX.YYY.ZZZ google.com => no recursion allowed, because SOURCE IP is pfsense WAN => Before SOURCE IP for DNS queries was 194.XXX.YYY.1 (OPTDMZ pfsense) There @gertjan said in [Upgrade not possible from 2.5.0 to 2.5.2. Netgate So you have something like nameserver 194.XXX.YYY.ZZZ yes There must be some info in the routing table that mentions : 194.XXX.YYY.ZZZ is on 'this' (OPTDMZ) interface. All the other addresses are reachable on the 'other' (WAN) interface. In the route table Again, in my opinion there is no routing and the default Gateway is not used if the DNS-Server is located in an internal network which is directly attached to the firewall, in my case OPTDMZ. In the route table there is an entry that all traffic goes to a device ... Destination Gateway Flags Netif 194.XXX.YYY.0/24 link#11 U lagg1 I think we are fine ;-)

You should be able to restore a config file from an older version onto a newer version. There are several upgrade notes.

Solved! My motherboard was set for the sata controller to emulate IDE and had no AHCI mode. Fortunately I can set the mode to RAID and that appears to work just fine when I did a BIOS mode install.

@gjaltemba The stuck up fetch finally timed out overnight and I was able to complete the update. Would be nice if there was a fast track the update when it is stuck fetching.

@stljonny said in PfSense 2.4.5 to 2.5x (StatusUp to date): Did you ever fix this issue, as I am having the same problem. [image: 1625976028994-cb304992-13dc-446f-aef4-0b23be330d58-image.png] I have went through the link mentioned by jimp (above), yet it does not resolve things at all. Is a reinstall the only way to resolve this? Played around with System -> Update (in the GUI) and the Branch setting, and suddenly things are working properly now. Not sure why, but I guess the issue resolved itself.

It seems thats the problem - it does not like samsung sticks. Switched to ALOT slower Kingston ones and it works and boots every time. I even cloned the kingston ones to samsung thinking that it's the uefi or some other things that is broken. It just boots from cold boot once and after reboots usb is not working and not booting. Sad thing is kingston ones are so slow for the same money and don't know how pricey i have to go to get decent performance out of them.

Unfortunately I am back on this issue when updating another firewall in that offline network. Rebooting the firewall after the update did not help to fix the issue this time. Trying to debug this further I tried to call fetch manually: [2.5.1-RELEASE][admin@...]/root: fetch -v http://10.x.x.x/pfsense/pfSense_v2_5_1_amd64-core/packagesite.txz resolving server address: 10.x.x.x:80 requesting http://10.x.x.x/pfsense/pfSense_v2_5_1_amd64-core/packagesite.txz It just hangs, same as when I call pkg-static update manually. But if I do the same fetch on meta.conf it loads perfectly fine: [2.5.1-RELEASE][admin@...]/root: fetch -v http://10.x.x.x/pfsense/pfSense_v2_5_1_amd64-core/meta.conf resolving server address: 10.x.x.x:80 requesting http://10.x.x.x/pfsense/pfSense_v2_5_1_amd64-core/meta.conf remote size / mtime: 163 / 1618334907 meta.conf 163 B 449 kBps 00s

@steveits yes, i assumed that. I keep my setup on the latest stable releases of pfsense and packages, so that's not an issue. I'd make sure all were on the latest before doing the config backup and restore. this is good! saves me a TON of time... Thanks!

I don't have any 5100's, but every single 3100 I have (I think 14 online at the moment) has bricked on pfSense+ major and minor updates, plus major rule rewrites were required after restore on the initial pfSense+ update for several.

@vmb said in No packages after restore: So, if you are reading this and you prefer to only use the stable releases, thank you for supporting pfSense and giving it the good reputation it has. It is difficult to argue with this, as there are two sides to the coin. (Natgate will not let such a grossly inoperable version out of its hands - Okay - good, 2.5.0, we also avoided it, far away) But thank you for sharing your opinion with us. About old ISO images and offline installation: Otherwise, you can simply not delete the old_pfs_x_y_z.iso (of course whatever is current at the time) from the pendrive (or etc.) and save it to the deepest folders of your NAS and install it offline, whenever you feel like it. BTW: and you don't have to claim this from Netgate

@mpetts1 @gertjan Solved this in the end. Removed the WAN Gateway and re-added. Same info as before, just works this time! Thank you for your help.

Send email to support.. They will help you out. No support contract needed for images for netgate hardware I have a sg-4860 desktop model, and get new image every time new one comes out. To have on hand.

Ok, so you have both outbound policy routing and a port forward in the other direction. So the IPSec tunnel can establish in either direction. Which way does it actually establish? Both? Is it failing to establish at all in 2.5.2? I would not expect to require both those. Certainly the tunnel will only use one to create the states though it could use either if it's a site to site tunnel. If it's actually blocking traffic what do the firewall logs look like? What rule is blocking? Check the state table. Do you see states on the wrong interfaces? Steve

If you previously had a geom mirror on there you probably have to destroy it first. But disable the hardware raid stuff first.

@mer The only reason I suggested this was I ran into a similar issue a few weeks ago on an SG-2100 and I've also seen it reported for the SG-1100. I don't know if it's an aarch64 specific issue or not.

So I'm upgrading again today from 21.02 to 21.05 and I'm having this issue again. I'm actually pretty confident this has happened every time I upgrade this box from the GUI. Has there really been no one else having this issue?