chris1259

Sorry for the confusion. This was a warning, not a request for support :-)

I upgraded three servers to v7.3.4: two from v7.3.3 and one from v7.3.2. The two coming from v7.3.3 were fine. The server coming from v7.3.2 had one issue: its 10GbE QLogic card (cLOM8214, rev 54, an NC523SFP-style 2-port adapter) is no longer detected. I had a similar problem on my previous upgrade. The NVIDIA driver updated from v580.173.20 to v580.196.07 and worked without problems. The array, docker containers and everything else appear to be working. Symptoms Many PCIe bus errors scroll by during boot, before Unraid finishes starting. In Tools > System Devices, the 10GbE card shows as “Device change action / removed.” What I tried Shut down, removed the card, and powered on. Went to Tools > System Devices and clicked “Acknowledge all PCI changes.” Shut down, reinstalled the card, and powered on. Went back to System Devices and clicked “Acknowledge all PCI changes” again. Rebooted. Result: The card no longer shows up at all. What the diagnostics logs show (captured after the first reboot on v7.3.4) The card is not enumerated at all. system/lspci.txt has no 01:00.x or QLogic entries, and logs/syslog.txt has no 0000:01:00 or qlcnic lines. system/lsmod.txt shows qlcnic is not loaded. config/pci_diffs.json lists both functions (01:00.0 and 01:00.1, 1077:8020) as “removed.” It worked on v7.3.2. logs/syslog-previous.txt (the Oct 11 boot, kernel 6.18.38) shows the card binding to qlcnic at 01:00.0 with driver v5.3.66 and firmware v4.20.1, identified as an NC523SFP 10Gb 2-port adapter, chip rev 0x54. The v7.3.4 kernel is 6.18.58 (system/ethtool.txt). Root port 00:01.0 (Intel Xeon E5 v3), which the card sits behind, is flooding fatal errors. logs/syslog.txt has 3,108 “Uncorrectable (Fatal), Data Link Layer” events with status SDES (surprise link down). Each is followed by “Root Port link has been reset” and “device recovery successful.” The link was already marginal on v7.3.2. logs/syslog-previous.txt shows it trained at 2.5 GT/s x8, although the card is capable of 5.0 GT/s. The syslog is truncated. logs/syslog.txt is capped at 2 MB and the error flood fills it, so the early boot lines are cut off. The first retained line is already mid-flood. NVIDIA is fine. system/nvidia-smi.txt shows driver 580.196.07 and a normal GPU listing (GTX 960 and GTX 1060). End Result: Removed the card from the server. server-diagnostics-20261102-1201.zip

Two of my three servers upgraded to 7.3.3 without issue. Those two either had no additional GPU or an NVIDIA RTX 3060. The third server booted back into the OS, but only one of its three network connections appeared in the GUI, so it appeared offline. The upgrade also pulled in the newest NVIDIA driver, which doesn’t support the older GPUs in the 3rd server and broke Plex. I rolled back to 7.3.2 to fix the networking, then had to repair the NVIDIA driver by hand. I should also mention that every few versions, an OS update changes the settings under Settings > Network Settings > Interface Rules. When that happens, I have to correct them before the server has network access again. echo "== BOARD =="; dmidecode -s baseboard-manufacturer; dmidecode -s baseboard-product-name echo "== NICs =="; lspci | grep -i -E "ethernet|network" echo "== GPUs =="; lspci | grep -i -E "vga|3d|display" BOARD ASRock X99 Extreme4 (Released August 2014) NICs 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V (rev 05) 01:00.0 Ethernet controller: QLogic Corp. cLOM8214 1/10GbE Controller (rev 54) 01:00.1 Ethernet controller: QLogic Corp. cLOM8214 1/10GbE Controller (rev 54) GPUs 02:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1) 03:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1) Plex issue: Plex wouldn’t start because Docker failed at container creation, before Plex ever ran. The container was configured to use the NVIDIA runtime, and the host’s NVIDIA driver wasn’t working. That was a side effect of the Unraid 7.3.2 → 7.3.3 upgrade and rollback: The Nvidia Driver plugin ended up with driver 615.78.08, which is too new for my cards. The GTX 960 (Maxwell) and GTX 1060 (Pascal) are only supported through the 580 branch, so nvidia-smi couldn’t talk to either GPU. When I switched to 580.173.02, the 580 package never made it to the flash drive. Only the stale 615 package was cached, so after the reboot the kernel module was 580 but the userspace tools were 615. That mismatch caused the NVRM “API mismatch” errors and kept the container runtime from working. Plex Fix: Deleted the stale 615.78.08 package folder from /boot/config/plugins/nvidia-driver/packages/. Re-downloaded 580.173.02 through Settings → Nvidia Driver, and verified the .txz and .md5 files landed on the flash drive before rebooting. Rebooted. nvidia-smi now reports driver 580.173.02 and lists both GPUs, and Plex starts.

This resolved my issue with my Nvida 960 and 1060 for Plex and tdarr. Downgrade to driver v580.

Downgrading to v580 resolved my issue on Plex and tdarr dockers with my 960 and 1060. Thank you!

This resolved my issue with my Nvida 960 and 1060 for Plex. Downgrade to driver v580.

3 Servers upgraded without issue from 7.1.4 to 7.2 with no data loss like last time.

A report was submitted for this under Stable Releases, and my mistake about posting this in the wrong forum. It wasn't my intention to create such a big post.

A report was submitted for this under Stable Releases.

Thank you for your input on this. For the HDDs on T04, that would mean 4 different HDDs with 1-2 years of usage max all failed. The drives themselves are fine and were only corrupted during the upgrade. I was able to replicate this issue. The the GPU on T02 is a Nvidia EVGA Geforce GTX 960 SuperClocked Gaming with drivers v575.51.02. Next time i attempt to upgrade i will downgrade the drivers. Thanks!

This is a continuation of my original thread of all issues i have experienced after upgrading to v7.1.0 and v7.1.2. The last stable release for me was v7.0.1, which i have reverted to on one of the 2 servers. The newest issues are as follows: Server T02 (Now running v7.0.1 - was upgraded to both 7.1.0 and v7.1.2) Crashed before reboot after upgrading to v7.1.2 from v7.0.1. Plex docker will no longer accept the extra parameter --runtime=nvidia; nvidia drivers are installed and working. This also affected the GPU Statistics plugin v2025.04.27. The webgui is no longer available within 2 days. Webgui feels slower than normal. SMB no longer works within 2 days. Docker was still working and had network access! No video out when hooked up to a monitor. Momentary press of the power button for a soft shutdown did not work; had to hard reset. NO flash appeared on the webgui. I am preparing a second USB to test with incase this is all related to an aging USB drive. Server T04 (Now running v7.1.2; upgraded from 7.0.1) 2 HDDs again corrupted with the message Unmountable: wrong or no file system (different HDDs each time). Same issue when upgrading to v7.1.0 from v7.0.1. Running Check Filesystem or Disks (gnome-disks) on Ubuntu did not fix the issue. I did not run any other data retrieval software to try to salvage the data as this is a backup server. My first post has the messages displayed when trying these 2 utilities. Random reboot after parity check completed. Webgui feels slower than normal. Webgui can no longer show the disks in the array on the Dashboard or Main tab. Downloading diagnostics data never completes; i let it sit over an hour. None of these issues are present on v7.0.1. At this time i am not asking for assistance and only wanted to share my experience. UPDATE 1: I found another reproducible issue on T04 where after using the Terminal in the upper right hand corner of the webgui and exiting, the webgui no longer shows the drives (no longer visible but array is online) in the array for about 30 mins, then it returns. Clicking refresh does not work. The drives are also no longer visible from Main > Array Devices. This same issue also occurres when trying to move files under Shares > [Pick a share] > move files. The files i was trying to move were 12.2TB in size amounting to just over 10,000 files. I let it sit for over an hour and no files were moved. I have only been able to move small files or small amounts of files with this built in feature in the past. I ended up using the docker Krusader and moved the files in a few seconds since they were all on the same server (T04). While i was updating this post T04 randomly rebooted and i was able to retrieve diagnostics (T04-diagnostics-20250513-1540.zip) this time. When the reboot happened a Windows 10 22H2 VM was running and performing a large file sync with robocopy. This was working fine for several hours before the server rebooted unexpectedly. After the reboot i reverted from v7.1.2 to v7.0.1 and again 2 drives were showing Unmountable: wrong or no file system and had to be reformatted. Downloading diagnostic data is not working on T04 after downgrading to v7.0.1, and the drives in the array are not visable, but the array is online. Diagnostics (T02-diagnostics-20250512_1030.zip) from T02 was collected while it was still running v7.1.2 at some point. A report was submitted for this under Stable Releases. T02-diagnostics-20250512_1030.zip T04-diagnostics-20250513-1540.zip

Upgraded from 7.0.1 to 7.1.0 on 2 machines: 1st machine (T02) was fine, 2nd machine (T04) was fine except for the Windows 10 VM with 2 virtual disks on 2 different drives disappeared. Downgraded to 7.0.1 and it did not fix the issue. Upgraded again to 7.1.0 and the VM did not return. Under Settings > Backup/Restore Appdata > Backup VM meta is set to yes, and Settings > VM Manager > Enable VMs is set to Yes. Some posts state the XML is within /mnt/user/system/libvirt/libvirt.img which i do have a backup of before the upgrade. Is there another location where the XML file can be found? UPDATE: 2 of my non-parity drives are now reporting as "Unmountable: wrong or no file system" on T04, yet there are no errors and the array is mounted. I am attempting to put the array in Maintenance mode and run a filesystem check. UPDATE 2: While waiting for the filesystem check to run i found the VM XML in my backup CommunityApplicationsAppdataBackup > DATE_OF_BACKUP > vm_meta.tgz > vm_meta.tar > etc> libvirt > qemu. UPDATE 3: Clicking on the disk and pressing the Check Filesystem Status button on T04 was unsuccessful after running for more than 11 hours. Both HDDs are reporting the same message over and over: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock unable to verify superblock, continuing... I also attempted fixing the filesystem with Disks (gnome-disks) on Ubuntu and it failed right away with the final message "Corrupt index block signature", "Failed to open $Secure: No such file or directory" and "Remount failed: No such file or directory". I ended up reformatting the drives in unRaid. Restoring the VM went a lot smoother: Virtual Machines > Add VM > create a generic VM but do not start it > enable form view > paste in XML and start it. A report was submitted for this under Stable Releases. T04-diagnostics-20250513-1540.zip T02-diagnostics-20250512_1030.zip

Using unRaid v7.0.0-beta3 I have not fixed it and tried again today with the following results: Opened the console to the Nextcloud Docker version Hub 9 (30.0.0), change directory to /var/www/html/ and ran the command ./occ fulltextsearch:test. Elasticsearch Docker 6.6.2 $ ./occ fulltextsearch:test .Testing your current setup: Creating mocked content provider. ok Testing mocked provider: get indexable documents. (2 items) ok Loading search platform. (Elasticsearch) ok Testing search platform. fail In SimpleNodePool.php line 68: No alive nodes. All the 1 nodes seem to be down. Elasticsearch Docker 8.11.1 $ ./occ fulltextsearch:test .Testing your current setup: Creating mocked content provider. ok Testing mocked provider: get indexable documents. (2 items) ok Loading search platform. (Elasticsearch) ok Testing search platform. fail In CurlFactory.php line 146: cURL error 60: SSL certificate problem: self-signed certificate in certificate chain (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://SERVER_ADDRESS:9200/ I also tried the Let's Encrypt certificate URL provided by unRaid as the address entered in Nextcloud under Administration / Full Text Search / Address of the Servlet.

Thank you for the explanation. Thus far, all the drives i have replaced have either failed or gone offline (disabled). In each case, i replaced the disk with a new one and rebuild did the rest. Next time i will place the array in maintenance mode, and review what repair options are available.