The installer will delete any existing partitions. The only time I'm aware of that it won't do that is if you have an existing geom mirror defined. It will install into that instead. If you use the default options you should never see the above error. You would only see that if you removed the default configured root partition and do not add another one. You might hit that if, for example, you remove the swap partition and want to re-create root to fill the space. Steve

@bmeeks Thank you very much.

@wn As KOM says open a ticket. You should get free support as it's a Netgate device. ("zero to ping")

OK, closing out this thread and linking it to another. The root cause of the problem I reported is that on the MBT board, the ZFS module combined with the i915 HDMI module exhausts the available EFI staging area. I don't fully understand the details, but thanks to help from @stephenw10 the solution is relatively simple: just reinstall pfSense and use UFS for the file system rather than ZFS. I have confirmed this works with CE 2.5.1. If you want to see additional details, this thread has more information. So glad that this issue can finally be put to bed!

I ran a number of APU2 devices on ZFS. The memstick method was successful but slow, so I created my own dd image (via ubuntu live disk). and then used Etcher to create new SD Cards in order build the rest of the APU2 devices.

For anyone finding this in future, I am glad to report that my router upgrades were successful (thank you pfSense team and contributors). I did have to go from 2.4.4_3 to 2.4.5_1 first (on both the 7100 and the 3100). After the upgrade, I did not touch any of the plugins, changed the update branch to latest and rebooted again (just to be sure). Then I was able to go from 2.4.5_1 straight to 21.05 and it even then upgraded all the plugins to the latest for me. It did take me several hours because I had two routers to do, I had CARP failover and IPSec tunnels and I waited to make sure none of my alerting systems went crazy. But the actual upgrade process was suprisingly and refreshingly straight forward without any drama.

I wouldn't expect you to have to run an upgrade more than once. It may have updated the pkg repo itself and then found newer packages. It should have just done that without requiring any interaction though. When it says The process will require 4 MiB more space. that just means the updated packages will be 4MB larger than before the update. That's expected and not filesystem space issue. Steve

@stephenw10 Thanks this was what I was looking for.

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.