Help - I need 2.4.4. p2 image for amd64
-
I have come unstuck upgrading with the 2.4.4.p3 image for both SG-1100 and amd64.
I still have a 2.4.4 p2 image for the SG-1100 but I need a p2 image for the amd64Since upgrading to p3 I reach a doppelgänger state in approx 36/48 hrs where the firewall is still passing traffic but the web interface will no longer answer and the console is similarly stuck. The similarities between the amd64 and Marvell products are striking.
As I write this the amd64 is in charge and providing internet access but is completely schtum on both console and and webconfig interfaces. To try and recover I did an NMI reboot and captured a couple of console pics as it rebooted, taking a long time.
It seems to have trouble with memory allocation and file system full. Not likely! It has 4Gb RAM and new 128Gb SSD for installation Thursday. I watched it for a while after installation of p3 and it said approx 23% RAM used and 1% disc.Can you please tell me where I can get a 2.4.4 p2 image for amd64. I cant find it now.!
eventually it says the boot is complete and prints the Freebsd/amd64 ..... but never provides the console choice menu.
-
There is no CE 2.4.4-p2 Image.
https://frafiles.pfsense.org/mirror/downloads/pfSense-CE-2.4.4-RELEASE-p1-amd64.iso.gz
p3 is not the cause of your full filesystem anyway.-Rico
-
Thanks for your input. I am re-flashing with p1 right now.
I would be glad to know what you think the freeze is caused by. -
Probably the full filesystem.
Check for installed packages which write a lot of logs and so on.-Rico
-
It's odd because /var/run is a ram disk and it's tiny because it never, normally, has to hold anything.
I've seen this once before recently and it was seemingly caused by a loop in a script that was somehow triggered that duplicated firewall rules until the ruleset was too large to load effectively. Check the size of your config file in /conf/config.xml and make sure it's rational. Usually less than 1MB.
Steve
-
The config file must be huge :
-
Yes entirely possible.
In the previous case it seemed to be somehow caused by the pfBlocker rules ordering script though I was unable to replicate it. It was the pfBlocker added rules that were duplicated until the config was >50MB.
Steve
-
The config file for the SG-1100 is 156k. The config defines installs of pfBlockerNG, Snort and OVPN client export. The config also provided an OVPN server for a couple of local users.
The SG-1100 pfBlockerNG setup implemented a large group of Geo Blocks and 4 (only) IPV4 IP block files all as WAN outgoing reject rules. The rationale being to stop my LAN users and road warriors going where they shouldn't. The DNSBL set of files was the usual set of Oink + public plus appID and the 4 addblk lists.This lot ran in about 61% of RAM. It had run for a while apparently happy but began to lock up in after a couple of days. Yesterday, after a clean re-flash and config reload it collapsed in 30 mins with both processors screaming flat out and failing to service the web-config interface. While we still had web dashboard there was a solid triangle of LAN and WAN traffic developing to the right. We also were watching it from the shell which remained snappy. With the console almost locked up solid and the web-config completely gone, the box maintained web access as if nothing had happened; classic doppelgänger I suppose.
From the shell I could see the var/run was stuffed full whereas it is running right now after another re-flash but bare-bones with no packages and looking sweet.
This seems to me to suggest that there is nothing wrong with either the SG-1100 or the amd64 hardware which each failed with much the same symptoms and a similar config but with many more files in the amd64 IPv4 section of pfBlockerNG. The current plan is to gradually add back items to the sg-1100, waiting after each addition, to find the offending part of the config.
I am speculating that the previous apparent willingness to run the config which then went sour might point to a dud IPv4 file which got updated and changed in such a way as to cause a loop to ensue.
-
That seems like a good plan of attack. If you see it again and still have any sort of access check the config file size and the back configs in /conf/backup. When we saw it previously you could clearly see the file size ramping up in the backups as the rules duplicated.
Steve