Change/apply settings for a bridge member; no serial console menu next boot
-
I am using an Alix 2c3 with a TP-Link TL-WN660G wireless card. My WAN is vr0, LAN is bridge0 (OPT1 + OPT2), OPT1 is vr1, OPT2 is ath0, and OPT3 is vr2. On the configuration pages for OPT1 and OPT2, they both have "None" assigned on the "Type" field.
This has been working great, except that when I save changes to OPT1 or OPT2 there are issues if I click the button to apply the changes (probably related to this bug: http://redmine.pfsense.org/issues/show/27 ), but no issues if I do a restart instead. If I do click apply, my LAN interface (the bridge) loses its IP address and even if I set the IP address back, there are still some issues until it is restarted. In addition to that bug, if I clicked apply it results in there being no menu on the serial console on the next and any subsequent reboots (but boot messages and some system messages still appear). At this point it was also frequently showing errors in the system log about something like not being able to initialize the console.
A configuration saved from when this is occurring does not cause this issue in an installation that has a properly working serial console menu, and it cannot be fixed by restoring a configuration backup from before or resetting to defaults. I can fix it by going back to my 1.2.3 release slice and doing the upgrade again (which requires restoring my 1.2.3 config before rebooting into 1.2.3, or the interfaces won't be configured in a working state and the serial console won't recognize any commands, just giving some errors and outputting the menu again each time I try a command). After upgrading I restore my 2.0 config back onto it. I must perform the upgrade from the 1.2.3 slice because it gives some type of disk full error if I try to upgrade from a 2.0 build.
Because of these two issues, I've been restarting the system instead of clicking apply whenever I make changes to the wireless configuration.
I'm currently using the pfSense-2.0-BETA1-512mb-20100106-1014-nanobsd build (upgraded from 1.2.3 release, but using a fresh config afterward instead of an upgraded one) and may soon try a more recent build, but this issue has existed in more than one build I've used so far.