Had the same problem, I personally thought it was because if was an Alpha build or w/e.

Hello,

Thank you jimp, yours really helps me to move on…snaps are taking a nap now tho... :) I will give it a try once snaps are back again.

cheers,

Reflash.
Embedded updates are not working.

Are you really using a 2.0_ALPHA_ALPHA box in a productive enviroment?
I would stick with 1.2.2 or 1.2.3_RC1

Do take the time to read and search the forum.  There are many discussions on mounting other filesystems, and the use of CF for full installs.  After that it's all just FreeBSD and they publish all their man pages and the handbook on the FreeBSD website.

Hi,

@jgottlieb:

I found a thread that was able to fix the issue at least for me - http://forum.pfsense.org/index.php/topic,10855.msg69541.html#msg69541

yep, that thread was started by me, actually. And yes, it was effective deleting /var/db/rrd/*-quality.rrd files one time before, but not always, since mid of Jan. I know that 2.0 is still -AA quality and ways to go, needs some attention for this kinda monitoring issues, however.

cheers,

@pharlock:

@joniz:

@pharlock:

has this been fixed yet?
this happened on 8 builds too btw.

I haven't dared to update yet, still running April 23 build.

i just tried an 8 build, works fine, except the serial console (embedded kernel at least)  was 115200 instead of 9600. just somethign to be aware of if you get garbage at 9600.

Tried updating tonight to an 8 build. Now my Wifi seems borked, Dashboard status shows interface down - Autoselect.

My English is poor.

I has update to Tue May  5 21:23:55 EDT 2009

WAN = "{ em2 }"
LAN = "{ em0 }"
DMZ = "{ em1 }"

LAN IP 192.168.0.1
DMZ IP 172.20.211.254

Services: DNS forwarder
oa.cc.com    172.20.211.1
www.cc.com 172.20.211.1

192.168.1.5 can access www.cc.com
192.168.1.5 can't access http://oa.cc.com:81

The firmware Thu Apr 30 07:11:48 EDT 2009
192.168.1.5 can access http://oa.cc.com:81

I've seen other reports of this happening today, but they seem to be isolated to the FreeBSD 7-based builds.

You might try a build based on FreeBSD 8, which can also be found on the snapshots server:
http://snapshots.pfsense.org/FreeBSD8/HEAD/?C=M;O=D

This is probably the right place to try to figure out if you have a real bug.  Then there's the bug tracker:
  http://cvstrac.pfsense.org/

Create a failover pool and setup it to pool traffic going to your dyndns account.
It might be a pitta getting all the ips but should work

My "solution" involved getting OpenVPN to workfor a site-to-site, which freeded up my IPsec ports to forward to an OSX l2tp VPN server.

When I last checked, I wasn't convinced that the webgui was writing the LT2P secret correctly (if at all) but that was a few releases ago.

You have to tweak a sysctl to get ipsec up.
Its sysctl net.inet.ip.ipsec_in_use=1

Try newest builds should be ok.

I did the resize to a 128MB image, but that doesn't seem to be the right approach:

$ df -h Filesystem            Size    Used  Avail Capacity  Mounted on /dev/ufs/pfSense      112M    73M    30M    71%    / devfs                  1.0K    1.0K      0B  100%    /dev /dev/md0                38M    162K    35M    0%    /tmp /dev/md1                19M    4.1M    14M    23%    /var /dev/ufs/pfSenseCfg    1.7M    179K    1.4M    11%    /cf

For some reason 73MB shows 'used' after resizing, so that's a stumbling block (I could resize it larger), but the update process didn't even attempt to use a non-RAM-disk storage, so I don't suppose resizing larger would make any difference.

I put some notes/scripting on how to do a resize using VirtualBox here:

http://bfccomputing.com/downloads/pfsense/get-resize-image.sh

if anybody else is trying this without a BSD host.

Does anybody know what the planned strategy is for updating embedded on 2.0?  Given parts prices, I'd think having a larger default embedded image size with a tmp filesystem on flash would work for most people.  Even in CF, there doesn't seem to be much price difference between 64MB and 1GB parts, at least from some quick Googling.