Bug showing up after power loss Version: 2.4.4-p3
-
I discovered, to the chagrin of Protectli and one other vendor selling router appliances, that, after a power loss, the WAN and LAN interfaces become disabled completely and no routing occurs, you can't get to the WebConfigurator nor can you ping either interface. The only way to get running again is to hook a monitor up to it and re-configure the interfaces. I've seen many posts (older) that this was a problem and it was supposedly fixed. I did fresh installs on 2 different appliances, and believing it to be a hardware bug, sent devices back to them only to find the replacement did the same thing (after another long power outage, long enough to run the UPS batteries to empty).
Does anyone here have a solution to this? Is there a patch for Ver 2.4.4-p3 ? -
@DD9000 said in Bug showing up after power loss Version: 2.4.4-p3:
devices
What devices ?
@DD9000 said in Bug showing up after power loss Version: 2.4.4-p3:
(after another long power outage, long enough to run the UPS batteries to empty).
and what about setting up things correctly : when battery runs out, shut down the device properly (using the NUT/UPS package) ?
@DD9000 said in Bug showing up after power loss Version: 2.4.4-p3:
Is there a patch for Ver 2.4.4-p3 ?
No patch. As any other computer device, ripping out the power will do nasty things to your device (file system). Test yourself : rip out the power on your PC, and you'll see Windows complaining when booting up ..... if it boots ....
-
@Gertjan - The power is pretty bad, but it is on a UPS, however the batteries are good for only an hour. But, being that this is the only system in over 2 decades that loses its settings after power loss does disturb me. The other problem is that pfSense, after doing lots of configuring, can get stuck (all OSe do this at one point or another), so a powerdown is the only solution for lock up conditions (sometimes this must be done from a remote power controller - as this location is an hour away).
Current hardware is a Protectli Celeron (6 port) - SSD drive.
It also makes zero sense that ONLY the definitions for the ethernet ports is "corrupted", but everything else is perfectly intact (no corruption of data) - including the boot records (it boots completely)! Hence why I insist this is either a problem with this version of BSD or pfSense (or both). (also why I know it's not a corruption problem via power loss, but a software problem - since all else is intact - even coming from same drive).
Many other brands of routers use similar OSes, software and hardware (some identical) and don't lose only specific settings after a power-loss (or hard shutdown of any type).
While a graceful shutdown is preferred, systems can and do lock up on occasion (buffer overflows, uncaught bugs) and must be powered off. But to have to redo settings that should have persisted (when all other settings are persisted) every time this scenario arises is ridiculous. -
There is no patch because this is not a bug. I've seen dozens of devices get power cycled in the field and have not had any of them re-assign interfaces after a power failure. Corrupt files systems, failed hardware -yes. Perhaps choosing zfs over ufs would help things. If it is a problem with a particular system/brand, you need to take it up with your vendor. Try a vanilla install on pc hardware and pull the power repeatedly and see if you have the same issue.
-
But this used to be a bug. Look in the forums here - this was an issue before and was patched a couple of years ago. Perhaps it is a hardware issue now (and Protectli just keeps sending me defective units!), but this is why I'm posting here - looking to see if anyone else has had this problem with other brands of hardware and maybe suggestions of where to look in either BDS or pfSense (this is an Intel pro 6 port configuration - maybe it's an Intel thing) to troubleshoot.
Will be running OPNSense to see if it has the same problem. -
I can't say I can ever remember seeing a 'bug' that resulted in a loss of interface configuration like you describe.
Maybe the filesystem was so trashed that the configuration was lost, but in that case you'd have to do a lot more than just reassign interfaces.
So I suspect that maybe it's not quite exactly as you describe. But since you don't have a monitor hooked up when it fails, you can't really tell what happened for sure. When it does fail, you need to look back in the boot log and see what it's really complaining about. (Press scroll lock on the hardware console keyboard and then use the page up key to go back in the buffer, then scroll lock again to get out)
It wouldn't surprise me if it's related to that hardware, given its track record/reputation, but it's entirely possible it's a red herring and you're chasing the wrong end of the problem.
