Random reboots pfSense 2.1.5 VM [SOLVED]
-
there is no reason to run x64 of pfsense unless you are giving it more than 4GB of ram, etc.
Not true. There likely aren't any functional differences in that case, but 32 bit is a dying breed, every 64 bit capable system should be running 64 bit. FreeNAS and Dragonfly both just put out their last releases with 32 bit support. We'll stop putting out 32 bit releases before too long, maybe a year or two down the road. We do much more testing on 64 bit than 32, and 64 is more widely used, so less chance of issues there. I'm not aware of any architecture-specific issues in 2.2, but if there are any, they're likely 32 bit only.
@KOM:
2. Install pfSense 2.1.5-i386
No, don't do that, use 64 bit.
@KOM:
You can't take an i386 backup file and use it to restore on an x64 config.
Yes you can, there is nothing architecture-specific in most all configs. The only thing that can be architecture-specific is if you manually set your auto-update URL. Just going to System>Firmware, Updater Settings tab, and verifying you don't have "Use an unofficial server for firmware upgrades" checked will ensure that's not an issue.
-
Yes you can, there is nothing architecture-specific in most all configs.
Good news. I was repeating something I had heard from someone else here many months ago.
Yes you can, there is nothing architecture-specific in most all configs.
Oh? Then why is upgrading from 32 to 64 bit not supported?
-
Because that's a re-install anyway.
-
Yea, I'll give x64 another try. But I don't know when I can have that service window.
Now i crashed again. And yet again this seems to be related to OpenVPN.
I had a OpenVPN connection @ 09.45, just seconds after it crashed. So this must be OpenVPN related.
Should I open a ticket?EDIT: And again - OpenVPN connection @ 10.12, crash just right after..
-
did you enable hardware crypto by any chance?
i vaguely remember I once tried this setting on esxi and it resulted in "fatal trap xxx"
-
did you enable hardware crypto by any chance?
i vaguely remember I once tried this setting on esxi and it resulted in "fatal trap xxx"
Yep, HW Crypto enabled (BSD Cryptodev engine).
Disable it now, hope it helps.But i love HW decryption :(
Lets see the result.
-
I think we can mark this as solved for now ;D
Since HW-crypto for OpenVPN was turned off, I've not had a single reboot.I'd call this a bug.
Thanks all!
-
What crypto hardware were you using (or trying to use)? Is ESXi presenting some virtual hardware to the OS the it thinks it can use with the crypto framework?
I don't think you've lost anything. ;)
Steve
-
This just seem to have started again.
And I'm not ready to do a 2.2 upgrade just yet. Seems to be too many IPSec related issues, and IPSec is very important here.Can't find anything related to the reboots this time, see log 9.48 is the last entry before reboot:
Jan 30 11:47:24 kernel: Features2=0x80802001 <sse3,cx16,popcnt,hv>Jan 30 11:47:24 kernel: Features=0x1783fbff <fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,sse2,htt>Jan 30 11:47:24 kernel: Origin = "AuthenticAMD" Id = 0x100f91 Family = 10 Model = 9 Stepping = 1
Jan 30 11:47:24 kernel: CPU: AMD Opteron
Processor 6128 (1999.86-MHz 686-class CPU)
Jan 30 11:47:24 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Jan 30 11:47:24 kernel: root@pf2_1_1_i386.pfsense.org:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_SMP.8 i386
Jan 30 11:47:24 kernel: FreeBSD 8.3-RELEASE-p16 #0: Mon Aug 25 08:25:41 EDT 2014
Jan 30 11:47:24 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Jan 30 11:47:24 kernel: The Regents of the University of California. All rights reserved.
Jan 30 11:47:24 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Jan 30 11:47:24 kernel: Copyright (c) 1992-2012 The FreeBSD Project.
Jan 30 11:47:24 syslogd: kernel boot file is /boot/kernel/kernel
Jan 30 09:48:59 lighttpd[35746]: (connections.c.137) (warning) close: 13 Connection reset by peer</fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,sse2,htt></sse3,cx16,popcnt,hv> -
Did you ever try a 64bit install?
Steve
-
Try, yes. But didn't get WAN-access to work so reverted to x86 after 45mins.
But I still havn't been able to find anything that should relate to random reboots on x86 FreeBSD on x86 compatible hardware and x86 compatible hypervisor. -
Try, yes. But didn't get WAN-access to work so reverted to x86 after 45mins.
In a different VM I'm guessing? Sounds like the usual circumstance when changing MAC on WAN NIC, upstream ARP cache needs flushed (or modem rebooted if cable or DSL service).
But I still havn't been able to find anything that should relate to random reboots on x86 FreeBSD on x86 compatible hardware and x86 compatible hypervisor.
The only circumstance where I'm aware of that happening is where the OS in the VM is 32 bit, but the VM is set to 64 bit at the hypervisor level.
Regardless, you're best off with 64 bit. Guessing you just need to make sure to either keep the WAN MAC the same, or do whatever you need to do for your type of Internet service to switch the MAC.
-
Yes, new VM ofc. I talked to my ISP before i tried to change last time about the ARP Cache and they told me "You can just change firewall, nothing needs to be done from our side".
This VM is ofc set to x86 on hypervisor, and i hate spoofing L2 adresses - wich also - regarding to ISP shouldn't matter.
-
who said anything about spoofing mac - if you change the mac of the device connected to the modem. You quite often have to power cycle the modem to clear its old cache and work with the new mac. Or you can do what I do and use the same mac on your different copies of your pfsense vm (never on at the same time) but this allows to keep the same public IP. This allows me to test with different versions, etc. Even if playing with different distro I set the mac the same on the wan interface so I keep the public IP.
