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