Upgrade from 12/13 to 12/18 -> PPPoE dead…
-
It might, but if your filesystem is corrupt there is always a chance that something in the config could be corrupt as well.
So while it is more likely to work with a freshly flashed CF, I can't say for certain it would.
-
So what should you do so that this type of thing does not happen? Test a config restore every now and then?
-
Normally it's not a problem over time, just keeping a few backups around may be enough. It may just be that it was corrupted by chance, but the only real test is to restore the config (perhaps in a VM) to see if it works OK.
Testing backups is a good task for any backup plan. Backups can't help you if they aren't usable. :)
-
True ;-)
Actually I have a VM around with a 2.0 full version…
Will try to restore that one now...
-
You can make embedded VMs in either VMWare or VirtualBox as well, though it is a little trickier to setup since you either have to convert the nanobsd image to a virtual disk directly, or attach the target virtual disk to another VM where you can download and use dd inside the VM to pull it off. Both VMWare and VirtualBox support named pipe serial ports you can connect to with putty or another program. It's pretty slick once it's all setup.
-
Hm. No, that config wouldn't restore in a vm as well :(
I also tested older configs from october. Same error, everytime…
Tried with aliases and nat section. Does not work. Does this restore of some actually work for you in newer builds? Perhaps nobody tried to restore just a part of the config? -
The partial restore doesn't seek out portions of a whole config, you have to edit out the part you want. For example, to restore DHCP settings, you need to cut the <dhcpd>…</dhcpd> section out into a separate file, and then pick that file along with choosing the DHCP server settings from the drop-down.
-
Aha. So THAT could be the problem….
-
Thanks jimp! That works! Man I could have searched a long time. Perhaps you should add a comment on the restore page so that everyone knows about this…
Or am I the only one who didn't know how it's suppose to work? ;)
-
@ermal:
Try this manually
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/92a1c8e6caca910ae1f8c54751bffebd45d87682or wait for a snapshot with the patch applied.
I just had this error while updating my config. Applied this manually and it works. Will check if it reached the newest snap yet…
-
Ok the fix is in the newest snap, but there seems to be a problem. Each time I reboot my Alix I get the same error as I posted in the beginning of this thread. I then need to ssh into my box do a killall mpd5. Then I have to go into the WebUI to my WAN interface, set a 0 into the idle timeout field and click save. Is this actually also a bug that I have to put in the zero everytime again? It does not get saved somehow…
After these steps my connections stays online until the next reboot...
-
So, are you saying that you have the "Dial on Demand" checkbox checked? Do you really need Dial on Demand?
Refs for devs:
http://redmine.pfsense.org/issues/757http://redmine.pfsense.org/issues/927
-
Yes, that box is checked. I want my line to be up and running all the time…
-
Well, two points.
First if you you want your line up and running all the time, you need to uncheck that box. That box is supposed to bring the line down when no outgoing traffic is detected after "Idle timeout" time has elapsed.
Second, checking that box is likely what has caused all your problems. That options invokes some pretty complex code that apparently still isn't stable. (re: linked redmine issues)
-
If thats is the intended function of dial on demand the the wording of setting it to zero should be remove and replace with untick for always on connection would clear up some confusion
-
Can you please test with latest snapshots?
-
Ok. I'll wait for the next snapshot to appear and try it…
-
2.0-BETA4 (amd64)
built on Tue Dec 21 15:13:51 EST 2010This is a clean install using a config that was running on a nanobsd snapshot from about a week ago. I'm getting errors similar to the OP. I don't have, and never did have the dial on demand box checked. If I click the Connect button on Status: Interfaces, it connects within seconds, but never automatically after a reboot.
-
Try with the most current snapshot, the one just uploaded. IIRC some fixes happened after the snapshot you're on but a new snap hadn't been generated since last night/this morning.
-
Still not working with latest snap…
Still have to kill mpd5 and then click save on WAN interface again...
