PFSense 2.0 Beta5 1/19 build system locks up
-
locks up on boot using new kernel, any way to get this back or is a reinstall necessary?
-
You might be able to unplug all the network interfaces, boot it up, and then switch back to the SMP kernel:
http://doc.pfsense.org/index.php/Switching_Kernels
-
ok, booting in safe mode I was able to get back to the smp kernel. Does the new dev kernel rely on any other dependencies? I am running Jan-26 snap, upgrading to Jan-27 right now. As I understand in the other kernel panic thread this new kernel will put a crash dump for debugging on the filesystem, so it is probably worthwhile for me to do, just need to know the order in which to do things. Thanks!
-
Actually the crash dumps aren't in the current snapshots, they're in the ones building now (there was one more thing I had to fix)
The kernel.gz referenced in the other thread doesn't require anything other than being on a recent snapshot.
-
ok, will wait for next snapshot then :)
-
Still freezes when I try to connect to FTP.
2.0-BETA5 (i386)
built on Thu Jan 27 20:55:04 EST 2011 -
Can you please try a snapshot from 28-JAN?
-
Freezing again!
2.0-BETA5 (i386)
built on Fri Jan 28 05:30:15 EST 2011 -
Just to chime in, I had a freezing system that I upgraded yesterday that was previously on a snapshot from November. When I brought it up to date it started freezing, sometimes in 20 min or less, sometimes not for over an hour. I had to revert as it was production. Unfortunately I'm not sure what the cause is, it's a reasonably large network, though I would think it unlikely that FTP was happening at that specific time (could be wrong). They do not use PPTP at all, it's not configured or enabled. However, they use IPsec site-to-site (with more configured, but only one site-to-site tunnel was up), and also use one VLAN, which are the "nonstandard" things I can think of. It's a P4 2.4 box with the i386 single-processor kernel and it was installed on a Promise mirror at the time (I rebuilt it using a GeoM mirror when I reverted though).
Another system, a VM this time on ESXi 4.0, started locking up as soon as it went into production after several hours. I had to revert to the old solution (Endian) there temporarily. That was at our main office, also production, and hard to know what was going on on the network; we do computer repair so at any given time our customer computers can be spewing who-knows-what :-)
-
BTW can all here execute sysctl debug.pfftpproxy=1 and report if the hangs continue?
-
doing it now, had two hangs this morning just prior to upgrading to Jan 28 snap. both master and slave pretty much hung at the same time, leading me to believe that it could be traffic type related.
-
also i face this problem, lockups and freeze, I update my server in 21/1/2011,
then i face this problem, and update to Tue Jan 25 06:07:53 EST 2011 and face it also.
i think the problem in Jan 19 and above.
thanks -
-
so is the current thinking on this FTP traffic? I do not have an FTP server so is this outbound FTP connections? Please let me know if there are configs, system logs, pretty much anything I can provide or do to assist in getting this cleared up. If I have any more lockups I will be forced to load up 1.2.3 release unfortunately.
-
I've only been able to replicate it when acting as an FTP client. And it's fairly erratic, I could hang a testing VM up solid earlier today but I came back to get some captures and do some in-depth analysis and now I can't hang it.
-
jimp, just i tell thank all version after 19/1/2011 have this problem.
I back to 2.0-BETA5 (i386) built on Wed Jan 19 02:10:47 EST 2011.
pfSense-Full-Update-2.0-BETA5-i386-20110118-2149.gz <=== this version not has any problem.
thanks -
Just found something else funny, the reason I couldn't hang my VM is that I switched it to the dev kernel. I switched back to the SMP kernel and I can hang it again.
So something about the dev kernel is making it less prone to hangs. (Can't say it's immune, haven't tested it long enough)
-
I switched back to the SMP kernel and I can hang it again.
FYI, the physical machine that was hanging last night was, I believe, running the single processor kernel. It definitely is now after I reinstalled the old snapshot, but since there's just one 2.4GHz P4 in there I did the single proc kernel (not sure if I should use the multi-proc kernel if it's a hyperthreaded proc or not).
-
Generally it's best to use the SMP kernel everywhere, even on single CPU machines. In the past that wasn't recommended, but the limitations don't really exist anymore (we've talked about dropping the UP kernel altogether but haven't yet done it, just in case…)
-
OK I hadn't seen anything about it so I just followed what was physically in the machine during the install process. I will keep that in mind though. Is it worth specifically switching in this case? I know I can drop in the SMP one without reinstalling if I look up the steps.
