pmcnano

Members
  • Posts

    25
  • Joined

  • Last visited

Posts posted by pmcnano

  1. I was just looking for something like this. Thanks! 

     

    That being said, your unraid template is missing somethings...I will try to fix it and submit a PR to your repo.

     

    Edit: It's actually all okay, the thing is, and I'm not sure how to fix, since the ports are not specified, the docker app doesn't offer to open the web gui. But just going to the port 8090 works fine. 

    Probably worth allowing the user to specify which port is going to use.

    And I thiiink maybe the app icon has to be PNG but not entirely sure.

     

    Edit2: Seems like the database is reset after restarting the container? I assume is because it's not being stored in the appdata.

     

    Edit3: Sorry for all the edits. Added a path mapping, /app/pb_data to my appdata folder and the database is now persisted.

  2. Just as an FYI, this image gave me the answer:

     q8A1iab.png

     

    I don't recall ever moving my docker "Host access to custom networks" setting, but it's enabled. I have a feeling it was auto-enabled at some point by an update or something else.

    And per that table, it won't work with NAT = true.

    Since I didn't want to stop all my docker containers, I went with the last option, and added my static routes with NAT= false and my problems were solved. 

  3. Hey @ich777 thanks for your apps!

     

    I tried looking for any repo I could just push a fix for this but couldn't find it. Either way, your mindustry "app" says the following:

     

    CONSOLE: To connect to the console open up the terminal for this docker and type in: 'docker exec -u terraria -ti NAMEOFYOURCONTAINER screen -xS Mindustry' (without quotes).

    The user is "mindustry" actually. :)

    • Like 1
  4. 6 hours ago, FoxxMD said:

    @pmcnano it looks like this is a known issue (and not an issue with the unraid template)

    Ah, thanks! You are right. Tho, the last post does mention it works fine with sqlite, which is what we are using, no?

     

    Edit: Tried with postgres and same thing, also commented on that post. I also found a post saying it might be permission issues with the data directory, but they seem to be root already. I will keep an eye on that issue. Thanks!

  5. 5 hours ago, runraid said:

    I got this figured out and am able to use the MariaDB inside the container to make this work. No need to run a dedicated MariaDB docker instance.

     

    First, make sure the shinobipro docker container is running. Log into the console of the container, either by using the unraid feature or by this command:

    
    docker exec -ti shinobipro sh

    Next, create the database and tables...

     

    
    mysql
    source sql/framework.sql;
    source sql/user.sql;
    exit

    Now restart the container and it will work.

    Yup, it does suck a bit, something changed and my database got corrupted with the update a week ago, I Spent days trying to fix it and reinstalling didn't work either.

     

    Ended up doing above. I feel like @SpaceInvaderOne missed something in the update but I don't think he has connected in a while. We'll see, I had to setup my cameras again but I have it all working again.

     

  6. Since the update last night I am getting an error, I tried what @SpaceInvaderOne suggested for another problem a couple of replies before, but it didn't work. I removed the template and reinstalled, same error.

     

    2020-05-14 17:06:31 11 [ERROR] mysqld: Incorrect information in file: './ccio/Presets.frm'
    
    Error: ER_NOT_FORM_FILE: Incorrect information in file: './ccio/Presets.frm'
    
    at Query.Sequence._packetToError (/opt/shinobi/node_modules/mysql/lib/protocol/sequences/Sequence.js:47:14)
    at Query.ErrorPacket (/opt/shinobi/node_modules/mysql/lib/protocol/sequences/Query.js:79:18)
    at Protocol._parsePacket (/opt/shinobi/node_modules/mysql/lib/protocol/Protocol.js:291:23)
    at Parser._parsePacket (/opt/shinobi/node_modules/mysql/lib/protocol/Parser.js:433:10)
    at Parser.write (/opt/shinobi/node_modules/mysql/lib/protocol/Parser.js:43:10)
    at Protocol.write (/opt/shinobi/node_modules/mysql/lib/protocol/Protocol.js:38:16)
    at Socket.<anonymous> (/opt/shinobi/node_modules/mysql/lib/Connection.js:88:28)
    at Socket.<anonymous> (/opt/shinobi/node_modules/mysql/lib/Connection.js:526:10)
    at Socket.emit (events.js:223:5)
    at addChunk (_stream_readable.js:309:12)
    at readableAddChunk (_stream_readable.js:290:11)
    at Socket.Readable.push (_stream_readable.js:224:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:181:23)
    --------------------
    at Protocol._enqueue (/opt/shinobi/node_modules/mysql/lib/protocol/Protocol.js:144:48)
    at Connection.query (/opt/shinobi/node_modules/mysql/lib/Connection.js:198:25)
    at /opt/shinobi/node_modules/knex/lib/dialects/mysql/index.js:130:18
    at Promise._execute (/opt/shinobi/node_modules/bluebird/js/release/debuggability.js:384:9)
    at Promise._resolveFromExecutor (/opt/shinobi/node_modules/bluebird/js/release/promise.js:518:18)
    at new Promise (/opt/shinobi/node_modules/bluebird/js/release/promise.js:103:10)
    at Client_MySQL._query (/opt/shinobi/node_modules/knex/lib/dialects/mysql/index.js:124:12)
    at Client_MySQL.query (/opt/shinobi/node_modules/knex/lib/client.js:158:17)
    at Runner.query (/opt/shinobi/node_modules/knex/lib/runner.js:135:36)
    at /opt/shinobi/node_modules/knex/lib/runner.js:39:23
    at tryCatcher (/opt/shinobi/node_modules/bluebird/js/release/util.js:16:23)
    at /opt/shinobi/node_modules/bluebird/js/release/using.js:185:26
    at tryCatcher (/opt/shinobi/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/opt/shinobi/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/opt/shinobi/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/opt/shinobi/node_modules/bluebird/js/release/promise.js:649:10) {
    code: 'ER_NOT_FORM_FILE',
    errno: 1033,
    sqlMessage: "Incorrect information in file: './ccio/Presets.frm'",
    sqlState: 'HY000',
    index: 0,
    sql: 'ALTER TABLE `Presets` CHANGE COLUMN `type` `type` VARCHAR(50) NULL DEFAULT NULL AFTER `details`;'
    }
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    This Install of Shinobi is NOT Activated
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    2020-05-14T17:06:33-05:00 This Install of Shinobi is NOT Activated

     

  7. 1 minute ago, bonienl said:

    This doesn't work with WireGuard.

    WireGuard is designed to remain silent unless it is a true WireGuard connection set up.

     

    I'm sorry but it actually works for me. I just checked both my tunnels and they are detected a open. 

  8. 4 minutes ago, musicking said:

    Yes to Static IP in Unraid as per the pictures above.
    Other ports (docker containers are reachable via letsencrypt docker/reverse proxy)

     

    I am enabling logging on the router now, but other rules are working fine.

     

    Did you have the Intel reboot issue on 6.8.1? I'm wondering if the change to fix this broke my wireguard in 6.8.2

    Honestly, I don't see this has been mentioned. But have you checked that the UDP port is opened? 

  9. 7 hours ago, bonienl said:

    If remote connection is completely lost, a solution can be to enable syslog mirroring to the flash device. See Settings -> Syslog Server

    This saves a copy of your syslog information on the flash device in the /logs folder.

     

    If you still can SSH (telnet) into your system, you can manually start diagnostics by typing

    
    diagnostics

     

     

    Hey, so, disabled my bond, I actually just used eth0. Briding enabled only for eth0 too. Same thing happened, I tried grabbing diagnostics, but it said (https://share.getcloudapp.com/WnuE0Ljd):

    Starting diagnostics collection...

    I waited for 40 minutes and nothing, just more kernel panics in the logs. Here are the logs (pastebin as it's pretty large, same KP over and over again as far as I can tell): https://pastebin.com/gQd8P7Zt

     

    Thanks!

     

    edit: I created a new diagnostics set, from console after the restart and it took 5 seconds, so yeah. Attaching it in case it helps with anything.

    tower-diagnostics-20200105-1932.zip

  10. 8 hours ago, bonienl said:

    Please try with bonding disabled and only use bridging for eth0.

     

    Your attached diagnostics are from AFTER rebooting the system, we need diagnostics BEFORE you reboot and while the system is having the issue.

    I will try that, question tho, how would I get the diagnostics before, if I can't access it?

     

    Thanks!

  11. 1 hour ago, ich777 said:

    Thank you! New corrected container is in the next few minutes available. ;)

    You are must welcome! Happy new year.

     

    Edit- Sorry to be a pain, but it still not working. The "basicjre.gzip.tar" extracts a "jre1.8.0_231" folder, and it's trying to find the java bin in the "basicjre" folder.  Again, I just fixed it by renaming the folder.

     

    Pushed a PR in your repo.

    • Like 1
  12. Hello, I started testing this yesterday. I added 3 different tunnels. I have 2 wans, so:

    - 1 Remote access to lan through wan1

    - 1 Remote access to lan through wan2

    - 1 Remove tunneled access through the wan1

     

    I can connect and everything works perfectly fine, but it looks like when I disconnect and reconnect, or just connect with another tunnel, my server's network dies. I can't ping it anymore and there's some kernel panic logs:

     

    Jan 1 21:09:34 Tower kernel: ------------[ cut here ]------------
    Jan 1 21:09:34 Tower kernel: NETDEV WATCHDOG: eth1 (igb): transmit queue 1 timed out
    Jan 1 21:09:34 Tower kernel: WARNING: CPU: 23 PID: 0 at net/sched/sch_generic.c:465 dev_watchdog+0x161/0x1bb
    Jan 1 21:09:34 Tower kernel: Modules linked in: wireguard ip6_udp_tunnel udp_tunnel nvidia_uvm(O) arc4 ecb md4 sha512_ssse3 sha512_generic cmac cifs ccm xt_CHECKSUM ipt_REJECT ip6table_mangle ip6table_nat nf_nat_ipv6 iptable_mangle ip6table_filter ip6_tables xt_nat vhost_net tun vhost tap veth ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat ip_tables xfs md_mod nct6775 hwmon_vid k10temp bonding igb i2c_algo_bit edac_mce_amd kvm_amd nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) ipmi_ssif kvm crct10dif_pclmul rsnvme(PO) crc32_pclmul crc32c_intel drm_kms_helper ghash_clmulni_intel drm pcbc aesni_intel agpgart wmi_bmof syscopyarea aes_x86_64 crypto_simd cryptd ahci sysfillrect sysimgblt ccp sr_mod pcc_cpufreq fb_sys_fops i2c_piix4 glue_helper libahci button ipmi_si cdrom acpi_cpufreq nvme i2c_core nvme_core
    Jan 1 21:09:34 Tower kernel: wmi [last unloaded: i2c_algo_bit]
    Jan 1 21:09:34 Tower kernel: CPU: 23 PID: 0 Comm: swapper/23 Tainted: P O 4.19.88-Unraid #1
    Jan 1 21:09:34 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X470D4U, BIOS P3.20 08/12/2019
    Jan 1 21:09:34 Tower kernel: RIP: 0010:dev_watchdog+0x161/0x1bb
    Jan 1 21:09:34 Tower kernel: Code: 71 94 00 00 75 39 48 89 ef c6 05 38 71 94 00 01 e8 85 a8 fd ff 44 89 e9 48 89 ee 48 c7 c7 49 1f da 81 48 89 c2 e8 8f 1b af ff <0f> 0b eb 11 41 ff c5 48 81 c2 40 01 00 00 41 39 cd 75 95 eb 13 48
    Jan 1 21:09:34 Tower kernel: RSP: 0018:ffff888ffebc3ea0 EFLAGS: 00010286
    Jan 1 21:09:34 Tower kernel: RAX: 0000000000000000 RBX: ffff888ff679c438 RCX: 0000000000000007
    Jan 1 21:09:34 Tower kernel: RDX: 00000000000005be RSI: 0000000000000002 RDI: ffff888ffebd64f0
    Jan 1 21:09:34 Tower kernel: RBP: ffff888ff679c000 R08: 0000000000000003 R09: 000000000001cd00
    Jan 1 21:09:34 Tower kernel: R10: 0000000000000000 R11: 0000000000000058 R12: ffff888ff679c41c
    Jan 1 21:09:34 Tower kernel: R13: 0000000000000001 R14: ffff888ff39ee940 R15: 0000000000000017
    Jan 1 21:09:34 Tower kernel: FS: 0000000000000000(0000) GS:ffff888ffebc0000(0000) knlGS:0000000000000000
    Jan 1 21:09:34 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jan 1 21:09:34 Tower kernel: CR2: 00007ffbffff8fc8 CR3: 0000000f93166000 CR4: 0000000000340ee0
    Jan 1 21:09:34 Tower kernel: Call Trace:
    Jan 1 21:09:34 Tower kernel: <IRQ>
    Jan 1 21:09:34 Tower kernel: call_timer_fn+0x18/0x7b
    Jan 1 21:09:34 Tower kernel: ? qdisc_reset+0xc0/0xc0
    Jan 1 21:09:34 Tower kernel: expire_timers+0x7e/0x8d
    Jan 1 21:09:34 Tower kernel: run_timer_softirq+0x72/0x120
    Jan 1 21:09:34 Tower kernel: ? enqueue_hrtimer.isra.0+0x23/0x27
    Jan 1 21:09:34 Tower kernel: ? __hrtimer_run_queues+0xdd/0x10b
    Jan 1 21:09:34 Tower kernel: ? ktime_get+0x44/0x95
    Jan 1 21:09:34 Tower kernel: __do_softirq+0xc9/0x1d7
    Jan 1 21:09:34 Tower kernel: irq_exit+0x5e/0x9d
    Jan 1 21:09:34 Tower kernel: smp_apic_timer_interrupt+0x80/0x93
    Jan 1 21:09:34 Tower kernel: apic_timer_interrupt+0xf/0x20
    Jan 1 21:09:34 Tower kernel: </IRQ>
    Jan 1 21:09:34 Tower kernel: RIP: 0010:cpuidle_enter_state+0xe8/0x141
    Jan 1 21:09:34 Tower kernel: Code: ff 45 84 f6 74 1d 9c 58 0f 1f 44 00 00 0f ba e0 09 73 09 0f 0b fa 66 0f 1f 44 00 00 31 ff e8 e0 99 bb ff fb 66 0f 1f 44 00 00 <48> 2b 2c 24 b8 ff ff ff 7f 48 b9 ff ff ff ff f3 01 00 00 48 39 cd
    Jan 1 21:09:34 Tower kernel: RSP: 0018:ffffc90006423e98 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
    Jan 1 21:09:34 Tower kernel: RAX: ffff888ffebdfac0 RBX: ffff888ff1fd6400 RCX: 000000000000001f
    Jan 1 21:09:34 Tower kernel: RDX: 0000000000000000 RSI: 0000000021bf5be5 RDI: 0000000000000000
    Jan 1 21:09:34 Tower kernel: RBP: 000038ac8d05b99b R08: 000038ac8d05b99b R09: 00000000000003b2
    Jan 1 21:09:34 Tower kernel: R10: 00000000000ac1b8 R11: 071c71c71c71c71c R12: 0000000000000001
    Jan 1 21:09:34 Tower kernel: R13: ffffffff81e5e260 R14: 0000000000000000 R15: ffffffff81e5e2d8
    Jan 1 21:09:34 Tower kernel: ? cpuidle_enter_state+0xbf/0x141
    Jan 1 21:09:34 Tower kernel: do_idle+0x17e/0x1fc
    Jan 1 21:09:34 Tower kernel: cpu_startup_entry+0x6a/0x6c
    Jan 1 21:09:34 Tower kernel: start_secondary+0x197/0x1b2
    Jan 1 21:09:34 Tower kernel: secondary_startup_64+0xa4/0xb0
    Jan 1 21:09:34 Tower kernel: ---[ end trace 47c27e2823999dc7 ]---
    Jan 1 21:09:34 Tower kernel: igb 0000:24:00.0 eth1: Reset adapter

     

    If I wait a bit, it ends up resetting the adapter and I get a ping response again, however I can't access the UI or anything, there's another kernel panic in the logs immediatelly.

     

    Jan 1 21:09:34 Tower kernel: igb 0000:24:00.0 eth1: Reset adapter
    Jan 1 21:09:35 Tower kernel: igb 0000:24:00.0 eth1: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    Jan 1 21:09:37 Tower kernel: igb 0000:24:00.0: exceed max 2 second
    Jan 1 21:10:25 Tower kernel: rcu: INFO: rcu_sched self-detected stall on CPU
    Jan 1 21:10:25 Tower kernel: rcu: 1-....: (60028 ticks this GP) idle=3d2/1/0x4000000000000002 softirq=7551290/7551290 fqs=14516
    Jan 1 21:10:25 Tower kernel: rcu: (t=60000 jiffies g=22102957 q=73124)
    Jan 1 21:10:25 Tower kernel: NMI backtrace for cpu 1
    Jan 1 21:10:25 Tower kernel: CPU: 1 PID: 8154 Comm: kworker/1:2 Tainted: P W O 4.19.88-Unraid #1
    Jan 1 21:10:25 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X470D4U, BIOS P3.20 08/12/2019
    Jan 1 21:10:25 Tower kernel: Workqueue: wg-kex-wg2 wg_packet_handshake_receive_worker [wireguard]
    Jan 1 21:10:25 Tower kernel: Call Trace:
    Jan 1 21:10:25 Tower kernel: <IRQ>
    Jan 1 21:10:25 Tower kernel: dump_stack+0x67/0x83
    Jan 1 21:10:25 Tower kernel: nmi_cpu_backtrace+0x71/0x83
    Jan 1 21:10:25 Tower kernel: ? lapic_can_unplug_cpu+0x97/0x97
    Jan 1 21:10:25 Tower kernel: nmi_trigger_cpumask_backtrace+0x57/0xd4
    Jan 1 21:10:25 Tower kernel: rcu_dump_cpu_stacks+0x8b/0xb4
    Jan 1 21:10:25 Tower kernel: rcu_check_callbacks+0x296/0x5a0
    Jan 1 21:10:25 Tower kernel: update_process_times+0x24/0x47
    Jan 1 21:10:25 Tower kernel: tick_sched_timer+0x36/0x64
    Jan 1 21:10:25 Tower kernel: __hrtimer_run_queues+0xb7/0x10b
    Jan 1 21:10:25 Tower kernel: ? tick_sched_handle.isra.0+0x2f/0x2f
    Jan 1 21:10:25 Tower kernel: hrtimer_interrupt+0xf4/0x20e
    Jan 1 21:10:25 Tower kernel: smp_apic_timer_interrupt+0x7b/0x93
    Jan 1 21:10:25 Tower kernel: apic_timer_interrupt+0xf/0x20
    Jan 1 21:10:25 Tower kernel: </IRQ>
    Jan 1 21:10:25 Tower kernel: RIP: 0010:get_random_u32+0xd/0x89
    Jan 1 21:10:25 Tower kernel: Code: 50 01 89 53 40 48 8b 04 c3 48 89 04 24 e8 0b 7d 28 00 48 8b 04 24 5a 5b 5d 41 5c c3 c3 0f 1f 44 00 00 ba 0a 00 00 00 0f c7 f0 <72> 79 ff ca 75 f7 41 54 48 c7 c2 b0 9f 29 82 48 c7 c7 80 66 c6 81
    Jan 1 21:10:25 Tower kernel: RSP: 0018:ffffc9000d4cbd28 EFLAGS: 00000203 ORIG_RAX: ffffffffffffff13
    Jan 1 21:10:25 Tower kernel: RAX: 00000000ffffffff RBX: ffff8889c7b7b2c8 RCX: 0000000000000000
    Jan 1 21:10:25 Tower kernel: RDX: 000000000000000a RSI: 00000000fffffe01 RDI: ffffffffa02a1f38
    Jan 1 21:10:25 Tower kernel: RBP: ffff8889bb300000 R08: ffffffffa02c89e0 R09: ffffc9000d4cbd18
    Jan 1 21:10:25 Tower kernel: R10: ffffc9000d4cbe18 R11: 007e315c0363396c R12: ffff8889bb310000
    Jan 1 21:10:25 Tower kernel: R13: ffff8889c7b7b2d0 R14: ffffc9000d4cbd68 R15: ffff8889c7b7b3a0
    Jan 1 21:10:25 Tower kernel: ? wg_index_hashtable_insert+0x48/0x100 [wireguard]
    Jan 1 21:10:25 Tower kernel: wg_index_hashtable_insert+0x58/0x100 [wireguard]
    Jan 1 21:10:25 Tower kernel: wg_noise_handshake_create_response+0x23e/0x260 [wireguard]
    Jan 1 21:10:25 Tower kernel: wg_packet_send_handshake_response+0x3f/0xd0 [wireguard]
    Jan 1 21:10:25 Tower kernel: wg_packet_handshake_receive_worker+0x93/0x290 [wireguard]
    Jan 1 21:10:25 Tower kernel: process_one_work+0x16e/0x24f
    Jan 1 21:10:25 Tower kernel: worker_thread+0x1e2/0x2b8
    Jan 1 21:10:25 Tower kernel: ? rescuer_thread+0x29e/0x29e
    Jan 1 21:10:25 Tower kernel: kthread+0x10c/0x114
    Jan 1 21:10:25 Tower kernel: ? kthread_park+0x89/0x89
    Jan 1 21:10:25 Tower kernel: ret_from_fork+0x22/0x40

     

    I know the build is not stable, but I just wanted to know if I it's just that, or is there something else going on?

     

    Also attaching my diagnostics.

     

    Thank you.

    tower-diagnostics-20200101-2117.zip