2.0.2 Release Available
-
A note about timezones for those of us from obscure parts of the world. Some of the time zone names changed with the updated timezone database. e.g. 2 that I am aware of:
Katmandu becomes Kathmandu
Calcutta becomes KolkataFor these, after upgrading, you need to select your newly-named timezone in System:General Setup.
(It will effectively default back to UTC when you upgrade, as the previous timezone name is now invalid.) -
A note about timezones for those of us from obscure parts of the world. Some of the time zone names changed with the updated timezone database.
TZ for Europe/Moscow is still incorrect. Too obscure?
-
Hi,
Congratulations for that awesome work!
There are some 'new' bugs in it.
Where or how can I publish them?CAT
-
new bugs in 2.0.2? We have already found/fixed some.
If they are operational bugs or things that need fixing, try the 2.0.3 snapshots:
http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/i386/pfSense_RELENG_2_0/?C=M;O=D
http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/amd64/pfSense_RELENG_2_0/?C=M;O=DIf it still exists, start a new thread here, and if we can confirm a bug exists then it'll get an entry on redmine.pfsense.org and a fix if it's warranted.
Unless it's a security vulnerability issue, in which case you can contact coreteam@pfsense.org with the details.
-
Can you fix runtime went backwards issue Jim??
Even if Vmtools is NOT using the vmtools server time, then it runs backwards….Its only pfsense itself that syncronize the time and even then it runs backwards.
-
There were no changes I'm aware of that would affect that, unless it's some new interaction with the ntp daemon. We use VMs almost exclusively in VMware and VirtualBox and I've never seen the uptime go backwards message.
-
Ok I did as suggested.
Still one bug resists of 3.
In Dashboard you can't set seconds interval by clicking save settings.
If your pfsense has more than 2 NIC the third Traffic Graph never will be displayed.
You always have to collapse the Traffic Graph.I tested it on 2 different pfsense's…
Did I understood right to open an extra thread for this?
CAT
-
That is a known issue that won't be fixed on 2.0.x. We had to fix another bug that affected rendering but as a consequence it broke that, and the fix was done on 2.1 for saving settings, but it was too complex to bring back to 2.0.x safely.
-
wow thnx.
nevermind.
ur really fast.CAT
-
Install the widescreen package and save settings. Then uninstall package again and everything works…
-
TZ for Europe/Moscow is still incorrect. Too obscure?
The timezone database /usr/share/zoneinfo.tgz was updated in April 2012.
Any timezone data changes since then would need a newer version of zoneinfo.tgz to be made. -
Just updated the zoneinfo database to 2012.j, which is the most recent available.
-
TZ for Europe/Moscow is still incorrect. Too obscure?
The timezone database /usr/share/zoneinfo.tgz was updated in April 2012.
Any timezone data changes since then would need a newer version of zoneinfo.tgz to be made.That's strange, because the change happened in 2011 - http://timeanddate.com/news/time/russia-winter-time.html
Just tried to set my box to Europe/Moscow - it shows incorrect time:
Fri Jan 11 20:25:14 MSK 2013 (should be 21:25 now as Moscow is in GMT+4). -
Tried this with a recent snapshot?
: zdump -v Europe/Moscow | tail
Europe/Moscow Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1 gmtoff=14400
Europe/Moscow Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0 gmtoff=10800
Europe/Moscow Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0 gmtoff=10800
Europe/Moscow Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1 gmtoff=14400
Europe/Moscow Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1 gmtoff=14400
Europe/Moscow Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0 gmtoff=10800
Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0 gmtoff=10800
Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0 gmtoff=14400
Europe/Moscow Fri Jan 1 03:00:00 2500 UTC = Fri Jan 1 03:00:00 2500 MSK isdst=0 gmtoff=14400
Europe/Moscow Fri Jan 1 03:00:00 2500 UTC = Fri Jan 1 03:00:00 2500 MSK isdst=0 gmtoff=14400The last "Winter time" transition listed is for 2011.
[note: zdump isn't present on pfSense, I copied it from another FreeBSD box and ran it against the expanded tz files from /usr/share/zoneinfo.tgz]
-
Tried this with a recent snapshot?
No, I'm on 2.0.2-RELEASE, I thought that 'zoneinfo.tgz updated in April 2012' should work.
Thank you!
-
Technically it should have, not sure why, though I'd have to check how old that zone info was at the time, it may have been older than April 2012. I just updated it the other day to "2012.j" (version number from the zoneinfo database maintainers)
-
Hi guys,
The 2.0.2 have a problem with the snmp interface configuration, when you select an different interface of localhost, like ALL, if you refresh the page the Interface Binding shows localhost instead of ALL. The snmp configuration file is working fine, just the page for configuration.
-
Try 2.0.3, I can't reproduce that problem on a 2.0.3 vm
-
hi guys
with this new release, is it support for SAS/SSD drive in raid already?
-
That's up to your controller. There were no storage driver updates on 2.0.x since 2.0. If it doesn't work on 2.0 or 2.0.1, it's not likely to work on 2.0.*, but you can try pfSense 2.1. Start a fresh thread with more details about your hardware.
