You don't need a support subscription for a re-install image. Just open a ticket: https://go.netgate.com/ Re-installing is what I would recommend from there. It cannot access a dtb file so the upgrade must have been incomplete. Steve

@gertjan yeah, Brother is a Dev Op i think the name he gave me lol. Not that high up myself but he brags about pfsense and his machine. I started with a 2100 for a small office and I need a second office up. Did not had this issues with my first one but this one.. i see is going to make me learn. An eye opener for sure, like you said -> Definetly will be ready for any future problems. Thank for reply

@jimp Ah ok thank you. That makes sense than.

@cli-networks said in Upgrade 2.4.4 to 2.5.2 using USB: I was able to upgrade the firewall last night without issues. What was the issue ?

@bingo600 thanks Bingo. So it appears the issue is, the pfSense-CE-2.5.2-RELEASE-amd64.iso.gz file is automatically uncompressed when downloading on a Mac. I just see the ISO and had not noticed the filename during the download (which was as per your reply, pfSense-CE-2.5.2-RELEASE-amd64.iso.gz. I can simply burn the ISO - too easy. Thanks for taking the time to reply, it's much appreciated!

@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.