Kaldek

Members
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

13 Good

About Kaldek

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. To update this topic for those using USB serial adapters (which I assume is realistically most of us), so far I have not managed to get kernel boot and shutdown messages to show but you can at least get the ability to login via the USB serial port. Essentially, you don't need the "SERIAL 0 115200" line, nor the changes to the "append" line" at all to get the ability to login via the USB serial adapter. Getting the ability to login via the USB to serial adapter only requires the addition to the /boot/config/go file as follows: sed -i -e "/^#s1/ i s1:12345:respawn:/sbin/agetty -
  2. Closed as this issue is related to my other post about the same problem with RC2. This is all caused by using a different IP address for my Shinobi Pro docker container running on a different VLAN (br0.12). Again, I think Limetech need to solve this issue as a matter of priority since it's been around since 6.5.
  3. This issue is not occurring now that I have moved Shinobi Pro to the normal bridge and sharing the same IP address as the unRAID host. I can only ask the unRAID team to work on and solve this issue since it appears to have been around since 6.5.
  4. OK I've changed Shinobi to use the normal bridge, no VLANs. Traffic between Shinobi and the cameras is now being routed. Let's see how stable it is.
  5. I will add that Shinobi is running on a separate VLAN which is a subinterface of br0 (br0.12) and that br0 is a bridge on an Intel 10Gb/s NIC using the ixgbe module.
  6. These keep cropping up on RC2. I've had a couple of callbacks related to netfilter, as well as some kernel panics. Two examples posted as well as my diagnostics file, however note that at the time of this diag file I had stopped my Shinobi Pro docker container which I could swear is the catalyst. I am leaving Shinobi disabled to see if unRAID stays up longer. I mark this as "Urgent" only because system stability is really poor at the moment. mu-th-ur-diagnostics-20201222-1354.zip
  7. I for one would be happy to move to subscription licensing. Even if that means free upgrades for XXX years in one purchase, further cost if you want to upgrade after that. I get people's concern, but devs have to eat. As for the statement about not liking "forcing people to update", as an InfoSec guy that kind of thinking drives me mad. The amount of back doors and crap I have to deal with on a daily basis due to old software is ridiculous. I just spent the last 6 months fighting hard to ensure our desktop standard going forward is cloud-first, Azure AD Joined and up-to-t
  8. Got this rather odd Kernel Panic from unRAID 6.9.0-rc1 that appears to be caused by nf_nat_setup which is part of netfilter. mu-th-ur-diagnostics-20201214-0924.zip
  9. I'll add some experience here with Shinobi Pro. I recently downgraded my unRAID server from an i7-6950X to a Xeon E5-2630L and thought it would be a good idea to use the hardware decoding of my Quadro P400 GPU to save CPU cycles and therefore power consumption, plus leave more headroom for other containers and VMs. Anyway it turns out that this actually increased my power consumption and the stability of Shinobi was a bit all over the place. I suspect it was also the cause of it consuming all of my memory (prior to me setting an 8GB limit as discussed by others previously).
  10. This issue is solved by disabling PCI express ASPM.
  11. Never mind I just doubled the size of my docker image.
  12. Looks like this has been discovered before on the X99 chipset and the solution is to apply the boot flag of "pcie_aspm=off". I have set this, will monitor, and update this issue over the next couple of days if I no longer see these errors.