2.1-release [Update - Success]
-
Yep - I've been working under the assumption that there is alot of data being left on the disk causing failures.
Lots of people are shy to reimage their systems, but some seem to have moved in that direction with good results. -
@Xon:
if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
You recommend a /var size? The 10 interfaces in my home box proved your point. ::)
Steve
-
@Xon:
if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
You recommend a /var size? The 10 interfaces in my home box proved your point. ::)
Steve
Applying this patch, will mean you don't need to touch /tmp. The real problem is it is about ~3.6mb per RRD graph with 2 years of stats, or 1.5mb new. The XML dump is ~4.5mb per RRD.
And the backup process requires dumping every RRD graph to XML, then compressing it. So maybe 90-100mb for /var should let you do the upgrade sucessfully?
Doing that on an Alix platform and getting it to boot would be hard. And if you ever decrease /var's size the RRD backup process would fail next shutdown/backup cycle, and thus cause RRD data lose on the next reboot.
The alternative solution which I'm poking at, is to update ./rc.backup_rrd.sh, /etc/inc/rrd.inc, /etc/inc/upgrade_config.inc to compress each file one by one, and then tarball it up.
So instead of dumping all the files to XML, then processing them dump 1 to xml, gzip it, then after tarball all the gzip'ed files. This is less efficient, both in time and over all compression of the final archive. But it fits in the memory constrains.
I'm bashed up a changed backup script and have the restore parts looking right. It is just a matter of testing and ensuring the restore process handles if you give it a .tgz or a gz.tgz
-
Personally I don't have an Alix, I have 512MB so running a 100MB /var is at least feasible. Also I have at least two years of data so I'm probably pushing the maximum size you might face.
That at least explains why I have had no problems updating any previous test box that had fewer interfaces and much less data.Steve
-
Update 4 Alix1D3 by now. Almost perfect, but in my CARP setup from 2.0.2 -> 2.1 OpenVPN is not working. The server doesn't answer anymore, I'm rolling back
-
Update Alix2D3 from 2.0.1 to 2.1
All perfect
Congrats and thanks
-
halo ,
PFSENSE router using for dual wan failover , working very good with wan and opt1 as wans and lan as lan network.
Upgraded 2.0.3 to 2.1 my opt1 is not working after upgrdation. Opt1 is showing in dashboard pending and unknown.
Please advise me work the opt1 .Thanking you .
(this is my first post . Please tell me where can i start my new post or question.I didnt find anywhere to post thatswhy
I used this Excuse me please. ) -
Another successful installation on a Soekris 6501-70.
This was an auto-upgrade from pfSense 2.03 Release to 2.1 Release, i386. I'm using the full version of pfSense, not the NanoBSD images, with a standard HDD. No issues to report.
-
Just updated to 2.1 but having problem with squid. got this error meesage.
squid package is missing required dependencies and must reinstalled -
Yep - So you uninstalled it and reinstalled it right?
-
No widescreen package anymore for 2.1?
I think there is going to be a widescreen theme in 2.2
http://forum.pfsense.org/index.php/topic,48140.msg353106.html#msg353106 -
What about the widescreen that JIMP posted a link for the other day? Seems like some people are happy with it and its running on 2.1.
http://forum.pfsense.org/index.php/topic,62410.msg364660.html#msg364660
http://files.pfsense.org/jimp/patches/widescreen-21.patch
-
Oh nice, I missed that one. That works too :)
-
I don't know about that package, but I've not seen any complaints yet EXCEPT that when you first install it you might have to clear your browser cache to see proper results. I was really surprised to see how many people require that package, but seems like many.
