gizmo000

@binhex it may also be worth adding to A17 to check that the VPN subscription is active, since that's exactly the situation I encountered...just an idea. Thanks again for putting up with us plebes...

This is a good reminder ... however, I get "authorization failed" to a gmail address that I won't re-post here for privacy reasons. Sorry, we weren't able to complete your payment at this time. Please try again later. If you continue to encounter problems, please contact customer service. Edit: If I send money without using the link through PayPal's site, it completes successfully. Hopefully his email hasn't changed! XDXD

binhex I am embarrassed beyond belief so I will own up to my mistake ... my PIA subscription had expired. For anyone reading this, I also had excess wireguard conf files in my /config directory which was throwing things off as well. I removed the extra conf files, updated my subscription, and I'm back up on wireguard with the most recent versions. binhex please PM me some way that so I can buy you a beer or three ... seriously I am embarrassed.

I am also experiencing these json errors in binhex-qbittorrentvpn ... however, in binhex-delugevpn I'm getting different errors: 2024-07-11 12:35:01,787 DEBG 'start-script' stdout output: 2024-07-11 12:35:01 [montreal411] Peer Connection Initiated with [AF_INET]199.36.*.*:1198 2024-07-11 12:35:02,957 DEBG 'start-script' stdout output: 2024-07-11 12:35:02 AUTH: Received control message: AUTH_FAILED 2024-07-11 12:35:02 SIGTERM[soft,auth-failure] received, process exiting 2024-07-11 12:35:02,962 DEBG 'start-script' stdout output: [info] Starting OpenVPN (non daemonised)... 2024-07-11 12:35:02,977 DEBG 'start-script' stdout output: 2024-07-11 12:35:02 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 2024-07-11 12:35:02,977 DEBG 'start-script' stdout output: 2024-07-11 12:35:02 WARNING: file 'credentials.conf' is group or others accessible 2024-07-11 12:35:02 OpenVPN 2.6.11 [git:makepkg/ddf6bf6d2a135835+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Jun 20 2024 2024-07-11 12:35:02 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10 2024-07-11 12:35:02 DCO version: N/A 2024-07-11 12:35:02,978 DEBG 'start-script' stdout output: 2024-07-11 12:35:02 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2024-07-11 12:35:02,980 DEBG 'start-script' stdout output: 2024-07-11 12:35:02 TCP/UDP: Preserving recently used remote address: [AF_INET]104.18.*.*:1198 2024-07-11 12:35:02 UDPv4 link local: (not bound) 2024-07-11 12:35:02 UDPv4 link remote: [AF_INET]104.18.*.*:1198 2024-07-11 12:36:02,278 DEBG 'start-script' stdout output: 2024-07-11 12:36:02 [UNDEF] Inactivity timeout (--ping-restart), restarting 2024-07-11 12:36:02,279 DEBG 'start-script' stdout output: 2024-07-11 12:36:02 SIGHUP[soft,ping-restart] received, process restarting 2024-07-11 12:36:02,280 DEBG 'start-script' stdout output: 2024-07-11 12:36:02 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. These only started popping up after the container update, which had been working for months with no issue. I haven't been able to get this deluge container to connect to wireguard in months ... I gave up and switched to OpenVPN, but now OpenVPN isn't connecting either If you need more diagnostics please let me know and I'll post them. I'm on UnRaid 6.12.6.

Looks like the re-import is covered here ... does the export save anything I need to keep track of, or just make sure to run the export command? The only other thing I changed was /dev/mapper/sdX1 (Y1) because I had the drives encrypted. zpool is doing its thing and resilvering now! Thanks so much @JorgeB for the assistance here ... I was about to lose my mind.

So I have been playing with this overnight ... I "wrote" a new config using the `New Config` tool (pool devices only), and assigned the same cache disks to the same slots, with the exception of my two failed drives. `zpool import -d /dev/mapper` (and `zpool import` for that matter) shows my two degraded vdevs with most disks online: pool: mypool id: [redacted] state: DEGRADED status: One or more devices contains corrupted data. action: The pool can be imported despite missing or damaged devices. The fault tolerance of the pool may be compromised if imported. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J config: mypool DEGRADED raidz2-0 ONLINE sdaw1 ONLINE sdax1 ONLINE sday1 ONLINE sdaz1 ONLINE sdba1 ONLINE sdbb1 ONLINE sdbc1 ONLINE sdbd1 ONLINE sdbe1 ONLINE sdbf1 ONLINE sdbg1 ONLINE sdbh1 ONLINE sdbi1 ONLINE sdbl1 ONLINE sdbm1 ONLINE raidz2-1 ONLINE sde1 ONLINE sdf1 ONLINE sdg1 ONLINE sdh1 ONLINE sdi1 ONLINE sdj1 ONLINE sdk1 ONLINE sdl1 ONLINE sdm1 ONLINE sdn1 ONLINE sdo1 ONLINE sdp1 ONLINE sdq1 ONLINE sdr1 ONLINE sds1 ONLINE raidz2-2 DEGRADED sdt1 ONLINE sdu1 ONLINE sdv1 ONLINE sdw1 ONLINE sdx1 ONLINE sdy1 ONLINE 12281917106237315780 UNAVAIL invalid label sdaa1 ONLINE sdab1 ONLINE sdac1 ONLINE sdae1 ONLINE sdag1 ONLINE sdaf1 ONLINE sdah1 ONLINE sdai1 ONLINE raidz2-3 DEGRADED sdad1 ONLINE sdaj1 ONLINE sdak1 ONLINE sdal1 ONLINE sdam1 ONLINE sdan1 ONLINE sdao1 ONLINE sdap1 ONLINE sdaq1 ONLINE sdar1 ONLINE sdas1 ONLINE 11665832322838174263 FAULTED corrupted data sdat1 ONLINE sdau1 ONLINE sdav1 ONLINE The array comes online now, which is great ... however, in the gui the "size, used and free" columns for all my zpool cache drives all show `Unmountable: Unsupported or no file system`. Also, at the bottom of the Main page, Unraid is asking to format all those pool drives (since the filesystem is detected as unsupported). If I assign 'no device' to both slots, the behavior is the same: unsupported or no file system (but the main array still starts). The `invalid label` results from a manual `cryptsetup luksFormat /dev/sdz1` that I was trying to get unraid to recognize in earlier experimenting.

It seems even with two new disks installed, I cannot start the array to resilver. Whenever I try to start my array now (with either 1 or both new disks assigned in the zfs pool), I get "too many wrong or missing devices." My main unraid array will not even start either. I'm DIW, and starting to stress out... Since I have two drive failures, there is no way for me to get back to just 1 cache drive wrong or missing. If there's a way to do this via command line, I'm comfortable doing so, but I don't want to jeopardize the 300+ TiB I have on there right now. Any recommendations on how to proceed properly to restore my zpool? galileo-diagnostics-20231107-1454.zip

Okay cool thanks for the quick replies My second drive failed after the reboot (separate vdev) so unraid is preventing me from starting anything (due to 2 missing disks in zpool).

Jorge, thank you for referencing the post, but the troubleshooting there is from 2016...certainly Unraid's ZFS implementation has made improvements to the replacement strategy by now? I recently experienced 2 HDD failures in a 60-drive array (4 vdevs @15 each, RAIDZ2). Luckily, the failures occurred in separate vdevs. However, from the looks of the post you referenced ... if the 2 failures were in the same vdev, I'd have no way to replace/rebuild that vdev, given that RAIDZ2 provides that redundancy? What is the point of this implementation if we cannot recover from 2 failures in a single vdev with RAIDZ2? Also, I happened to notice that if I removed one failed HDD from one of my vdevs, the zpool kept functioning, albeit in a degraded status. I am waiting for replacement HDDs to arrive, and I was forced to reboot my server (array would not stop on its own so I could pull the failed disks). But now, I cannot even start the array (unraid array either, but specifically: the zpool), because I'm missing 1 disk from a vdev that has RAIDZ2 redundancy? Shouldn't I be able to start the zpool in a degraded status? This is a little bit inconvenient because now I cannot start any array until I have replacement disks, but I would think we should be able to at least start the zpool in a degraded status...certainly we should be able to start the unraid array, but I cannot seem to do that either while waiting for zpool replacement disks...

'latest' image still refuses to start up: 2023-10-02 11:05:38,666 INFO Set uid to user 0 succeeded 2023-10-02 11:05:38,670 INFO supervisord started with pid 16 2023-10-02 11:05:39,673 INFO spawned: 'dbus' with pid 17 2023-10-02 11:05:39,675 INFO spawned: 'avahi-daemon' with pid 18 2023-10-02 11:05:39,677 INFO spawned: 'squeezeboxserver' with pid 19 2023-10-02 11:05:39,688 INFO exited: avahi-daemon (exit status 255; not expected) 2023-10-02 11:05:39,789 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-10-02 11:05:40,791 INFO success: dbus entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2023-10-02 11:05:40,794 INFO spawned: 'avahi-daemon' with pid 21 2023-10-02 11:05:40,797 INFO spawned: 'squeezeboxserver' with pid 22 2023-10-02 11:05:40,907 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-10-02 11:05:42,718 INFO success: avahi-daemon entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2023-10-02 11:05:43,722 INFO spawned: 'squeezeboxserver' with pid 24 2023-10-02 11:05:43,841 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-10-02 11:05:46,847 INFO spawned: 'squeezeboxserver' with pid 26 2023-10-02 11:05:46,966 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-10-02 11:05:47,968 INFO gave up: squeezeboxserver entered FATAL state, too many start retries too quickly

Ran this LMS container for years under 6.9 and recently upgraded Unraid to 6.12. Ever since switching to 6.12, I've had the "persistent process restarting" forever and LMS refuses to start and present itself to my logitech devices. Tried chmod'ing and chown'ing directories in the data folder to nobody:users & 755 as recommended earlier in this forum, but nothing seems to work. The most recent update pushed 3 days ago now presents another interesting problem ... docker run -d --name='LogitechMediaServer-latest' --net='proxynet' -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="myunraid" -e HOST_CONTAINERNAME="LogitechMediaServer-latest" -e 'test'='yes' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:9000]/' -l net.unraid.docker.icon='https://i.imgur.com/PoUuA3k.png' -p '3483:3483/tcp' -p '3483:3483/udp' -p '5354:5353/udp' -p '9000:9000/tcp' -p '9090:9090/tcp' -v '/mnt/user/music/SBox Server/My Music/':'/music':'rw' -v '/var/run/dbus':'/var/run/dbus':'rw' -v '/mnt/user/appdata/LogitechMediaServer-latest':'/config':'rw' 'snoopy86/logitechmediaserver' 9454622d76ca5c50871e83875238fee4c172867918cae0ebcaefeb15e87e2679 But this never shows up either ... logs: usermod: no changes 2023-09-17 11:54:36,230 INFO Set uid to user 0 succeeded 2023-09-17 11:54:36,234 INFO supervisord started with pid 17 2023-09-17 11:54:37,238 INFO spawned: 'dbus' with pid 18 2023-09-17 11:54:37,241 INFO spawned: 'avahi-daemon' with pid 19 2023-09-17 11:54:37,245 INFO spawned: 'squeezeboxserver' with pid 20 2023-09-17 11:54:37,392 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-09-17 11:54:38,252 INFO success: dbus entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2023-09-17 11:54:38,252 INFO success: avahi-daemon entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2023-09-17 11:54:39,256 INFO spawned: 'squeezeboxserver' with pid 22 2023-09-17 11:54:39,378 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-09-17 11:54:41,383 INFO spawned: 'squeezeboxserver' with pid 24 2023-09-17 11:54:41,502 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-09-17 11:54:44,508 INFO spawned: 'squeezeboxserver' with pid 26 2023-09-17 11:54:44,629 INFO exited: squeezeboxserver (exit status 0; not expected) 2023-09-17 11:54:45,631 INFO gave up: squeezeboxserver entered FATAL state, too many start retries too quickly Not sure what else to try, as this container worked perfectly for so long. I'm also not sure what is using 5353, as the original docker run showed a conflict (but none was listed in the utilization list). I also thought about "rolling back" to a previous version, but can only seem to find the 'latest' tag on docker hub, with no ability to select a previous image

I spoke too soon ... after another reboot, the WebUI came up with the appropriate IP address. Diagnostics are attached. diagnostics-20230316-1649.zip

FWIW, the ASRock BIOS/splash screen seems to hang with "Update FRU System device..." before booting Unraid. Not finding much on this error either...

Actually with the 10Gbe NIC installed, and eth0 properly assigned (5c is the HP 4-port Ethernet NIC): # PCI device 0x8086:0x150e (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac::5c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x8086:0x150e (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac::5d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # PCI device 0x8086:0x150e (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac::5e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" # PCI device 0x8086:0x150e (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac::5f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" # PCI device 0x8086:0x1563 (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0::18", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" # PCI device 0x8086:0x1563 (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0::19", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5" # PCI device 0x8086:0x10fb (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80::08", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6" # PCI device 0x8086:0x10fb (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80::09", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7" Unraid is still failing to assign an IP on the ::5c MAC (eth0) interface. I wish I could get an IP so I could get you some diagnostics.

Turns out my boot order was mangled in one of the reboots ... no idea why or how that would occur without me changing it. So the server was just sitting there not knowing what to boot. My BIOS won't seem to pick the right boot drive (tries to boot UEFI, but I boot Unraid legacy). If I manually boot, it starts just fine. So, I'll have to dig into the BIOS settings to see if I can't force it to skip the UEFI checks (I didn't see any obvious way to force this at first glance). It's an ASRockRack ROMED8-2T. So, I tried to re-install the 10Gbe adapter, which is utilizing the `ixgbe` driver that I happened to notice wouldn't get IP addresses in Unraid before. I already have an identical NIC in a workstation running linux (ixgbe) that picks up the IP address just fine. Is there a known bug in Unraid that prevents ixgbe from obtaining IP addresses?