UPDATE: Running './build_pfPorts.sh b43-fwcutter' solved the problem. However this ./build_iso.sh failed to build iso (just memstick images were built) and the memstick image has the same kernel panic as stated in my above posts. :-( ) Now, I am getting the following error during ./build_pfPorts.sh File not found b43-fwcutter /usr/ports/sysutils/b43-fwcutter /usr/local/bin/b43-fwcutter - /usr/local/bin/b43-fwcutter Building athstats…main.c: In function 'getfmt': main.c:73: warning: implicit declaration of function 'strcasecmp' Done! Building tools/crytpo...Done! I checked with whether b43-fwcutter is available and it is there: dev# ls -lah /usr/ports/sysutils/b43-fwcutter/ total 32 drwxr-xr-x    3 root  wheel  512B Aug 22 19:01 . drwxr-xr-x  1078 root  wheel    21k Aug 22 19:04 .. -rw-r–r--    1 root  wheel  428B Aug 22 19:01 Makefile -rw-r--r--    1 root  wheel  141B Aug 22 19:01 distinfo drwxr-xr-x    2 root  wheel  512B Aug 22 19:01 files -rw-r--r--    1 root  wheel  113B Aug 22 19:01 pkg-descr Did anyone encouter something like this?

It cleans up old remnants of patches (e.g. .orig, .rej files) and similar things. You can build an iso right after, though I normally run this first: ./update_git_repos.sh && ./clean_build.sh && ./apply_kernel_patches.sh

It is safest to make a stock image first, test it, and make sure you have everything working. Then make changes. Otherwise you don't know if something went wrong because of your changes, or because of the builder in general. There was just a recent thread where I explained the various ways to tweak the kernel options (e.g. EXTRA_OPTIONS in pfsense-build.conf) and I updated the doc here: http://devwiki.pfsense.org/BuildTimeOptions What you want to do can be accomplished by just adding one line to your pfsense-build.conf once you have made a good ISO. I mentioned the path to the resulting kernels in a previous post in this thread already.

RELENG_8_3 is an errata branch, which can get updates from time to time. It must always check to make sure they are completely current and stock before starting. So it doesn't matter if you already have them, it will still check for updates and revert any local alterations to that tree before it starts so it's back to a stock FreeBSD base, ready for our patches to apply.

No. I wouldn't expect a fix until closer to 2.2, if then.

Build? Maybe. Work? Probably not. The work on 9.x was abandoned. Even if it built, the patches would be old/out of date, mostly left in case we decided to pick it up again. The work on 10.x is still in progress. I don't believe it builds/works yet. That probably won't be good/stable until a lot farther into the 2.2 development cycle.

The code is updated from git on every builder run, nothing to manually do there. Not sure why they weren't showing before as the code was there/in place… shrug It works now, not going to worry about it. :-)

They haven't been touched by anyone in a long time, they likely do not work with 2.1

@DigitalSpirit: Atheros driver from freebsd 9.0 compiles and works on pfsense But in kernels that I maked has been broken pfctl and full image creation stops on php I am having the same problem with image creation halting at php (http://forum.pfsense.org/index.php/topic,61074.msg354170.html#msg354170). Can you tell me how did you overcome the problem? I am asking because you reported above that you could finally create the NanoBSD images. Thanks!

@mikeisfly: I'm assuming I could take a full backup file and edit it to my needs and restore that without corrupting the whole system right? Assuming I don't make any mistakes. That's the only way it can reasonably work. What you want is the separation of Interface Assignments (e.g. LAN is em0, WAN is em1) and "the rest". So you can prepare a new box with Interface Assignments (e.g. LAN: ra0, WAN: ra1) and pull all the additional information from an Interface-Assigment-less configuration file. Well, it should work in such a simple case. But what about VLANs? Ouch. An automated decision which VLANs to keep and which to ignore would be quite complex, if not immpossible. The only safe way is to manually edit the configuration file with a text editor before restoring it on the target machine. It's quite simple, in most cases. In some more complex cases, I did a partial pre-configuration of the target machine and then manually merged the config fiels from the old and the new machine.

Okay thanks. I will try this.

So I'm trying to get back into this. I have been doing quite a bit of research into jails. I think running the controller in a jail is absolutely imperative for a few reasons: 1) It keeps the system has "vanilla" as possible (easy to install/uninstall without touching the underlying system). 2) It isolates what could potentially be a security threat. So basically, can a pfSense package create a jail and install software into it without having the PfJailctl package installed?

The same remark from my own experience of translation - some of the buttons in forms at their translation into another language no longer work. Therefore, in its version of the name translation, I left the fields and buttons in English - and all had to work as it should. And I think 100% Gui translation is not needed, because you might lose the meaning of the names of the terms that will worsen the understanding of the end user. But it is my opinion only.

@Lectrician: Well, it seems to have cut down on the amount of duplicate entries, but there seems to still be two or three each day, but only single duplicates, not multiple. I guess because some users bail out faster than the session data gets written. As an additional measure you could check your logfile if the last 1000 bytes or so already contain the currrent user's MAC address (with a timestamp not older than a few minutes). As you perform locking on the file, you'll have not trouble with race conditions, I think.

It was wrong mareclloc :)

Thanks for your answer. So, backporting is the strategy. I submitted my changes (as a pull request) to the master branch now as well. The repository pfsense-tools, where I had to patch the DSCP kernel patch (for FreeBSD versions 8.3, 9.0, 10.0), appears to be organized a bit differently though.

Thanks for the info…

That's a fairly vague question and not one that's easy to answer. Can you be more specific about what exactly you're looking to find out about?

@Altar: What about pfSense upgrades ? Shall they leave my driver and loader.conf.local untouched ? loader.conf.local will be copied across an update but the module will not. This is only sensible when you think about it as an update may render the module incompatible and could potentially stop the system booting. It would be interesting to find some way around this though as most updates do not change the kernel. You could keep a copy of it in /root/ which is preserved across an update (in Nano at least) for easy copying back to /boot/modules. I haven't tried that. Steve