Don't upgrade to x86 CE build 2.4.0.r.20171008.0625
-
I'll try to give as much information as possible:
Box before the upgrade attempt:
Mini-ITX System based on an ASUS N3150-C with an Intel 82571EB 4 port NIC (em driver) and 64GB SSD.
Onboard Realtek Ethernet Controller disabled in BIOS.
It was running the last 2.4RC build from yesterday (07.10.2017) using ZFS as filesystem.
Note: I was originally running 2.4.1 and reverted back to 2.4.0, when it moved to FreeBSD 11.1, recovering the config during the install.Installed Packages iperf (server not active), bandwidthd and cron.
em0 configured as LAN with a static IPv4 on 192.168.2.1/24 and the IPv6 from HE.net tunnel.
em1 confgured as OPT with a static IPv4 on 192.168.1.1/24 to access the WebUI of the DSL modem.
WAN configured as PPPoE on em1, get's a dynamic IPv4 address.I started the upgrade using the WebUI, like always, it downloaded the packages and rebootet. Booting took quite a bit longer than usual, after it was finished neither the box nor the WAN was reachable.
I attached a Monitor to the box and normal output should be like this:
WAN (wan) -> pppoe0 -> v4/PPPoE: x.x.x.x Lan (lan) -> em0 -> v4: 192.168.2.1/24 v6: x:x:x:x::x/64 MODEM_ACCESS (opt1) -> em1 -> v4: 192.168.1.2/24 and the HE.NET Tunnel
instead it was this:
WAN (wan) -> pppoe0 -> Lan (lan) -> em0 -> v6: x:x:x:x::x/64 MODEM_ACCESS (opt1) -> em1 -> and the HE.NET Tunnel
I attached a keyboard and used option 2 to give LAN a new IPv4 address, the process run without displaying any errors but LAN was still without an IPv4 address afterwards. I rebooted for good measure but that didn't change a thing.
After that I used option 4 to reset pfSense to factory defaults, this run through without an error and after the reboot this was displayed for the interfaces:WAN (wan) -> em0 -> Lan (lan) -> em1 ->
I tried to reassign the interfaces and manually add an IPv4 address to the LAN, but it still didn't work. So I reinstalled an older build and go the box working again.
-
Same here, BUT if helps to solve i had several IP alias in LAN and they were asigned to LAN and worked to connect.
Then deleted them and unable to configure the IP.
Also in WAN i have static IP and even i configure it, it is not used (in console, IP (WAN and LAN) are blank (in Web cfg (when accessed with one of those aliases) appeared as configured)
Also when configuring in console appears an error about "renaming interfaces", i'll try to take a photo.
Downloading 20171006-1536 to reinstall if no solution given.
-
I blew it away (testing VM), and did a fresh install of today's build, and so far everything seems good.
Did you restore you previous config or did you reconfigure by hand?
Are you using the traffic shaper, and if yes do the queues show up in Status -> Queues?
-
Sorry, the error about renaming was when booting, not when configuring IP, attached 2 pictures, one with the renaming error when booting and other after configure LAN IP in console and IPs of interfaces are blank.
-
I blew it away (testing VM), and did a fresh install of today's build, and so far everything seems good.
Did you restore you previous config or did you reconfigure by hand?
Are you using the traffic shaper, and if yes do the queues show up in Status -> Queues?
No, I did everything from scratch again (only installed about 9:00pm EDT). I didn't have the shaper setup, I did have a few packages (ACME, FRR, Snort, PFBlockerNG), and I believe I went through the real basic setup of Snort and PFBlockerNG. But other than that it was pretty much stock/not configured.
I still have the ISOs from yesterday and I can do some testing to see if I can reproduce it and grab some more screen shots.
Edit: So far I reinstalled with yesterday's build, but it isn't finding anything yet for an update. I'll leave it be for a bit and see what happens.
-
I tried to configure the IPs from shell (console) and default GW and got some connectivity
So:
ifconfig re0 WANIP/Mask
ifconfig rl0 LANIP/Mask
route add default MI_ISP_GW_IPGave me some connectivity, i can ping to the Internet (ie: 8.8.8.8 ) BUT no DNS (even configured in Web manager, i had to configure the GW for DNS again)
Now restoring a config over this build (i did a backup yesterday night! ::) ) and will report if solves something
-
This is superborked and not being able to see the relevant commits on Redmine/GitHub once again does not help here.
-
See the other thread: https://forum.pfsense.org/index.php?topic=137672.msg752884#msg752884
It's been pulled.
-
We're working on a fix right now. A change went in that appears to have broken older package binaries (even base system package binaries) with a newer kernel/world. Once we get a new full pkg set built and tested we'll get a fix out.
In the meantime, installing a current snapshot fresh will work since it all matches. Reinstalling and using the "recover config.xml" option will have you back up with less effort than other solutions.
We have taken the broken package sets down so people can't accidentally upgrade to a broken snapshot.
-
We have taken the broken package sets down so people can't accidentally upgrade to a broken snapshot.
for some reason I am unable to get to the repository after going to previous snapshot. Is there anyway I can quickly install freeradius package so I get wifi working atleast?
-
The repos are down apparently ATM.
-
-
Yes, my pfSense box got hosed as well. I can't complete my restore since the pkg libraries are down.
Can we restore the latest packages that worked for 2.4.0 while the devs fix the package set?
-
Yes, my pfSense box got hosed as well. I can't complete my restore since the pkg libraries are down.
Can we restore the latest packages that worked for 2.4.0 while the devs fix the package set?
Yes please restore the packages
edit:
it seems they added .BAD to the end of the repos.
https://firmware.netgate.com/pkg/pfSense_factory-v2_4_0_amd64-core.BAD
https://firmware.netgate.com/pkg/pfSense_factory-v2_4_0_amd64-pfSense_factory-v2_4_0.BADCan someone test this /usr/local/etc/pkg/repos/pfSense.conf file?
FreeBSD: { enabled: no } pfSense-core: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_0_amd64-core.BAD", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes } pfSense: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_0_amd64-pfSense_v2_4_0.BAD", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes }
edit 2: works!
-
I think they are marked BAD for a reason ::)
-
@marjohn56:
I think they are marked BAD for a reason ::)
I agree ::)
Could that situation also lead to failing package reinstallation after a fresh install?
I did a fresh install of a RC-snapshot from Oct, 3rd or so (just chose a random one, updates later) and restored my backup xml to it.
Currently it is not able to display available packages or install the packages listed in the XML.
No big deal right now, just reporting and asking to learn things. -
Most likely yes.
Best to leave alone until the repo is back up. If you have killed your system then I would rebuild from one of the downloads that are still available. You may not have packages, but at least you'll get a basic working system, however each to their own.
-
@marjohn56:
Most likely yes.
Best to leave alone until the repo is back up. If you have killed your system then I would rebuild from one of the downloads that are still available. You may not have packages, but at least you'll get a basic working system, however each to their own.
Box is up and running, no urgent need for the packages. Thanks.
-
i wish i had read this Friday night before i installed this on my sg2220…
i learned quickly how to console into my box which i never had to do before.
really my main complaint is this. i had made a backup under diagnostics > backup and restore > backup and restore a few months ago to an XML file. when i tried to restore it after i put 2.34 p1 back on i received this :
a full configuration restore was selected but a pfsense tag could not be located. what exactly does that mean?
another sad note, i am running the community version on what i believe is an older version of BSD version 10. is that correct?
-
On 2.3.4 Yes. 11.0 is 2.4.0 ( or was/is/maybe ) 11.1 is 2.4.1 ( or was/is/maybe ). It's all a bit variable at the moment depending on how you are leaning.
-
The current release version of pfSense,2.3.4_1, is built on FreeBSD 10.3.
2.4 snapshots were previously built on FreeBSD 11 but moved to 11.1 when we had to delay release to pull in patches for newly discovered issues.
That applies to factory and CE versions.
https://doc.pfsense.org/index.php/Versions_of_pfSense_and_FreeBSD
If you upgraded to a bad snap and found the result unusable you have a few choices.
You can wait until we get the repos back up after testing the fix we put in which should be very soon. If your firewall still has WAN connectivity you can upgrade from there.
You can restore a 2.4 snap from Oct6th or earlier but because the repos are down you will not be able to install and packages.
You can restore a 2.3.4 image, the repos for 2.3.4 are unaffected so packages will be installed but any config file you restore must be from 2.3.4 or earlier. If you restore a config from 2.4 you may see that sort of error where 2.3.4 does recognise tags in a 2.4 config file. Not everything has changed though.
Steve
-
@marjohn56:
I think they are marked BAD for a reason ::)
I plan on fresh install and restore from old config.xml as soon as repos are up.
-
In this next sentence I say Something witty in Klingon about ZFS boot environments in pfSense 2.4+ as a mitigating factor for contingencies such as this:
"ZFS nIvbogh be'vam SUPERBORK SeH 'oH alows SoH ghaH nom RECOVER."
That was one really nice thing about Nano.
-
In this next sentence I say Something witty in Klingon …..
Nice. ;D
_That is always the safest way. And with the config recovery in 2.4 should be fast.
Internal testing of the new pkgs is looking good.
Steve_
-
In this next sentence I say Something witty in Klingon about ZFS boot environments in pfSense 2.4+ as a mitigating factor for contingencies such as this:
"ZFS nIvbogh be'vam SUPERBORK SeH 'oH alows SoH ghaH nom RECOVER."
That was one really nice thing about Nano.
Will be a snapshots a thing in pfSense? Wold be great a auto snapshot before upgrade option, maybe. Config recovery do the job beautifully.
-
@mais_um:
Will be a snapshots a thing in pfSense? Wold be great a auto snapshot before upgrade option, maybe. Config recovery do the job beautifully.
It's a ZFS thing, and ZFS is now an install option in pfSense 2.4.
AFAIK, you can't recover from ZFS snapshots in pfSense just yet. I'm not sure where that is on the road-map, but if I were King/President/Jesus, I'd make it a high priority.
I've been anticipating ZFS in pfSense for years and am still giddy when I think about a ZPool vDEV made of 2 flash DOMs. https://twitter.com/karlfife/status/878833005426561024
FreeNAS has been doing GUI-integrated ZFS boot environments for a while, and the feature has saved my bacon more than once (especially in remote installs without remote technical hands). As long as the system comes back up after an update/upgrade, you can pick a boot snapshot (via GUI/SSH–no IPMI needed).
Yes, snapshots are auto-generated at time of update, and (of course) they each contain a private copy of the config (e.g. usable, non-migrated).
-
I just applied the newly available 10/9 build. It seems to have fixed my broken install.
That is, my 2.4 remote instance was non-functional, notably had a DHCP server that wouldn't start, but the borked instance retained WAN connectivity. Just now, it called home to the update servers, which pushed the 10/9 build, then rebooted, bringing the network back to the land of the living. Nice work gentlemen.
-
Too late, totally messed me up. Took about 4 hours to figure out what happened and get things fixed and going again. :(
-
Installed the latest update. Seems okay so far.
-
But dhcpd v4 not working:
Oct 10 06:21:15 dhcpd Can't attach interface bridge0 to bpf device /dev/bpf0: Invalid argument
-
But dhcpd v4 not working:
Oct 10 06:21:15 dhcpd Can't attach interface bridge0 to bpf device /dev/bpf0: Invalid argument
I'm not seeing that error or any other malfunction of dhcpd.
-
Manual upgrade "pkg upgrade -f isc-dhcp43-server-4.3.6_1" and clean chroot env. /var/dhcpd resolve it.
-
Fresh install of the new version and restore from old config.xml has fixed everything.
-
Did a fresh install and restored my old config and its all working fine now.
-
Manual upgrade "pkg upgrade -f isc-dhcp43-server-4.3.6_1" and clean chroot env. /var/dhcpd resolve it.
That did the trick for me as well.
For developers, I know it's hard to keep up with the changes but this is a case where you could improve greatly. It should not be possible to upgrade your system and be left with an old version of a chroot environment that has the wrong device nodes or other files, every upgrade should clean up expendable content so that the services are started with a clean slate after an upgrade.Edit: I realize now that the real problem was a bad dhcpd binary and the package system didn't include an updated dhcpd package, it actually did but since the version number hadn't changed pkg didn't offer it as an update and the only way to get the fixed dhcpd package was to use pkg install/upgrade -f.
You could investigate a possiblity of including a build number into your package version numbers. It's not afaik supported directly by poudriere which assumes that the version numbers are what's in the ports tree and nothing else. A build number would solve a lot of problems similar to this and enable a forced reinstall of all packages regarless of what the version numbers are in the ports tree.
-
Installed the latest update. Seems okay so far.
Logos', my pfSense logos' are screwed up on both my units, not critical but visually obvious. :)
-
Erm… I have a strong feeling that the pre-kaboom snapshots should be taken, released as 2.4.0 and this insane messing should be moved to 2.4.1. WTH is anyone doing changes like this days before release, after months and months of beta testing.
-
Erm… I have a strong feeling that the pre-kaboom snapshots should be taken, released as 2.4.0 and this insane messing should be moved to 2.4.1. WTH is anyone doing changes like this days before release, after months and months of beta testing.
-
@marjohn56:
Installed the latest update. Seems okay so far.
Logos', my pfSense logos' are screwed up on both my units, not critical but visually obvious. :)
Refresh browser cache, fixed the broken logo for me.
-
@marjohn56:
Installed the latest update. Seems okay so far.
Logos', my pfSense logos' are screwed up on both my units, not critical but visually obvious. :)
Refresh browser cache, fixed the broken logo for me.
Yup.. I'll go sit in the corner with my dunces hat on… :-[