@onhel: Might be a silly question but is the drive recognized in the BIOS and is it set as the first boot device? Yes. @onhel: Secondly, are you using that CF Adapter as a SATA device or USB? SATA, but I have tried both. I do think the issue may be related to the reader, as I'm able to boot off a 4GB USB thumbdrive with the same image. @jaredadams: I thought I read around here to use a smaller image than the CF.  Try using the 2GB image on the 4GB stick. I had never heard this before. Are you sure this isn't in relation to people with large CF cards (over 4GB?). I tried this as well, no luck. I'm going to try getting a new SATA/CF adapter and see if that works. @wallabybob: There is a crucial detail that seems to reasonably regularly get overlooked: you have to write the UNCOMPRESSED image to the "raw" CF, not to a partition of the CF. (The first sector of the uncompressed image becomes the MBR and partition table of the CF and that partition table specifies that the CF is bootable.) This is exactly what diskpart/physdiskwrite does. Also, the latest versions of physdiskwrite can handle gzip files as it has zlib incorporated so there is no longer a need to uncompress. @wallabybob: This suggests to me that the CF is not being seen by the BIOS in its scan looking for devices with a partition marked "bootable" or the CF doesn't have a bootable partition, perhaps because it wasn't written correctly. I think you're right here. The partitions are good with the first active, and the BIOS is showing the device, but perhaps the CF itself isn't being read. I'm going to swap it for another reader. Thanks. Thanks, Ben

If you have the 2009* dir there, that means you upgraded to 2.1 and then downgraded to 2.0.x, which isn't supported. If auto update did that, someone must have selected the snapshots url from the drop-down menu at some point.

on i386 ? on amd64 start but not working very well.

That fixed it. Thanks!

Yeah, I expect it had to do with TRIM support (not sure if TRIM is yet supported in the FreeBSD version being used), but with a large enough SSD to have spare/slack space this would likely be less of an issue. And the point about a reliable manufacturer/brand/model is very good. This isn't something that NEEDS the high speeds an SSD can provide but it does need the reliability potential.

So I just wanted to post an update about this. I know mjimlay from another forum and am the one who recommended pfSense to him. He engaged me to help him get this setup and wow was this a PITA. Long story short, I left the "142" address on ESXi so I could maintain remote connectivity to the host and attempted to use the "192" address on pfSense as he did. I could sometimes get it to save the gateway if I added the gateway in the interface setup (but could never get it to save if I added the gateway in the gateways page). This gateway would briefly show as online then go offline, probably due to come check in the background. I would have preferred to have the "142" address on pfSesne WAN and use the "192s" as VIPs (which I think is their intention) but I couldn't maintain connectivity to the host doing this. I then got the bright idea to alter the subnet mask. One of the OVH docs I read mentioned I could set the gateway to /24 instead of /32 and it would still work. I figured if that works, let's see what mask I need to use to make the "142" gateway be in the same subnet as the "192" address I'm configuring. The only valid mask for that is /1 so I tried it and surprisingly it worked. The gateway stays online and hosts behind pfSense have connectivity. This may not be the correct way to have handled this but it worked.

@jimp: I'd be seriously suspicious of the hard drive in that case. Not an intrusion. In that case…does pfSense have any SMART tools? EDIT: Never mind, found Diagnostics>SMART. It says everything is hunky dory. Hmm, guess I need to run a surface test. That'll only take a few days... Would it be feasible to just boot off a USB stick? Would I need to worry about wearing out the memory? EDIT2: Running a long offline test now. Also, since I got the GUI back up, got notice of a kernel panic from a couple of days ago. Not sure if it's related to the disk corruption or not.

I would say little to no difference.  In some theories the larger images might help with wear leveling, if that's even a feature of the firmware of the CF card, but at the same time it's highly possible that if the card did have wear leveling it'd still work even with a smaller partition.  Again, at the same time, it's not like the Nano versions are writing to the cards much. Some info/discussion here: http://forum.pfsense.org/index.php/topic,55760.msg298016.html#msg298016 If someone has more/better/deeper info, I'd be interested as well.  I'm building a new box and I'm debating "things". (I have a bunch of IDE to CF adapters, but only 256MB CF cards, so I'd have to buy new, or I've got a few physically small 1GB and 2GB USB sticks sitting around, or…)

Removing Ipguard-dev components… Tabs items... done. Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. Beginning package installation for Ipguard-dev... Downloading package configuration file... done. Saving updated package information... done. Downloading Ipguard-dev and its dependencies... Checking for package installation... Loading package configuration... done. Configuring package components... Additional files... done. Loading package instructions... Custom commands... Executing custom_php_resync_config_command()...done. Custom commands... Executing custom_php_resync_config_command()...done. Menu items... done. Integrated Tab items... done. Services... done. Writing configuration... done. Package reinstalled.

Just Installed pfsense 2.0.2 without a hitch. I think next time I will go with an i7 setup. Thank you guys for the help.

Alrighty. I will leave it for a bit.  :)

You can use any combination of load balancing, failover and policy based routing to acheive what you need. So, yes, you can send a particular protocol or departments traffic via a specific modem or group of modems. You should investigate whether or not your ISP supports ML-PPP. If it does use that instead. http://doc.pfsense.org/index.php/Multi-Link_PPP_%28MP/MLPPP%29 Perhaps you meant that instead of LAGG. Steve

Sounds like you accidentally upgraded that to a 2.1 snapshot then went down to 2.0.2. There is no way you could have gotten a 2009* php dir from a 2.0.x image.

@matguy: @jimp: AFAIK, older versions of m0n0wall might actually import more accurately than newer ones. I haven't tried it in a while, but you should really just be able to restore a m0n0wall config.xml directly into pfSense without any adjustments. Oooh, I'll try Well, I think it worked, all too well.  I was working on it remotely (RDP to a Windows host inside the network), had the interfaces islanded in VMWare on vSwitches with no live external network.  Upon booting I saw a time process taking a while, so I figured I'd give the WAN port network on my LAN so that it might hit a time server, I swapped it over to my regular LAN.  This was all well and good, it got an IP via its local DHCP client.  I imported the XML backup from m0n0wall and it asked about an interface mismatch and asked me to re-assign them since my m0n0wall had an OPT interface (not that it was doing anything) and my VM version only had LAN and WAN.  I checked the console and WAN on the top on EM1 and LAN on the bottom on EM0.  I matched that up to the web interface and clicked save.  Then I lost RDP, looking back, they were in a different order, LAN was on top on the web interface, so I just put the LAN interface live on my LAN and since the import seemed to work perfectly, it has the same Gateway address as my physical m0n0wall router. I can ping the m0n0wall router's external interface fine, but I can't get to anything inside and I don't put the web login on WAN.  I'll have to check on it when I get home, but considering what happened, I think it probably worked.

matguy - thanks for the suggestion.  Have now looked at m0n0wall - if I had found it first I might have gone that way - but I am now more than convinced that pfSense is the way to go - even if I have to scale-up hardware a little. For now it seems to be very happy - as long as I don't hit the php too hard. extide - nice suggestion but difficult with only two slots :)  Seems in any case to be running smoothly with 128MB for now. Hopefully even better with 256MB when I get replacement.  That will probably last for a while - until I can get the higher spec hardware sorted. Thanks again for suggestions / help What a great product - and an even greater community!!

see if this works [image: pfSense.jpg] [image: pfSense.jpg_thumb]

Let's not continue with this fork and follow up here instead: http://forum.pfsense.org/index.php/topic,57020.0.html Cheers Uwe

I used the Invoke Upgrade option in the WebGUI to upgrade my 2.0.1 32bit-i386 installation and it was the fastest and easiest upgrade I've ever done to one of my machines. The only thing I noticed was that I had to check the box to enable the pfBlocker package, the only package I'm using. The package didn't need to be reinstalled, just the box to enable it checked, and it kept all the CIDR lists I had set up.