TechGeek01

Yep, turns out a 32 character password works just fine. Seems odd that there's a limit here, as the 64 character worked fine in browser. Do you know if there's a limit in your code, whether that's a limitation or artificial, at all, or is this just a weird bug?

So it was working on Unraid, as was sabnzbdvpn. I was attempting to get a second instance up and running (testing with my login, but setting up for a friend), and after running into these same issues, I changed the password, and updated the containers on Unraid. The only thing changed was the password. It's alphanumeric with no special characters, and 64 characters. Does it maybe need to be shortened a bit?

So I'm having issues connecting with NordVPN UDP. Logs show the following repeated constantly: 2021-09-27 22:21:47,937 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2021-09-27 22:21:47,938 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 WARNING: file 'credentials.conf' is group or others accessible 2021-09-27 22:21:47 OpenVPN 2.5.1 [git:makepkg/f186691b32e68362+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 24 2021 2021-09-27 22:21:47 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10 2021-09-27 22:21:47,939 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 WARNING: --ping should normally be used with --ping-restart or --ping-exit 2021-09-27 22:21:47 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2021-09-27 22:21:47,940 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2021-09-27 22:21:47 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2021-09-27 22:21:47,940 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 TCP/UDP: Preserving recently used remote address: [AF_INET]89.187.182.71:1194 2021-09-27 22:21:47 Socket Buffers: R=[212992->212992] S=[212992->212992] 2021-09-27 22:21:47 UDP link local: (not bound) 2021-09-27 22:21:47 UDP link remote: [AF_INET]89.187.182.71:1194 2021-09-27 22:21:47,954 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 TLS: Initial packet from [AF_INET]89.187.182.71:1194, sid=df5141ca 49f1b7f1 2021-09-27 22:21:47,988 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA 2021-09-27 22:21:47,988 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA6 2021-09-27 22:21:47,989 DEBG 'start-script' stdout output: 2021-09-27 22:21:47 VERIFY KU OK 2021-09-27 22:21:47 Validating certificate extended key usage 2021-09-27 22:21:47 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-09-27 22:21:47 VERIFY EKU OK 2021-09-27 22:21:47 VERIFY OK: depth=0, CN=us6722.nordvpn.com 2021-09-27 22:21:50,007 DEBG 'start-script' stdout output: 2021-09-27 22:21:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA 2021-09-27 22:21:50 [us6722.nordvpn.com] Peer Connection Initiated with [AF_INET]89.187.182.71:1194 2021-09-27 22:21:50,007 DEBG 'start-script' stdout output: 2021-09-27 22:21:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA 2021-09-27 22:21:50 [us6722.nordvpn.com] Peer Connection Initiated with [AF_INET]89.187.182.71:1194 2021-09-27 22:21:51,157 DEBG 'start-script' stdout output: 2021-09-27 22:21:51 SENT CONTROL [us6722.nordvpn.com]: 'PUSH_REQUEST' (status=1) 2021-09-27 22:21:51,171 DEBG 'start-script' stdout output: 2021-09-27 22:21:51 AUTH: Received control message: AUTH_FAILED 2021-09-27 22:21:51,172 DEBG 'start-script' stdout output: 2021-09-27 22:21:51 SIGTERM[soft,auth-failure] received, process exiting Debug is enabled, credentials are recently changed, have no special characters, and have been verified to work in browser. openvpn directory contains the UDP .ovpn file, as well as the cert files for the associated server. Both delugevpn and Unraid are up to date at the time of writing this. Any ideas here?

Didn't seem appropriate to open a bug report for this, but I noticed in the shares page, the help ? section on the column headers makes mention of AFP still being a thing, despite it having been removed everywhere else.

Yeah, that's what I'm doing currently now as well. Only difference is before, I didn't have the custom header color, so the header was default white, while my text was also white. Maybe you could add a check for other users that have the same deal I did (dark custom header image, but default color), and make it so that if the custom text color, and the header color are too close together, provided they're not both user-set (I didn't have a custom header color before, just the theme default), have it change the unset one to contrast? That is, if I had white text, but an unset header color, it would see they're both close together, and change the color the menu uses to something darker and readable. Not sure if this is the most elegant way to do that while retaining the custom display options, but it would at least help readability in that edge case.

Also chiming in, seeing the same thing with the Supermicro 846 icon in the list. No icon for me in the my servers page.

I actually do not have adapters for mini DisplayPort, so that's not happening currently 😛 Yeah tried that already. Boots to GUI fine without the plugin installed. So something changed either in 6.9.1 or in the plugin. Not a huge deal having it be headless for a bit since I can get to the web interface just fine, but it would be nice to have that fixed 😛. Keep up the great work, man!

Good to know! Connected to integrated graphics. The Quadro is solely for Plex transcoding. Yup, needed to to get onboard graphics working in 6.9 with the new IPMI firmware that uses the newer Aspeed drivers. For the record, I was not getting a black screen before. This was the first time I rebooted since installing on 6.9.1 (was having issues with it not seeing the card after the upgrade, so uninstalled and reinstall fixed that, but I never rebooted after reinstalling since it's not required) so it was the first time I noticed this issue. Any ideas why I'm getting the black screen now even after uninstalling and reinstalling the Nvidia plugin?

Just wanted to chime in on a coloring issue. I'm using the "black" color theme, and have a white header. I have a custom header image that's gray, so the tab bar is black text on white, but the header image is gray with some stuff in it. To see text here, I have the custom text color set to white in display settings. The menus for me are unreadable in this plugin in the header. Seems that after testing, the background of the flyout menu takes the custom text color, and text takes the custom background color. Presumably the correct approach is for the text in the header to take the text color of the tabs, and for the flyout to match this? Without a custom header color set, the default in this theme is white. With my custom text color set to white to see version number and such on a gray header image, this otherwise makes text unreadable. This plugin, since it takes the color of the header, should more than likely do the same thing the tabs do, and ignore the custom text color and just set text to white/black depending on luminance of the header color.

@ich177 Just wanted to chime in. I'm in 2021.03.12 of the Nvidia plugin, and even with the Intel GPU Top plugin installed, no bueno. Still get a blank screen with a non-blinking white cursor. I've tried removing and reinstalling the Nvidia plugin to no avail, since I thought that might be part of the issue. Motherboard is a Supermicro X10DRi, which is Aspeed, I think 2400-based. For the record, this is the same problem I had with 6.8.3 on the latest IPMI firmware. Since 3.80, they updated the graphics drivers on the board, so I had to downgrade to 3.77 firmware to get GUI mode to work in 6.8.3. Since 6.9's latest drivers, I've been able to run on 3.88 IPMI firmware just fine. Only after this upgrade to 6.9.1, and the first reboot after installing the Nvidia plugin do I seem to have this problem again. Given that Unraid updated drivers for Aspeed, this shouldn't be a driver issue with the drivers not actually being there, right? This is just some sort of precedence thing? Any ideas on a fix here? helium-diagnostics-20210315-1709.zip

Just an update, that was indeed the problem. Uninstall and reinstall of the Nvidia Driver plugin worked like a charm!

I have not yet, but that will be my next project once it's not 4AM. I will definitely post back with results when I do though!

Updated from rc2, and after rebooting, I get the following on boot at the console, right before the login prompt main: line 96: ( / 1000 ): syntax error: operand expected (error token is "/ 1000 )") modprobe: FATAL: Module nvidia not found in directory /lib/modules/5.10.19-Unraid My initial thought was that this pertained to the Nvidia Driver plugin, but that was on the latest version before the upgrade. Only thing that changed is from rc2 to 6.9 stable. Googling for that error returns no relevant results, so I'm at a loss here. As a result, Plex Docker won't start. GPU is visible in system devices, and not bound to VFIO, but the Nvidia Driver plugin doesn't see the card, presumably as a result of the above boot errors. Server boots fine, and everything barring the GPU works fine without halting boot, but I'm at a loss here. helium-diagnostics-20210303-0224.zip

I'm not seeing perhaps the same level of increased activity. I do see increased activity on the CPU every 10-15 seconds or so, on dual E5620 v3. I've seen this happen on 6.8.3 as well, both in the form of one core spiking to 100% usage for a second, and then going back down. End result is that overall usage might go from 10 to 15% for a second. I've never seen this system not do this, so presumably this is normal behavior, but posting diagnostics in case it's not, and it could lead to someone finding something. If whether this is normal behavior or not could be clarified, that would be awesome. helium-diagnostics-20210122-0114.zip

Okay, so gracefully stopping the VM did not work. Only thing that would actually kill it was a force stop. Usually a clean stop seems to send an ACPI shutdown command, and will force kill if it's still running after a minute or so. Anyway, force stopping this time also led to the same stuck frame on the monitor, even after the VM was powered off (jnstead of the expected "no signal"). What I did notice is that unplugging the VGA cable from the card, and plugging back in does not reset this, so the detection of a monitor here makes no difference, and it seems to be the GPU that's frozen. This is fixed by restarting the VM, so the card isn't stuck, it's just being told to keep displaying an image after the VM is stopped, which might not be the desired effect. Also, I notice USB pasthrough isn't working on my system properly. Have a Dell R510 with a Logitech K120, and an M325 plugged in. Both work in Unraid itself, but they seem to control Unraid, and aren't passed through to the VM. This was with them on the front USBs of the server, so I don't know if that's an Unraid thing, or if it's just a grouping thing not being able to pass through. FWIW, the Unraid USB is on the same controller board as those front USBs (the internal USB on the R510 is on that front control board, so presumably the same USB controller). Rear USBs directly on the motherboard I/O had the same effect, controlling the host, not being passed into the VM. Additionally, editing a VM to change the USB device leads to an error "unable to find device" on power on. The ID it gives is for the new device, so it's letting go of the old device config properly, though it seems like it's unable to find and bind to a new USB device, despite it being in the USB passthrough list, and being checked. Deleting and recreating the VM fixes this, as it works fine when creating, just not editing.

Yeah, I know it's a hard power off to the VM. But displays require an active signal, correct? That is, the monitor won't continue to display when there's no signal, and has to be constantly told what to output. So how on earth, after killing and even nuking the VM, should the card still be telling it to display the same last frame of video the VM was working with? Actually, I wasn't able to get USB passthrough of keyboard and mouse working. I force stopped the VM once I realized I needed keyboard and mouse, and then edited the VM, and it wasn't responding to input. I'm not sure if that's a USB passthrough thing (either a bug, or something to do with IOMMU grouping, I have no idea), or if that was just the GPU still stuck on the last frame of video even after restarting it. I'll give that a new test in the morning to rule that out. My main Unraid server on 6.8.3 uses low profile cards. I unfortunately don't have anything that'll fit in there to test. Was *planning* on getting a low profile Quadro, but I haven't bought yet since I wanna make sure this'll work. Side note, would I be able to use said Quadro for HW acceleration in a Plex Docker?

I've never done GPU passthrough before, so I don't know if this happens all the time, or if it's an issue with my setup, or if it's an rc2 bug (leaning towards the latter, but I have no idea). I have an old GeForce 210 I threw in to pass through to a VM, and I noticed that when I stopped the VM, I still had video. To my knowledge, monitors only display what they're actively told to, so if there's nothing utilizing the GPU, there should be no signal to the monitor, as it shouldn't be telling the monitor to do anything. Anyway, after stopping, and even completely nuking the VM and disks, it still persisted. Was using the VGA output on the card, and the monitor constantly displayed the last thing that was on screen when I shut it down (setup screen of a Windows ISO) as if it was actively being told to display it still. I did not check if stopping the VM properly avoids this. This was using the force stop option.

Yeah, at least the ability to say "don't assign an IP" would be nice. Cause if you set untagged as no static IP, your option is "automatic" which then assigns a 169 address, and then it seems that even though I have a static assigned to a VLAN, and a default gateway set on said VLAN, it tries to use the 169 untagged interface, and "can't reach the internet"

IPMI/system log shows nothing unusual, unfortunately. Memtest completely freaked on the bit fade test. Like, millions of errors in the first several hundred MB, so I'm currently in the process of finding what I hope is a bad stick, and not a slot or something.

In the last couple months, I moved Unraid over from a Dell R510 to a Supermicro build, and since then, I see occasional warnings about machine check errors. Dec 19 16:49:16 helium kernel: mce: [Hardware Error]: Machine check events logged Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: CPU 6: Machine Check Event: 0 Bank 10: 8c000046000800c1 Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: TSC 51ce458bc87a8 Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: ADDR c5c6ea000 Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: MISC 900100010000c8c Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: PROCESSOR 0:306f2 TIME 1608418156 SOCKET 1 APIC 10 Dec 19 16:49:16 helium kernel: EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0xc5c6ea offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:2 rank:0) Current system is a Supermicro X10DRi with dual E5-2620 v3 processors, and 64GB of RAM, configured as 2x16GB per socket. This obviously is a memory issue, but what exactly causes this, and how do I go about fixing it? I don't know a lot about these sort of logs. Presumably this isn't logging of things like ECC corrections, and this indicates a memory issue where I may have to replace the stick, correct? helium-diagnostics-20201219-2044.zip

This is an issue on RC1. I have not tested on RC2, since my networking setup has since changed, but if you didn't know about this, it probably applies to RC2 as well. Firstly, if we're enabling VLANs, and put an IP on a VLAN, but don't want an IP on the whole untagged interface, there probably should be an option for "no IP" rather than just letting "automatic" give it a 169 address. It's a minor annoyance that leads to the 169 address showing in the top right corner, as opposed to the real, set IP in the VLAN interface. The problem this creates is that in this scenario, where there's an auto 169 address on the untagged interface, and the "real" accessible web UI IP on a tagged VLAN on the same interface, installing things like plugins fails, because the 169 address has no internet connection, so Unraid can't connect to the internet. My guess is the best way to handle that would be to try the next IP in line on a VLAN should the main interface IP fail to resolve internet, until it hits one that works, instead of just giving up after the first fail. And/or let us "disable" IP assignment on an interface, or subinterface, so that instead of trying the untagged VLAN on a port, it knows to skip it, and use the tagged VLAN IP instead.

I know this has been an issue for a while. I'm not sure if it's a hardware thing, or if it's an Unraid thing, or a bit of both, but it won't boot UEFI. Made a test USB of the trial of beta 35 and booted an R510. Booting in BIOS works fine, but despite having made the USB with the "allow UEFI boot" option checked, when it gets to the splash screen to select GUI mode or CLI mode at boot, whatever the selected boot option is, I get a "bad file number" error when booting, and it keeps trying and failing every couple of seconds. UEFI was enabled on the R510, and it should in theory be supported, given that the USB was made with that in mind, but all options at the Unraid boot screen still do this. Would be awesome if it could be fixed, but what exactly is the underlying cause for this?

Totally missed that statement above. So then with autostart on my array disabled, the programmatically intended behavior is that VMs don't autostart, correct? Now, Docker containers also have an autostart option, and when I manually start the array on boot cause auto array start is disabled, the Docker containers autostart themselves once the array is running. Surely, the expected and proper behavior should be that VMs should also follow that pattern? The array has to be started to even see a list of VMs or Docker containers, so there's no way to even manually start them before the array is already running, meaning that whether the array is started manually or automatically should be entirely irrelevant to both of those autostarts. Can a change be made so that even when starting the array manually, both Docker and VMs respect the chosen autostart options?

I just dumped a diagnostic ZIP. Sounds like a weird edge case or something. helium-diagnostics-20201118-1647.zip