OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: Taomyn on February 02, 2017, 07:26:16 pm
-
Everything was more or less fine after upgrading from 16.7.14 to 17.1 until today when during the day I was unable to access my systems externally. On returning home I discovered the firewall had completely locked up, no ping or GUI. When I looked at the console directly via VGA, I saw this instead of any kind of login prompt:
I'll put a screen shot here, or I would if I could figure this forum, nothing works for me :-(
I connected a keyboard and nothing worked so I had to press and hold the power button, then restart it. I checked my Console Options and they appear fine:
I'll put a screen shot here, or I would if I could figure this forum, nothing works for me :-(
Any ideas?
I also submitted an error report through the firewall in case that helps.
-
Try setting the "vt" driver and primary console to "efi". FreeBSD flipped their the default on 11.0, and the old defaults that worked for EFI are not working so well anymore (we kept our settings to minimise impact, ironic).
Cheers,
Franco
-
Try setting the "vt" driver and primary console to "efi". FreeBSD flipped their the default on 11.0, and the old defaults that worked for EFI are not working so well anymore (we kept our settings to minimise impact, ironic).
Cheers,
Franco
Thanks, that did the trick after I rebooted - if it hangs again, hopefully I can gather more info.
-
I'm afraid it hung again today, exactly the same way although this time I could see some information - see screen shot, but connecting a keyboard still made no difference and I was forced to kill the power. I also submitted another report through the GUI once the firewall restarted, and I then disabled a few plugins I don't currently use (I was going to play with them later), and see how it goes. All though IPS/IDS is still broken for me, I left that on and will disable it should the problem repeat.
-
It's happened again - have disabled Intrusion Detection this time, though not really working anyway.
Report submitted via GUI also.
-
Happened again today, changed the thread title to highlight this as the main issue.
Is there some way to schedule just a firewall reboot? I'm thinking of doing this to at least give me back some kind of stability.
-
We're having the same issue multiple times: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903
I'm going to ask FreeBSD for help on this report. Can you post your hardware specs? This is surely something related to a distinct set of conditions.
Cheers,
Franco
-
Is there a good way to get the hardware specs as the firewall sees it, either in the GUI or via the command-line.
It's a while since I built the box and I don't recall every specification of it - but I will get what I can when I get home.
-
You can generate a crash report under and drop me a note in the description. But hardware eval on problematic system has show hardware as new as 2013, so no sure anymore. :/
-
Well my box is only about two years old, so fairly new.
I did submit 3 reports so far, if you can search for any with the email address starting "ferd352" and ending "@gmail.com" (I use plus-addressing) they will be mine.
-
I just upgraded to 17.1.1 and wanted to know if there is any chance my problem is likely fixed by the updates? I ask because then I will disable my daily reboot of the firewall and see how it goes.
-
No particular change for this. Still need to discuss with FreeBSD. Sorry. ;(
-
No worries, thought I would ask, so I'll leave my reboot in place for tomorrow morning then disable it and see what happens at the weekend, at least then I'll be close by to reboot it manually.
-
Just to let you know that I'm experiencing the same hangs where the firewall doesn't reply to any request, neither ping nor https.
Pressing the power button of my mini itx case does reboot it though.
-
Just to let you know that I'm experiencing the same hangs where the firewall doesn't reply to any request, neither ping nor https.
Pressing the power button of my mini itx case does reboot it though.
And the same error on the console as I reported above?
Have you submitted a report through the firewall as well? It would be good to get more data points sent in.Go to System, Firmware, Reporter.
-
The reporter doesn't report any errors after the reboot.
I haven't had the possibility to check the console, but for the last three days it was stable.
Updated to 17.1.1 yesterday too.
-
I also switched the console to 'vt', might this be a workaround/fix for the hang?
-
I also switched the console to 'vt', might this be a workaround/fix for the hang?
No, at least it wasn't for me - since updating to 17.1.1 I'm testing mine without a scheduled reboot to see if it's fixed. 1day 4hrs so far....
-
Well so much for that test - it just hung again so will re-enable the daily reboots.
Report submitted as always.
-
Same issue on my box. lexcom 3i270d
Installed fresh one week ago.
Died always after one day.
Intel(R) Atom(TM) CPU N270 @ 1.60GHz
2 CPUs: 1 package(s) x 1 core(s) x 2 HTT thread. 1GBRam
NanoBSD form 4GB-CF
-
Died always after one day.
Did you submit a report through the firewall? The "Report" page is a little mis-leading as it will look like there is nothing to report, but hit the button anyway as it will say there is and fill in the details.
The more info we send in, hopefully the sooner we can get this fixed.
-
Sorry can't provide you with chrashlogs. because the firewall will not boot anymore.
So i switched back to my old CF-Card with a booting pfsense 2.3.1
At the moment i have not the time for investigating.
My intension was to go to opnsense because pfsense will not support i386 and NANOBSD in the comming release.
Have seen some other posts where also users have problems with BSD 11.0 on Atom Hardware.
At the moment i will stay on pfsense 2.3.1 with BSD 10.3.
-
So far not much luck here. It's a corruption of the VM lists somehow, a locked object returns without a lock. The code does not expect this to happen at all and on 10.3 apparently it did not.
It's somewhere in the amd64 code, so maybe i386 has better luck running smoothly. Can somebody confirm/deny?
-
Regarding the crashes in turnstile_broadcast(), a FreeBSD developer provided a test kernel:
# opnsense-update -kr 17.1.1-rwdebug
# /usr/local/etc/rc.reboot
It still panics, but will print vital debug information when doing so.
Running it and providing the output will hopefully help resolve this.
Thank you all,
Franco
-
I missed something. How is this solved? I'm hitting this exact issue.
-
Are you running OPNsense 17.1.2?
-
Are you running OPNsense 17.1.2?
I am now.
-
The issue is fixed in 17.1.2 and FreeBSD is still asking for users to reproduce this with the debug kernel posted above in order to get it fixed there... I would just like to pass this along, but I can understand our users' stance as well.
Cheers,
Franco