Jump to content

kingfetty

Members
  • Content Count

    83
  • Joined

  • Last visited

Community Reputation

1 Neutral

About kingfetty

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

  1. It's gotta be software at this point. I've had this issue since 6.6.7 and was convinced it was hardware. Alas, I have replaced every single piece of hardware and still get kernel panic NF_NAT IPTables about once a week. I'm not sure where to go from here. I don't have a log file of the kernel panic as once it panics and you reboot, the logs are gone. I'm attaching a diagnostic file, and will await instruction on what to do next. tower-diagnostics-20190705-0148.zip
  2. Bug Description: When using quotes " in the value of a variable for a docker container the UI does not parse the line correctly when reading the xml file. How to reproduce: Create a docker and add a variable called test. Set the value of the variable to something that contains quotes. (ex: this"is"my value ). Then edit the container configuration. Upon editing the value will be depicted as truncate where the quotes began. (ex: this ) Expected results: Quotes should be parsed and represented html safe encoding " Actual results: Quotes are not parsed correctly. Other information: Examining the xml file shows that it is stored correctly the first time it is entered but not parsed correctly when editing.
  3. I too would like this to work. Currently I have a script that I run each time I reboot the box that creates my networks. I have to do this manually though.
  4. I've created some custom docker network entries. How does one persist them between unraid restarts?
  5. Help, Fresh install of the docker. Made sure the /config mapping is correct, made sure the UID and GID map to correct ID numbers from unraid. On startup the MongoDB server won't run, it crashes with a fatal assertion: LogFile::synchronousAppend failed with 8192 bytes unwritten out of 8192 bytes; b=0x3786000 errno:22 Invalid argument 2017-12-25T20:30:41.286-0600 [initandlisten] Fatal Assertion 13515 2017-12-25T20:30:41.291-0600 [initandlisten] 0xedb3e9 0xe6fb3f 0xe4a1c1 0xe7039b 0x8869fa 0x886f3a 0x88ea86 0x87d184 0x61f92f 0x620903 0x5e943c 0x2b47beb77830 0x61a2d9 bin/mongod(_ZN5mongo15printStackTraceERSo+0x39) [0xedb3e9] bin/mongod(_ZN5mongo10logContextEPKc+0x21f) [0xe6fb3f] bin/mongod(_ZN5mongo13fassertFailedEi+0x71) [0xe4a1c1] bin/mongod(_ZN5mongo7LogFile17synchronousAppendEPKvm+0x29b) [0xe7039b] bin/mongod(_ZN5mongo3dur20_preallocateIsFasterEv+0x22a) [0x8869fa] bin/mongod(_ZN5mongo3dur19preallocateIsFasterEv+0x2a) [0x886f3a] bin/mongod(_ZN5mongo3dur16preallocateFilesEv+0x966) [0x88ea86] bin/mongod(_ZN5mongo3dur7startupEv+0x74) [0x87d184] bin/mongod(_ZN5mongo14_initAndListenEi+0x76f) [0x61f92f] bin/mongod(_ZN5mongo13initAndListenEi+0x23) [0x620903] bin/mongod(main+0x23c) [0x5e943c] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x2b47beb77830] bin/mongod(_start+0x29) [0x61a2d9] 2017-12-25T20:30:41.291-0600 [initandlisten] ***aborting after fassert() failure ---- Edit ---- More info, to help tshoot. I have verified file permissions match up, plus it's obviously writing out the files to the /appdata/unifi folder as I'm able to get the logs. It's not a port issue as I have mapped it to it's own IP address on a seperate NIC and I'm able to ping the unique IP for the container. I have tried to wipe the /appdata/unifi folder and restart and just repeats with the same errors over and over. I cannot let it run for long as the log files get gigantic. I have tried wiping the image and redownloading with no luck. I saw before someone else had the same error and had to switch to another docker image, that docker image is what I'm trying to move away from as it has several bugs of it's own. --- Edit 2 ---- From what I can tell this is an error that the MongoDB can't write out correctly. Which is strange as it's creating all the files and the log files. Is there a specific filesystem format that has to exist for this to run? My cache drive (where appdata is) is formatted as XFS. ---Edit 3--- It just started working after stopping and starting enough times. Truly odd.
  6. It would be nice to have some way to use VLAN tagging or implement VSwitch support. With unRAID now having the ability to act as a hypervisor with KVM it becomes necessary to manipulate the networking components.
  7. My unraid is running super sluggish due to a process "kworker/u16:19" eating all the cpu. It's so bad I can't even stop the array gracefully.
  8. Documented in the defect reports thread with work around documented: https://lime-technology.com/forum/index.php?topic=41650.0
  9. If you have multiple USB devices with the same Vendor and Product then the passthrough does not work as the UI currently builds the XML file with USB based on the Vendor / Product and not the Address Bus= Device= syntax. Since this is the case if you attempt to passthrough any usb devices that have duplicate Vendor/Product you will not be able to start your VM. The workaround is to manually edit the xml to the Address syntax. Examples: Bus 011 Device 003: ID 08bb:2704 Texas Instruments Audio Codec Bus 011 Device 002: ID 08bb:2704 Texas Instruments Audio Codec Current Syntax: <hostdev mode='subsystem' type='usb' managed='yes'> <source > <vendor id='0x08bb'/> <product id='0x2704'/> </source> </hostdev> This will result in a non booting VM Fixed Syntax: <hostdev mode='subsystem' type='usb' managed='yes'> <source> <address bus='11' device='2'/> </source> </hostdev>
  10. Looks like it's fixed in the latest RC. I've been running solid for a week with bridging enabled.
  11. All this fuss over Realtek vs Intel is pointless as the same issues occur on my Intel NIC as well. I went out and purchased the Intel as requested at the beginning of this thread. It did not alleviate the issues at all. The only thing that corrects the issues is to disable bridging support. Right now in order to get around this, I have purchased a physical NIC for each VM and I am passing through the NIC to each VM. I tried going the tunneling route instead of physical NICs but it seems the tunnel support is not in the kernel. The downside of the physical NIC being 2-fold. 1: Usage of all my PCI/USB slots. 2: Access to the array now has to go through the physical network.
  12. Well, RC2 still has the same issues. Back to Beta 12. How is it a Release Candidate with a large bug like this?
  13. So, I finally made the move to 15 to test. I didn't even make it past 18 hours before the network puked out on me. Looks like it's time to go back to 12 again. Exact same symptoms as previous builds. It appears to still be tied to the bridge interface. -- Edit -- Just saw an RC version hit, gonna upgrade to that and see if the bug still exists
  14. Thanks, was just going to ask about beta 15 before upgrading, you have saved me some time. Does anyone know if this issue is even being worked on? I'd hate to be stuck at beta 12 forever.