Crashes, and Kea DHCP Server randomly stops for no apparent reason

Started by computer_freak_8, September 12, 2026, 05:21:41 PM

Previous topic - Next topic
Hello,
After a very chaotic upgrade on my HomeLab firewall, I took extra care with my HomeProd, and the process went entirely differently. No packages were removed, the DHCP server was not cut over, etc. I had to do all that manually, even though I'd done the pre-work to make it a smooth transition.

I've had a few times now, over the past few weeks, two events that seem unrelated but both keep occurring. One, is the firewall itself crashing. This is annoying, but not a huge issue since it automatically reboots. A couple weeks ago (I think - I didn't write down exactly when), it had one of these crashes, only it didn't bring up the Kea DHCP server when it restarted. I've had it on my list to investigate more, and then this morning, there was no crash (uptime of 9 days, so perhaps that's when the previous crash was), but Kea was stopped again. In both cases that Kea has been stopped, clicking the "Play" button on the "Services --> Kea DHCP --> Kea DHCPv4" page is all I've had to do to resolve the issue.

As I was getting ready to make this post, I decided to check for updates, and in the process of applying them, the firewall crashed again. Kea came up properly from the crash, but it's concerning I have two different critical components (the kernel and Kea) that can't seem to stay running.

Every time I have a crash, I submit the logs using the webUI reporter page, but never get any feedback whatsoever on it.

Attaching the Kea logs where the service stopped. Also attaching a screenshot of the latest kernel panic.(May take a 2nd post because apparently I've hit a space limit.)

Was on 26.7.2 prior to this morning's updates; now on 26.7.3.

Kernel panic screenshot from this morning, immediately prior to submitting via the Reporter.

perhaps signs of a hardware problem. Perhaps you could tell what hardware is involved. The linked thread has a lot of realtek stuff on it, it might still be the source of problems but is impossible to tell here without basic details provided. It could be almost anything.

Quote from: cookiemonster on September 12, 2026, 11:31:00 PMperhaps signs of a hardware problem. Perhaps you could tell what hardware is involved.
It's a generic mini-PC; if there's a spot to a hardware report or something that would be useful, I can post that, but I didn't find anything while poking through the webUI menus. It would be great if there were better logs in OPNsense to help troubleshoot the issues.

This machine is not as easy to disassemble and would require significant downtime to do so, hence the lesser detail on hardware specs than the other post. Based on the dashboard, looks like 8GB RAM, 100 GB SSD, load averages 0.60, 0.42, 0.30. Not sure what other hardware information is relevant without being able to see/have more detailed logs or something specific to troubleshoot/change.

Quote from: computer_freak_8 on Today at 12:21:52 AMNot sure what other hardware information is relevant without being able to see/have more detailed logs or something specific to troubleshoot/change.
How about a nice smartctl -a /dev/<whatever> output ? :)

And maybe run memtest86+ from your favorite Linux Live ISO Boot Image on a USB Stick for at least 24 hours ?
If you see errors very shortly after starting it you can stop ofcourse!
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

Quote from: nero355 on Today at 12:33:40 AMHow about a nice smartctl -a /dev/<whatever> output ? :)

And maybe run memtest86+ from your favorite Linux Live ISO Boot Image on a USB Stick for at least 24 hours ?

Any tips on how to get smartctl to run? Apparently admins don't have sudo permissions, and running without sudo yields permissions errors. (Smartctl open device: /dev/ada0 failed: Permission denied)
Suppose I can do that from a live USB as well, if needed. Will definitely be a bit since I'll need to build a temporary box to cutover to in the meantime.