cholzer

Members
  • Posts

    164
  • Joined

  • Last visited

Posts posted by cholzer

  1. Maybe someone else can use this too. :)

    I have the Tailscale Docker running on Unraid (192.168.1.5).
    On Unraid I also run Plex as Docker with its IP set to 192.168.1.6.

    To access that Plex Docker through the Tailscale node simply add the following to the "UP-FLAGS" field in the Tailscale Docker.

    --advertise-routes=192.168.1.6/32


    Now u can access Plex by its IP 192.168.1.6 remotely through the Unraid Tailscale node. :) 

     

    I also recommend to enable the advanced view on the Tailscale docker and then add to the Extra Parameters. 

    --restart=unless-stopped

     

  2. My log looks like this:

     

    Sep 26 07:05:57 NAS kernel: vethbf83a3e: renamed from eth0
    Sep 26 07:05:58 NAS kernel: eth0: renamed from veth9c122b6
    Sep 26 07:06:01 NAS kernel: veth9c122b6: renamed from eth0
    Sep 26 07:06:02 NAS kernel: eth0: renamed from vethc115e45
    Sep 26 07:06:05 NAS kernel: vethc115e45: renamed from eth0
    Sep 26 07:06:07 NAS kernel: eth0: renamed from veth8833121
    Sep 26 07:06:10 NAS kernel: veth8833121: renamed from eth0
    Sep 26 07:06:13 NAS kernel: eth0: renamed from vethfcb7b12
    Sep 26 07:06:16 NAS kernel: vethfcb7b12: renamed from eth0
    Sep 26 07:06:23 NAS kernel: eth0: renamed from veth1941e91
    Sep 26 07:06:26 NAS kernel: veth1941e91: renamed from eth0
    Sep 26 07:06:39 NAS kernel: eth0: renamed from veth3a3e044
    Sep 26 07:06:43 NAS kernel: veth3a3e044: renamed from eth0
    Sep 26 07:07:09 NAS kernel: eth0: renamed from veth13b5a96
    Sep 26 07:07:11 NAS kernel: veth13b5a96: renamed from eth0
    Sep 26 07:08:03 NAS kernel: eth0: renamed from veth2a876ee
    Sep 26 07:08:06 NAS kernel: veth2a876ee: renamed from eth0
    Sep 26 07:09:06 NAS kernel: eth0: renamed from veth56008ba
    Sep 26 07:09:09 NAS kernel: veth56008ba: renamed from eth0
    Sep 26 07:10:10 NAS kernel: eth0: renamed from veth5587952
    Sep 26 07:10:13 NAS kernel: veth5587952: renamed from eth0
    Sep 26 07:11:13 NAS kernel: eth0: renamed from veth21b20a6
    Sep 26 07:11:16 NAS kernel: veth21b20a6: renamed from eth0
    Sep 26 07:12:16 NAS kernel: eth0: renamed from veth4e69dbb
    Sep 26 07:12:19 NAS kernel: veth4e69dbb: renamed from eth0

     

    I dont remember having seen this in the past.
    Only thing i changed resently was switching docker from macvlan to ipvlan - reason for this switch was that I still encountered crashes with macvlan in 6.12.4

     

    //edit - this was caused by a docker container being stuck in an endless restart loop

  3. 8 hours ago, Mainfrezzer said:

    Yes but there are 2 things that could stop it. 1. If the stream session isnt closed, it doesnt clean up after itself. 2. Depending on what kind of transcode quality youre trying to watch, 8,6GB isnt enough in size(especially if someone else is transcoding simultaneously). I think Plex does have "emergency trigger" which will clean up if the destination has not enough space anymore but it might be that the current available space is too much for plex to see the issue.


    The AppleTV is the only device which accesses my Plex Server and the transcoding is audio only as Video is direct streamed (Apple still refuses to support TrueHD / DTS-HD).
    So I thought that 8GB should be enough for this. But I have increased it to 16GB now.
    I wonder why Plex Server does not clean up after itself.

    However previously I have noticed that the transcode folder rarely reset in size while I was transcoding to an SSD. I always manually deleted the folder once a week.

  4. Quote

    2023-09-17 22:41:47.996     BTRFS error (device loop2): block=57999360 write time tree block corruption detected

    2023-09-17 22:41:47.996     BTRFS: error (device loop2) in btrfs_commit_transaction:2466: errno=-5 IO failure (Error while writing out transaction)

    2023-09-17 22:41:47.996     BTRFS info (device loop2: state E): forced readonly

    2023-09-17 22:41:47.996     BTRFS warning (device loop2: state E): Skipping commit of aborted transaction.

    2023-09-17 22:41:47.996     BTRFS: error (device loop2: state EA) in cleanup_transaction:1964: errno=-5 IO failure

     

    I upgraded to 6.12.4 last week, today I found this in the log. 

    It looks like my Code Server docker container is dead now, while the other containers are still working.
    2121183211_Screenshot2023-09-18071112.jpg.5bd29230dae5b3f73fcdd6955d7aeef7.jpg

    //edit okay, recreating the docker.img & restoring the containers was surprisingly easy.

     

    Why did this happen tho?
     

     

  5. 20 hours ago, ich777 said:

    Nope. On a bare metal system this shouldn't happen since I can't reproduce this over here on a bare metal system.

    yeah just tried it on a 2nd system here, same GPU, doesnt occur.
    odd that it worked prior to upgrading to 6.12.4, but, well. not that much of an problem 😄

  6. 2 hours ago, ich777 said:

    It would be better to ask that on the Proxmox forums since I'm not familiar with Proxmox and I don't know if everything is passed over correctly <- but as said I can't help with that since I don't use Proxmox, maybe a command line argument is missing or whatever.


    If this was a baremetal system, any idea where I could start to look why it switches the GUI output to the Nvidia GPU after Unraid finished booting up even though disable_xconfig=true ? :)

  7. 3 hours ago, ich777 said:

    To what GPU is the screen connected?

     

    previously an intel 9700k iPGU, last weekend I moved the whole Unraid system to run under proxmox.

    after that move the GUI still worked nicely inside the proxmox console.

    today I made the upgrade and now I only get a blackscreen then the GPU is passed through.
    hardware transcoding in plex also works nicely, only the GUI doesnt work anymore.
    when I remove the GPU then the GUI works again.

     

     

  8. NVIDIA Driver

    I have an GTX1050 for Plex transcoding.
    I just upgraded from 6.11.5 to 6.12.4 - and now I dont get a GUI anymore - after the boot I just see a blackscreen

    weblogin works fine.

    I checked config\plugins\nvidia-driver\settings.cfg

    first_installation=false
    driver_version=latest
    disable_xconfig=true
    update_check=true

    No change there. So it should work.

    Is there a problem with 6.12.4 ?

  9. 52 minutes ago, ich777 said:

    You habe to choose one of the three not all of them so it would be:


    LOL, okay - I wondered if commands had changed in the new version. 
    I misunderstood the description. 😅

    I did then use the old commands from my cheat sheet with which i could set it up as usual. 
     

    52 minutes ago, ich777 said:

    How often did you restart your container?

    I only started it, then I noticed the error in the log.

    After another restart it seems to have updated. 😃
     

    ---BattleNetPrefill v1.6.1 up-to-date---


     

    • Like 1
  10. Just did a clean install of LanCache Prefill on a new machine.

    After the setup I ran:

    su $USER
    cd ${DATA_DIR}/(BattleNet|Epic|Steam)Prefill


    which resulted in:

    bash: syntax error near unexpected token `('


    I then looked in the logfile where I noticed this:
     

    ---Version missmatch, installed v1.5.0, downloading and installing latest v1.6.1...---
    ---Something went wrong, can't download BattleNetPrefill v1.6.1, putting container in sleep mode---

     

  11. On 3/25/2023 at 1:18 AM, tjb_altf4 said:

    use the go file located on the boot disk /boot/config/go

    add this entry below the existing commands:

    /usr/bin/qemu-ga -l /var/log/qemu-ga.log -d &

     

    As a test you can run this in the command line to get the agent running for the current session, it should show up in proxmox straight away.

    The go file will run this command on subsequent reboots.

    Thank you!

    Now I can shutdown Unraid from inside the proxmox webinterface!

  12. 56 minutes ago, JorgeB said:

    Ipvlan also supports that, but if you prefer to keep macvlan update to this release, read the release notes before.

     

     

    Thx! I will wait for this release to reach stable status and then maybe a week or two before I upgrade. :)

  13. 2 minutes ago, JorgeB said:

    Switching to ipvlan should fix it


    I have containers that need to have a static IP on my main LAN.

    If I get this right, switching to ipvlan would no allow this, right?

    The ipvlan type is best when connection to the physical network is not needed

     

    Also what is broken with macvlan that I have to switch? Or what causes this issue in the first place?

  14. For about 4 weeks now I get this about every 2 to 3 days in the log. The system itself continues to work though, nothing obvious "breaks, stops or freezes".
     

    Aug 24 23:19:07 NAS kernel: ------------[ cut here ]------------
    Aug 24 23:19:07 NAS kernel: WARNING: CPU: 2 PID: 19856 at net/netfilter/nf_conntrack_core.c:1208 __nf_conntrack_confirm+0xa5/0x2cb [nf_conntrack]
    Aug 24 23:19:07 NAS kernel: Modules linked in: xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat xt_nat xt_tcpudp iptable_mangle vhost_net tun vhost vhost_iotlb tap veth macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs nfsd auth_rpcgss oid_registry lockd grace sunrpc md_mod tcp_diag inet_diag ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc ixgbe xfrm_algo mdio e1000e i915 iosf_mbi drm_buddy i2c_algo_bit x86_pkg_temp_thermal ttm intel_powerclamp coretemp drm_display_helper kvm_intel drm_kms_helper drm kvm i2c_i801 crct10dif_pclmul input_leds crc32_pclmul wmi_bmof mxm_wmi crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd rapl intel_cstate intel_uncore i2c_smbus joydev led_class intel_gtt nvme agpgart i2c_core nvme_core ahci syscopyarea libahci sysfillrect sysimgblt fb_sys_fops tpm_crb tpm_tis tpm_tis_core video thermal fan wmi
    Aug 24 23:19:07 NAS kernel: backlight tpm acpi_pad button unix [last unloaded: xfrm_algo]
    Aug 24 23:19:07 NAS kernel: CPU: 2 PID: 19856 Comm: kworker/2:2 Not tainted 5.19.17-Unraid #2
    Aug 24 23:19:07 NAS kernel: Hardware name: System manufacturer System Product Name/ROG STRIX Z370-E GAMING, BIOS 3005 09/30/2021
    Aug 24 23:19:07 NAS kernel: Workqueue: events macvlan_process_broadcast [macvlan]
    Aug 24 23:19:07 NAS kernel: RIP: 0010:__nf_conntrack_confirm+0xa5/0x2cb [nf_conntrack]
    Aug 24 23:19:07 NAS kernel: Code: c6 48 89 44 24 10 e8 dd e2 ff ff 8b 7c 24 04 89 da 89 c6 89 04 24 e8 56 e6 ff ff 84 c0 75 a2 48 8b 85 80 00 00 00 a8 08 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 16 de ff ff e8 2c e3 ff ff e9 7e 01
    Aug 24 23:19:07 NAS kernel: RSP: 0018:ffffc90000170cf0 EFLAGS: 00010202
    Aug 24 23:19:07 NAS kernel: RAX: 0000000000000188 RBX: 0000000000000000 RCX: abd8a9687e187a16
    Aug 24 23:19:07 NAS kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa0273140
    Aug 24 23:19:07 NAS kernel: RBP: ffff8881092ebf00 R08: 3a435c8f350d0ebe R09: 4ca5bad75056aacb
    Aug 24 23:19:07 NAS kernel: R10: 5565a652dd6ba82b R11: 629a3762be45c08e R12: ffffffff82909480
    Aug 24 23:19:07 NAS kernel: R13: 0000000000014290 R14: ffff8882803b2400 R15: 0000000000000000
    Aug 24 23:19:07 NAS kernel: FS:  0000000000000000(0000) GS:ffff888426c80000(0000) knlGS:0000000000000000
    Aug 24 23:19:07 NAS kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Aug 24 23:19:07 NAS kernel: CR2: 0000150ccfa6e740 CR3: 000000000220a005 CR4: 00000000003706e0
    Aug 24 23:19:07 NAS kernel: Call Trace:
    Aug 24 23:19:07 NAS kernel: <IRQ>
    Aug 24 23:19:07 NAS kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack]
    Aug 24 23:19:07 NAS kernel: nf_hook_slow+0x3a/0x96
    Aug 24 23:19:07 NAS kernel: ? ip_protocol_deliver_rcu+0x164/0x164
    Aug 24 23:19:07 NAS kernel: NF_HOOK.constprop.0+0x79/0xd9
    Aug 24 23:19:07 NAS kernel: ? ip_protocol_deliver_rcu+0x164/0x164
    Aug 24 23:19:07 NAS kernel: ip_sabotage_in+0x47/0x58 [br_netfilter]
    Aug 24 23:19:07 NAS kernel: nf_hook_slow+0x3a/0x96
    Aug 24 23:19:07 NAS kernel: ? ip_rcv_finish_core.constprop.0+0x3b7/0x3b7
    Aug 24 23:19:07 NAS kernel: NF_HOOK.constprop.0+0x79/0xd9
    Aug 24 23:19:07 NAS kernel: ? ip_rcv_finish_core.constprop.0+0x3b7/0x3b7
    Aug 24 23:19:07 NAS kernel: __netif_receive_skb_one_core+0x77/0x9c
    Aug 24 23:19:07 NAS kernel: process_backlog+0x8c/0x116
    Aug 24 23:19:07 NAS kernel: __napi_poll.constprop.0+0x28/0x124
    Aug 24 23:19:07 NAS kernel: net_rx_action+0x159/0x24f
    Aug 24 23:19:07 NAS kernel: __do_softirq+0x126/0x288
    Aug 24 23:19:07 NAS kernel: do_softirq+0x7f/0xab
    Aug 24 23:19:07 NAS kernel: </IRQ>
    Aug 24 23:19:07 NAS kernel: <TASK>
    Aug 24 23:19:07 NAS kernel: __local_bh_enable_ip+0x4c/0x6b
    Aug 24 23:19:07 NAS kernel: netif_rx+0x52/0x5a
    Aug 24 23:19:07 NAS kernel: macvlan_broadcast+0x10a/0x150 [macvlan]
    Aug 24 23:19:07 NAS kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]
    Aug 24 23:19:07 NAS kernel: process_one_work+0x1a8/0x295
    Aug 24 23:19:07 NAS kernel: worker_thread+0x18b/0x244
    Aug 24 23:19:07 NAS kernel: ? rescuer_thread+0x281/0x281
    Aug 24 23:19:07 NAS kernel: kthread+0xe4/0xef
    Aug 24 23:19:07 NAS kernel: ? kthread_complete_and_exit+0x1b/0x1b
    Aug 24 23:19:07 NAS kernel: ret_from_fork+0x1f/0x30
    Aug 24 23:19:07 NAS kernel: </TASK>
    Aug 24 23:19:07 NAS kernel: ---[ end trace 0000000000000000 ]---

     

    2 days ago I transplanted all harddisks into a new system (different mainboard, CPU and RAM).
    But as you can see above I got the same problem yesterday night.

    Anyone an idea what could cause this or what this error actually means? It looks kinda severe?

    System is still on Version: 6.11.5 - I usually always wait for a few months before upgrading to a new major release for stability.

  15. 18 minutes ago, Squid said:

    It's not.  powerdown -r simply calls reboot

     

    If powerdown ever stopped working, I'd be the first to bring the wrath of the gods down on LT (and probably my wife's wrath too).  Muscle memory etc dictates that everyone here says "powerdown -r" instead of "reboot"

     

    hmm... 

    so what is the meaning of this line in unraids syslog? 

     

    May 21 07:10:01 NAS root: /usr/local/sbin/powerdown has been deprecated

     

  16. I might have figured it out.


    DISKS WHICH STAY BUSY:

    according to the syslog its cache2nvme and cache3nvme that appear to stay busy on shutdown, which could lead to the forced shutdown.

    THAT RANG A BELL:
    I run a seperate log-server pc to collect all kinds of logs (docker, syslog, smartmeter, ....).
    On that log-server promtail is used as remote syslog server to collect syslogs and write it to Grafana / Loki.

    In the extra parameters of all my Unraid dockers I use:

    --log-driver=syslog --log-opt tag="Docker_{{.Name}}" --log-opt syslog-format=rfc5424 --log-opt syslog-address=udp://192.168.1.2:40515

    UDP is used because if you use TCP and the remote syslog server is down, then the docker container will FAIL TO START.
    This is an issue in the docker logging driver itself (not unraid's fault!)- there are many threads and issues on github about this in various projects, also affects other remote logging targets/drivers.

    But I digress:)
    So with that parameter I ensure that all docker logs get send to my log-server.... well... almost....

    There are a couple of problems:

    1. the syslog server in promtail only supports RFC5424 - UNRAID DOES NOT USE THAT FORMAT FOR ITS REMOTE SYSLOG SERVER!!!! And so no data is collected. I could not find a way to get unraid to send its syslog using that format. :(
    2. some dockers (plex, LanCache, LanCache_prefill,...) write additional logfiles onto the unraid filesystem, which cant be sent through the docker syslog driver - I need these logs for error alerts / troubleshooting.


    To fix these issues I installed promtail locally on the unraid machine, and launched it with a userscript when the array starts.
    Promtail then tailed the unraid syslog as well as the logs from Plex, LanCache, LanCache_prefill, .. and sent them directly into the Loki database on the log-server.

    This worked great!!! 😃

    Well, apparently that caused a new issue as it seems - because when you shut down or restart unraid, promtail does not get killed - which in return then leads to the cache2nvme and cache3nvme to stay busy and cause an unclean shutdown. :(

    SO...... WHAT NOW?

    • I removed the local installation of promtail from unraid as that kept the cache2nvme and cache3nvme busy
    • I installed the grafana_promtail docker on unraid and have that tail the local logs of Plex, LanCache, LanCache_prefill, .. sending these directly to my log-server
      I do not have it tail unraid's syslog - that would be useless as I dont get any logs when docker isnt running
    • So since for some unknown reason Unraid cant be configured to use the RFC5424 format for sending its syslog to a remote-syslog server, I had to configure a syslog-relay on my log-server and have that do the format conversion to RFC5424....... 🙄


    Fingers crossed that this fixes the issue.

    Thank you for your help guys! :) 

  17. 5 minutes ago, itimpi said:

    Good point - I am not sure.  I think the cache drives staying busy may stop them being unmounted and cause issues.   If that is happening I guess the problem then becomes why that is happening.

    if that really causes the issue then i wonder why it would trigger a parity check as that isnt needed when the array was stopped okay. 

    i will look into this closer. :)

  18. 16 minutes ago, itimpi said:

    If you can successfully stop the array before the timeout kicks in you should not get an unclean shutdown unless Unraid for some reason is unable to record the array stop on the flash drive.

    what if cache disks stay busy?

    could that trigger a unclean shutdown and parity sync even tho the array itself was stopped correctly?

     

    i have seen a message that one of the cache drives was busy a couple of times in the logs.