Quote:
Originally Posted by unixjingleman
Hi There
I'm still using 4.8-stable with a GENERIC kernel. I'm gonna do a fresh install of 5.0 soon rather than upgrade twice(I'm using it for such a simple purpose that it will be quicker that way).
|
4.8 has not been supported since 5.0 was released 1 Nov 2011. At this moment, only 4.9 and 5.0 are supported. In less than two weeks, 5.1 will release, and then the only supported releases will be 5.0 and 5.1.
Quote:
|
...By noticable i mean that the console won't accept or echo characters from the keyboard.
|
Is X running on this platform at the time the console stops functioning? I ask because the default behavior during an actual crash or panic of the system is to drop to ddb(4), and if you have X running at that moment, on many architectures you'll be seeing X on the screen and not know you've dropped to ddb. If the video output from ddb remains hidden, but ddb is functional, you can blindly type ddb commands.
If X was not running, and there is no obvious response to console keystrokes (or connection via the network), you can force a drop to ddb via the console if the kernel will a) still respond to keyboard interrupts, and b) if you've enabled the proper sysctl in advance.
If you are running X, you can change the default behavior during a kernel panic, and ensure a crash/reboot without entering ddb at all. Again, via sysctl settings.
See the crash(9) and ddb(4) man pages for more info.
Quote:
I'm really puzzled. I know it is extremely unlikely to have been hacked, if this is even possible at all. Also the Internet gateway doesn't crash hhmmm.
Also i couldn't find anything in the mail or logs relating to anything like what's been going on. But i didn't untar the old logs. I'll post pf.conf if you realy think that firewall rules can cause an OpenBSD system to crash?. Sorry that's not much data to go on. The main question is can a misconfigured pf cause peroidic system outages?. If so could you advise me on pf if i post my pf.conf?
Thank you very much for your time
regards unixjingleman
|
If your system has become unresponsive from both the console and from the network, then it will either be from a crash or a hang. If the kernel has crashed, and you are running X with default sysctl settings, depending upon the hardware architecture you are using you may never see ddb console output appear on the console. We don't know your architecture, but if it is either amd64 or i386, "hidden" ddb output is the norm when a panic occurs while X is in use. On hangs, where the OS stops running and responding to normal events, it may be possible to force ddb as I mentioned previously.
You can be assured that we all would be much more interested in your dmesg(4) than any other configuration information you could gather for us at this time. That will answer my question regarding architecture, for example.