UVM restarting randomly on works new router?

[jlficken]

I guess I just hoped that since it's the same hardware that I run at home that it'd work at the office too.

The physical machine was completely replaced with a unit direct from Supermicro. The RAM has been replaced as well and it's the same kit that I run at home. The SSD has been completely replaced as well with a new install where I only imported the config.

I really don't think there's a compatibility issue as I've been running the same setup hardware wise at home for almost a year now with the only difference being I'm using a Micron SSD vs a Samsung.

I also don't really want to start taking parts from my machine at home either so I guess we are just left with random reboots for now.

I may just download OPNsense and see if it acts any differently. I just don't know how to either confirm or eliminate Untangle as being the issue unless I try another router OS.

The only other thing I can come up with is to reset to factory defaults in Untangle and configure it from scratch again.

I'll look thru the logs but they haven't proven to be helpful thus far.

[jlficken]

This is all that shows in Messages for the time it rebooted.

Aug 20 15:37:23 5018D-FN8T-AO kernel: [337293.479609] WARNING (unknown src intf):IN=ppp2 OUT= MAC= SRC=198.18.0.4 DST=224.0.0.22 LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=23854 PROTO=2
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] Linux version 4.9.0-9-untangle-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u3+untangle1 (2019-02-27)
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-untangle-amd64 root=/dev/sda1 ro net.ifnames=0 ramdisk_size=100000 lang=us apm=power-off nomce nodhcp nofstab panic=5 quiet splash
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Aug 20 15:37:23 5018D-FN8T-AO kernel: [337293.431015] WARNING (unknown src intf):IN=ppp2 OUT= MAC= SRC=198.18.0.4 DST=255.255.255.255 LEN=96 TOS=0x00 PREC=0x00 TTL=128 ID=23491 PROTO=UDP SPT=137 DPT=137 LEN=76
Aug 20 15:37:23 5018D-FN8T-AO kernel: [337293.479609] WARNING (unknown src intf):IN=ppp2 OUT= MAC= SRC=198.18.0.4 DST=224.0.0.22 LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=23854 PROTO=2
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] Linux version 4.9.0-9-untangle-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u3+untangle1 (2019-02-27)
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-untangle-amd64 root=/dev/sda1 ro net.ifnames=0 ramdisk_size=100000 lang=us apm=power-off nomce nodhcp nofstab panic=5 quiet splash
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Aug 20 16:29:11 5018D-FN8T-AO kernel: [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256

Aug 20 15:37:23 5018D-FN8T-AO kernel: [337293.430943] WARNING (unknown src intf):IN=ppp2 OUT= MAC= SRC=198.18.0.4 DST=255.255.255.255 LEN=96 TOS=0x00 PREC=0x00 TTL=128 ID=23489 PROTO=UDP SPT=137 DPT=137 LEN=76

[sky-knight]

That's just normal boot messages.

Before you go too crazy, have you compared the two system's BIOS settings? Because the OS selector may be different, and if it is... change it!

There are three BIOS settings to manage:

SATA Operation Mode, OS, and EFI

Those three don't always have the same settings, but those are the three that on every platform need tinkered with until you find stability. You have a working example, so make sure the rebooting unit matches.

[jlficken]

Thanks for the tip!

What do you mean OS setting in the BIOS?

I think the SATA Operation Mode would be where I have it set to AHCI and the EFI would be the boot type being UEFI, LEGACY, or BOTH in the BIOS (mine was set to both with Legacy --SSD Info---) in the list after the USB Key.

[johnsonx42]

maybe it's something slightly different in the kernel. I saw you have a slightly older kernel at home, probably because it was installed awhile ago...
maybe try re-installing with a slightly older Untangle version, like 14.1.2 http://download.untangle.com/untangle_1412_x64.img and see if you get that same kernel as at home.
or clone the disk from the one at home, then restore your work config onto it?

[jlficken]

maybe it's something slightly different in the kernel. I saw you have a slightly older kernel at home, probably because it was installed awhile ago...
maybe try re-installing with a slightly older Untangle version, like 14.1.2 http://download.untangle.com/untangle_1412_x64.img and see if you get that same kernel as at home.
or clone the disk from the one at home, then restore your work config onto it?

I've been thinking this as well. I'll soon find out since I let my kernel update the other day.

The worst part about this is the waiting to see what if anything happens between changes.

For now I have disabled the tunnel that has 100GB+ of traffic per day for cameras and will be restarting to check the BIOS settings as sky-night mentioned when I can get a window to do so.

I may also try to source a different brand of SSD or use the spare 2.5" spinning rust drive that I have around.

[sky-knight]

Thanks for the tip!

What do you mean OS setting in the BIOS?

I think the SATA Operation Mode would be where I have it set to AHCI and the EFI would be the boot type being UEFI, LEGACY, or BOTH in the BIOS (mine was set to both with Legacy --SSD Info---) in the list after the USB Key.

Yes, there's sometimes an OS setting that will let you pick Linux, Android, or Windows. Then there's the SATA setting which is either Legacy or IDE Emulation, or AHCI. Then there's the UEFI or Legacy BIOS option

Not all platforms have all three, and somtimes they are combined. And not all of them will be set all of the same way. Some of my appliances need AHCI and others need Legacy SATA for example.

But, usually if the SATA mode is off, the platform just doesn't boot. This seems more like either a kernel issue, or an OS selector issue. On some of those tiny boxes, setting them to Android can fix things, but others you have to set them to Windows, which is weird because Linux almost never works for Linux. Meanwhile the platforms I've mucked about with, setting it for Linux allows Windows to work. I'm not sure WTF the BIOS is doing with that switch, but it's almost never what it should be.

Either way, testing an intermittent issue is always a pain in the rear.

But crap like this? Yeah... it almost bankrupted Nexgen. We don't sell Supermicro hardware anymore for this reason specifically. Between the random strangeness, and entire platforms just simply not being compatible with specific kernels, we ended up replacing almost a years worth of sales to keep people going. So never again... My appliance vendor isn't cheap, but their stuff always works and they stand behind it. So I can always service the things.

[jlficken]

Yes, there's sometimes an OS setting that will let you pick Linux, Android, or Windows. Then there's the SATA setting which is either Legacy or IDE Emulation, or AHCI. Then there's the UEFI or Legacy BIOS option

Not all platforms have all three, and somtimes they are combined. And not all of them will be set all of the same way. Some of my appliances need AHCI and others need Legacy SATA for example.

But, usually if the SATA mode is off, the platform just doesn't boot. This seems more like either a kernel issue, or an OS selector issue. On some of those tiny boxes, setting them to Android can fix things, but others you have to set them to Windows, which is weird because Linux almost never works for Linux. Meanwhile the platforms I've mucked about with, setting it for Linux allows Windows to work. I'm not sure WTF the BIOS is doing with that switch, but it's almost never what it should be.

Either way, testing an intermittent issue is always a pain in the rear.

But crap like this? Yeah... it almost bankrupted Nexgen. We don't sell Supermicro hardware anymore for this reason specifically. Between the random strangeness, and entire platforms just simply not being compatible with specific kernels, we ended up replacing almost a years worth of sales to keep people going. So never again...

That makes sense. I couldn't find anything OS type related in this Supermicro BIOS but I did find the others that you mentioned so I will verify they are the same on both machines and go from there.

Thanks again!

[jlficken]

Well, made it almost 8 days this time.

Off to dig thru logs again I guess.

This one is a bit different though as there aren't any lines of the weird @^ in syslog that I can find with vi.

[Telefonix]

I have a unit with IPsec VPN's restarting as well. What we found was when a certain remote user logged into the VPN from home it would cause a reboot. Logs weren't any help and just showed what the engineers said was a power related shutdown even though the system is on a UPS. Come to the conclusion that there is a bug in the IPSEC remote user feature.