I figured it out.

The mb has a function in it's bios to redirect the preboot screens out the console port. There are three options on how the board should handle this. When set to two of the options the NanoBSD build for some reason pauses if there is no console cable attached. I am assuming that the BIOS still has some kind of handle on the com port and the ttys driver is in a wait state. When I plug in the console cable the mb releases it's hold on the com port.  If I disable post boot console redirect then NaonBSD does not get hung.
I have placed a bug report with Supermicro and all is well in my world again.

Thanks

There's a bug ticket open on that.

@ChillyWilly:

So was is the latest build with the 7.2 ath driver in it?

Get one off the snapshot server from early-mid September.

I'm running with version 1.2.3-RC3 built on Sat Oct 17 21:42:17 UTC 2009 and everything seems fine now. Thank you quys for the fast answers and fix.

David.

@rcpao:

I recommend pre-duplicating the slice in the nanobsd new installation images so the step can be skipped by the user for the first upgrade.

This is exactly what is already done on the Nano images. The second slice is merely a duplicate of the first done beforehand.

I've never had a problem running a nano upgrade, not recently anyhow. Depending on the version you started with, there may have been bugs in the code at that point that didn't allow a working upgrade, so a reflash may have been necessary.

That information is not retained after updating, the filename doesn't really matter at that point.

The NanoBSD size will already be displayed in the gui on newer snapshots under Diagnostics > NanoBSD.

See:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/c43ed2f92df169a80b81feb85d80223e9710ac5b

I'll put it on my TODO list to add that to the dashboard system info as well.

@jimp:

Not sure if this might work but have you tried bridging LAN to ath0 instead of the other way around?

That should work. The problem isn't the bridge, it's when you have an IP assigned to an Ethernet interface and it's down, the IP is gone.

Thanks for the pointer–I totally missed that doc on my first trip through the FAQ.
Not being a BSD guy, I couldn't remember the darn ping flag to send traffic through the LAN interface.

SonicWALLs suffer from this exact same problem....I wonder what they use as their base OS... ;)

There are probably too many combinations of rules to ever come up with a complete list.

Trial and error may be your best bet.

I got the same error with vnstat.

My pfsenen is 1.2.3-RC3
built on Fri Sep 18 05:03:50 UTC 2009

regards,

Minh duc

error.JPG
error.JPG_thumb

That was not the same issue as the thread in which you posted, so I started a new topic with your post.

DenyHosts doesn't work at all right now, it doesn't matter if it's nanobsd or a full install. I spoke with the maintainer and he is considering options for fixing it, but it may be a while.

Yes, it is, but based on my experience….

If You are working on some site for some time and e.g. reading lots of text and after that you want to go on other part of this site, than sticky thinks "it is new session" and it will use other output GW (session was timed out from sticky point of view). That is a problem, specialy if You are logged on that site (it will disconnect your accout) because You connect here again with different IP address (You are going from other IP or ISP respectively).
Specialy it is problem for forums communication... after deeper reading of interesting items.... I have to login again and again....again. Or like now when I try to write this item (it is lots of time consuming for me and specialy for my english...) my session is closed or sticky connection can realocate it to other output GW and website says You are not connected now (other IP is used for sendoing this item)

DuroM

I hope it is true but it looks like this for me....

@gloomrider:

2: No.  Assuming you already have a recent nanobsd instance (that you presumably flashed by hand), you can download an update suitable for the size of your CF card and use System:Firmware:Manual Update.  I just looked and I guess I hadn't noticed that Auto Update has been removed from the later snapshots.
4: The later snapshots seem quite stable.  I have not had issues for quite some time on my 2D3.

Great! thanks!

now, just wondering is there a special forum for the nanobsd package setup?  i have installed the imspector and denyhost and they both don't seem to be working.(no log for imspector and nothing with denyhost)…

thanks

@xbipin:

one other thing is all my CF cards i use with alix i get these 2 lines in serial console
WARNING: Expected rawoffset 0, found 63
WARNING: Expected rawoffset 0, found 922383

and also after a few reboots etc one of my CF card failed or so as the serial console started saying write failed, next 1 retry and this started coming when loading web configurator and pfsense would never boot up completely so i replaced it with another CF card and that worked fine but the rawoffset warning it still keep getting in serial console

Your description of the bad CF card symptom (web configurator hangs for a long time then throws an error) was identical to mine.  I believe the rawoffset errors can be safely ignored.

Well, I rebooted again and the problem didn't rear it's ugly head. The PID file was deleted and replaced by the system after reboot. I checked for any core files but there are none. I'm wondering if in my case it was just a glitch. I had updated from 1.2.3 RC2 just before I had this issue so maybe that had something to do with it. Either way i'm going to say that i'm good for now but i'll post again if it crops up again. Thanks guys.

Note none of those things will fix the wireless problem. Best you can do there is hope it's fixed in FreeBSD 8 so it'll work in the future.

see http://doc.pfsense.org/index.php/UpgradeGuide

Thanks jimp. I will wait with my first update until the final is released I guess ;)