Hi Bill, What is different in your configuration now than before? ask

This is the expected behavior, that rule should have been required previously, now with a recent bug fix it is required.

Fixed, thanks

I've stumbled upon a small hick-up during an snapshot update and reboot with my previous modifications. After a system reboot the boot-time-update-check won't find an ntpserver ip because of the dsnmasq "localhost" modifications done earlier. Time update check is done before dnsmasq has loaded. So I "restored" the original symlink before time update check is run. Didn't try moving dnsmasq startup before time update check though, so I don't know if that will work too. Symbolic links are not "repaired" when the exist… /etc/rc only checks if the links exist and recreates them if they are missing, it does not repair them like the comments state... the following is only a small part of /etc/rc : echo -n "Creating symlinks..." # Make sure symlink is correct on embedded if [ "$PLATFORM" = "embedded" ] ; then rm /conf ln -s /cf/conf/ /conf fi # Repair symlinks if they are broken if [ ! -L /etc/syslog.conf ]; then rm -rf /etc/syslog.conf ln -s /var/etc/syslog.conf /etc/syslog.conf fi # Repair symlinks if they are broken if [ ! -L /etc/hosts ]; then rm -rf /etc/hosts ln -s /var/etc/hosts /etc/hosts fi # Repair symlinks period!!! if [ ! -L /etc/resolv.conf]; then     rm -rf /etc/resolv.conf     ln -s /var/etc/resolv.conf /etc/resolv.conf else     #make sure the link is pointing to the right conf file for startup reasons ( -f )     ln -f -s /var/etc/resolv.conf /etc/resolv.conf fi the following is only a small part of /etc/rc.bootup : /* start DHCP service */ services_dhcpd_configure();     /* create correct symbolic link for using dnsmasq as forwarder and local cache!!! */     mwexec("/bin/ln -f -s /var/etc/resolv.dnsmasq /etc/resolv.conf"); /* start dnsmasq service */ services_dnsmasq_configure(); side note, people who want OpenDNS and ISP's DNSservers (dhcp) add two lines in to /etc/inc/system.inc like so: function system_resolvconf_generate($dynupdate = false) { global $config, $g; if(isset($config['system']['developerspew'])) { $mt = microtime(); echo "system_resolvconf_generate() being called $mt\n"; }         $syscfg = $config['system'];         $fd = fopen("{$g['varetc_path']}/resolv.conf", "w");         if (!$fd) {                 printf("Error: cannot open resolv.conf in system_resolvconf_generate().\n");                 return 1;         }         $resolvconf = "domain {$syscfg['domain']}\n";         /* Add OpenDNS to the list of nameservers */         $resolvconf .= "nameserver 208.67.222.222\n";         $resolvconf .= "nameserver 208.67.220.220\n";         $havedns = false;         if (isset($syscfg['dnsallowoverride'])) {                 /* get dynamically assigned DNS servers (if any) */ $ns = array_unique(get_nameservers()); foreach($ns as $nameserver) { if($nameserver) { $resolvconf .= "nameserver $nameserver\n"; $havedns = true; } }         }         if (!$havedns && is_array($syscfg['dnsserver'])) {                 foreach ($syscfg['dnsserver'] as $ns) {                         if ($ns) {                                 $resolvconf .= "nameserver $ns\n"; $havedns = true; }                 }         }         fwrite($fd, $resolvconf);         fclose($fd);

Hi, Get tarball and do pkg_add then you're done. Modify some rc/inc files if necessary. I've added several packages installed in this way.

Ah, okay I finally reached at the same page  ;D  ;D ;D Agreed.

I've come across this issue and this is a simple issue to resolve. The issue is with the BIOS revision the ALIX board is running. I bought a ton of ALIX boards and they all came with version 0.92 firmware. This is fine for monowall but not for pfSense. Get an empty CF card handy and go here: http://pcengines.ch/alix2.htm to download the freedos based 0.99 bios update. If you use physdiskwrite.exe to copy the .img file here: http://pcengines.ch/file/freedos.zip (inside the zip file) you can then copy the 0.99 files to the CF card in windows. Boot to the CF card, run "sb" at the command prompt to upgrade and you should now be able to run version 1.2 images and up on ALIX.

Most of that doesn't apply, the projects are pretty significantly different now. There are a couple things there we need to verify have been fixed.

This is not possible. I think there's already a thread about this. http://forum.pfsense.org/index.php/topic,9783.0.html

I did a full install from pfSense-20080820-2336.iso.gz and restored my saved configuration file and now bandwidthd works.

Yeah, I tried doing a full install using an earlier build of the 1.2.1 RC1 software after seeing the thread about the messed up 1429 build. I already had edited the /etc/fstab to reflect ad instead of da. This resulted in an ALIX board that the bootloader would start on, and then say "can't load kernel" yet from the bootloader I can traverse and read from the filesystem where the kernel and boot files are. So it seems like I am missing something, just not really apparent what it is. I have to go get a smaller CF card to see if that isnt the issue. As an aside, just to make sure the CF card itself wasnt an issue I did a dd of my working 1.2 embedded release on a 512MB CF card and dd'ed it onto the 4GB CF. That 4GB CF works, and if I changed the /etc/platform from "embedded" to "pfSense" and it works ok, but that just leaves me with the problem of how to expand the FS from 128MB to something bigger. @wallabybob: I used VMware Fusion 2.0 Beta 2 to run the pfSense-20080822-1429.iso to do a Full Install on my new CF card via a USB reader. There seems to have been problems with the builds. There are reports (http://forum.pfsense.org/index.php/topic,11129.0.html and http://forum.pfsense.org/index.php/topic,11111.0.html) that the last known good build was 20080820-2342 for an update. In the directory of recent builds it looks as if you will need to go a bit earlier for a full build. The problem reports I've seen don't look anything like your problem but the reports seem to have been from people doing updates rather than full installs. I don't know that using an earlier build will fix your problem but from the reports I mentioned its likely your system wouldn't work well even if it did boot so you might as well try an earlier build. Once you get a kernel to build you are likely to run into a minor problem: I expect the kernel will be looking for the root file system on a da device (e.g. da0) whereas its likely to be on an ad device (e.g. ad0). This is easily recovered by supplying the correct device name when prompted THEN when the system has booted, editing /etc/fstab to permanently correct the device name. (The device name da is used for "disks" connected by SCSI or USB. The device name ad is used for "disks" connected by an IDE controller.) I've done similar things to what you describe though not through a VM.

Thanks, this is updated now.

I have install ISO from 13-Aug-2008 end traffic shaper work ok !

you caught it before a full run, it sleeps a day between runs. It's fine now.

I haven't had any problems accessing from WAN since the reply-to fix.  I suggest firing up tcpdump and seeing what's happening.

that's expected and by design.