We did not try removing package prior to upgrade. Thank you for checking scripts.

I think it's better to go https://forum.pfsense.org/index.php?topic=43574.585 and post your question again, just linking this topic, may be somebody can help you.

Sounds like a bits vs bytes difference.?. both can be correct but do differ by a factor 8.

pfSense on the SG-1000 has been beta since the device was released.  2.4 is the first release to support it.

We used to fudge the update message on older repos to find the newer version numbers directly, but that had some unintended side effects. tl;dr is that if you run the update anyhow it'll update to 2.3.4-p1 even though it only "sees" 2.3.3_1 as the "latest". To be extra certain, run the upgrade from the console or ssh.

Well after all that….. It turned out that it was in fact the new network cable from the servers NIC2 port to the switch. I changed the cable for another new cable and hey presto all singing all dancing  :) Incidentally i'm struggling to get services through the firewall and after following numerous tutorials i'm still non the wiser but that's a different issue. Thanks for your help.

no guide. you can find bits an pieces around the forum if you look for it. chances are very small you'll get a build working for a random arm device, but do keep us updated :)

Is it set to BIOS or UEFI?  PFsense doesn't do UEFI yet, so you have to use BIOS (Or legacy or what ever Dell call it)

@b00rishev: The issue is getting IP addresses allocated to the WAN and LAN NICs. I either get one or the other. Sounds like you got the scope wrong and connected both LAN and WAN to your switch. Do it this way: Zyxel –- pfSense WAN | pfSense LAN --- SWITCH --- computers, printers, APs, etc. Only WAN gets an IP from the Zyxel (as long as that one is not in bridged mode). Set IP for LAN manually. Must be different from IP-on-WAN settings, completely different subnet. pfSense is a router. It can only route between different networks. Otherwise it would be a bridge/switch.

Update: After a reboot the update completed. Seems the swap partition filled up… Regards, Joachim

DNS issue… It s working now...

If your WAN1 gateway is down hard for the duration, I would just make the WAN2 gateway the default gateway until WAN1 is back up. Any of these remarkable checkboxes checked on either of your gateways?  

Yeah it can do some strange things since the terminal type doesn't match exactly. It installs fine regardless. FWIW I am having much better luck selecting vt100 in the new installer on 2.4 (in beta) using kermit on a mac..

Sam, The below threads may be a different issue but several people couldn't upgrade directly to 2.3.4_1…it kept trying to download 2.3.4 which was no longer on the web site.  The "fix" process might work to get yours looking at the right version. https://forum.pfsense.org/index.php?topic=125873.msg695386#msg695386 ref. from https://forum.pfsense.org/index.php?topic=134042.msg736575

Are you sure that you have properly set your Proliant UEFI options (ex. "any linux" is activated, even if it's not linux at all ) ? Do you have the same Proliant model and the latest UEFI BIOS is installed?

Just affirming phil's instructions that you can edit the interface names fairly easily in the .xml config file; I just did my last soekris->sg-xxx upgrade and this time instead of going the console method I just saved (backup) the prior configuration, edited the xml file to change the <if>blah</if> entries as appropriate, then restored from that modified configuration onto the new hardware. Worked fine. I would resist the temptation to change anything else that you don't need to change "while you are there". I started to reorganize my choice of opt1 vs opt2 etc and quickly realized that had many other implications (e.g., rules); so of course I reverted all that and started over with discipline to just update for the emX -> igbX changes. Which method (console vs edit the xml file) you prefer seems to be a matter of preference; both are pretty simple.

There has been a lot of discussion about this but I don't see any advantage in using PCI passthrough. VMware have their view of course and you can take that whatever way you want  ;)