OPNsense Forum
Archive => 17.7 Legacy Series => Topic started by: silent_mastodon on January 13, 2018, 08:31:01 am
-
My opnsense running 17.7.11 crashes every 8-10 hours ( I hear the boot chime going off) and when I look in the system.log in the gui all I see is stuff like
kernel:
and
kernel: OK
just before the usual boot messages.
I gather that actual dump files aren't enabled, but I can't seem to find an option anywhere and the documentation wiki says nothing about it (search for 'crash' just gives irrelevant results).
The contents of /var/crash are a 'minfree' file that contains the string "2048". The webgui reporter says that everything is fine.
I memtested the machine, which has been running opnsense steadily since 15.x, and found no issues.
-
Hi there,
Kernel crash dumps only work with a real swap partition. The following command will indicate if there is one or not available in your system.
# swapctl -l
Cheers,
Franco
-
I'm guessing a /dev/mdNN device isn't a real swap partition?
The issue started after upgrading to this .11 release. I'll try walking it back a few and going from there I guess.
-
Sorry, no, only persistent hard disk storage works for this.
The kernels within any major release differ in very tiny details. It's more likely the hardware / operating conditions changed, new services that cause kernel crashes, overheating, newly plugged cards, failing power supplies, etc.
Cheers,
Franco
-
Alright, I've re-installed opensense with 17.7.5 (I was running 17.7.6 before the upgrade, so this should suffice) and I'll observe its relative stability for several days before reporting back.
I used the manual option during partitioning (which forced me to break out a calculator to use since it made me deal in raw sectors? Didn't realize the manual option was this unpolished) and unless I missed it it never gave me the chance to assign the 1GB I set aside as a swap partition.
Was there something else I should have done? Or is setting up a swap partition a 'custom' post-setup step?
-
Check /etc/fstab and swapctl -a so that we know your swap is active.
Cheers,
Franco
-
It wasn't.
I found instructions on how to enable it in freebsd and set the partition as swap in the fstab file.
Is there anything else I need to do?
-
Stability so far with 17.7.5 is much enhanced, with no spurious reboots. 1.7.7.11 had 2-4 reboots a day. Continuing to monitor.
-
Don't think there is anything else other than wait. You can upgrade to the newer 17.7.10 kernel/base maybe to see if that changes your picture, but I'm assuming it was either a service or a configuration change. Unfortunately only 17.7.10, 17.7.11 and soon 17.7.12 are still on the mirror in full.
Sometimes it's also simple overheating that causes crashes. :/
Cheers,
Franco
-
Still ticking upwards on uptime.
In the upgrade I performed, I didn't make any config changes. If there were any, it would have been in migrations done during the upgrade, and not something I changed myself. (I also would have reverted them first instead of pestering you on the forum). I saved my config.xml from the 17.7.11 and pushed that to the 17.7.5 without issue, so if it were a configuration issue I gave it the perfect chance to persist and vex me. So far it hasn't.
The system is a Jetway embedded device with passive cooling. It's environment hasn't changed.
I hear what you're saying about hardware issues and such (I've been a PC technician for 15 years) but the rollback seems to have stopped the reboots, pointing at a software issue, not a hardware one.
-
Fair enough. Now comes the hard part: isolating the "bad" software update as we have over 130 individual components to sift through and 6 versions to cover (17.7.6 - 17.7.11).
As I said, we could start by applying the FreeBSD updates (base and kernel) manually if you are up for it?
Cheers,
Franco
-
I'd like to get to 5 days of uptime before going all-in on diagnostics, just so I can be reasonably sure that the problem has gone away with this version. 2 days is statistically a little thin for my taste, even with the previous frequency of crashes.
If you have the time right now though, please do give me the directions on what to do once I've hit that benchmark, and I'll get it done.
My experience is more with Gnu/Linux and not *BSD, so please bear that in mind. Thank you.
-
Okay, take your time.
You can install the newer kernel and base system by issuing these two commands:
# opnsense-update -bkr 17.7.10
# /usr/local/etc/rc.reboot
(The reboot is necessary and should not be delayed.)
If that produces crashes, you can go back to your old kernel and base:
# opnsense-update -bk
# /usr/local/etc/rc.reboot
After that is negative, we can try updating packages. If it is positive, we can try isolating the update for base or kernel.
Cheers,
Franco
-
Performed the update and reboot.
FreeBSD <redacted> 11.0-RELEASE-p17 FreeBSD 11.0-RELEASE-p17 #0 14a0f7db3(stable/17.7): Tue Dec 12 03:19:44 CET 2017 root@sensey64:
/usr/obj/usr/src/sys/SMP amd64
I don't know if I want to keep my fingers crossed that something crashes, or that nothing happens. : /
-
Looks good. Fairly certain this will not cause the crash, but better to be sure.
Cheers,
Franco
-
Well, it seems like the system is still stable, so I guess it's time to look for other packages.