quattro

Has anyone else ever gotten this error? clean install, getting this error when doing an initial build: Finished - added 0 files. Duration: 00:00:01 I had the plugin installed before and it successfully did an initial build and export. But after upgrading the plugin I began getting this error. I removed the plugin, deleted the plugin folder under \boot\config\plugins and rebooted, but still getting the error. Logs are empty.

Thanks, will do. Also, thanks for such a great tool

Strange as I've always unmounted before removing it, but thanks for the quick reply. Was just hoping to avoid a reboot.

I inserted a usb drive I've been using with unassigned devices for months and got a "reboot" button instead of a mount button. What caused this and is there a way to avoid rebooting?

That's a beautiful explanation of what's going on. I too got the "being reconstructed" message which is very confusing. Is reconstruction different from rebuilding? I found instructions for adding back a drive that was disabled but appears to be good from SMART data (I suspect delayed spin up of a drive when a scheduled parity check started or a cable/power issue). The instructions I found say 1)stop the array 2) remove the disabled drive from the array 3)start the array 4)stop the array 5) assign the disabled disk to the empty slot 6)start the array in maintenance mode 7) click sync Could I just do steps 1 through 6 and not trigger the rebuild with the sync button? Why is the word reconstruct being used in this message instead of rebuild? A quick google of unraid reconstruct seems to only pull up info on reconstruct rewrite. When it comes to repairs, rebuild always seem to be the preferred terminology. What exactly is happening when this message is triggered. Thanks!

Thanks for continuing to help with this issue. I'm sure you can imagine it's been frustrating, so my apologies if I at all seemed unappreciative. I always understood it was a different driver, but thought perhaps the workaround might not be driver specific since it's just a blank file (even though it's the name of the driver config file). I guess I kinda figured the blank tg3.conf was just turning off iommu passthrough or something similar. Thanks for clarifying exactly how the fix behaves, even though it's been kinda obvious that's what it was doing, it was the only thing I tried that worked. Imagine getting to a thread with some fixes posted and those suddenly fix your issue that has kept a system down for weeks. Prior to that, I tried EVERYTHING under the sun to troubleshoot it. Like I said, clearly those changes are(seem to be) affecting my system, and it's too regular to give up and conclude it's just a coincidence that my machine boots when I make those changes. I will troubleshoot some more this weekend and get some diagnostics. Thanks again for your assistance.

Except that it's not a coincidence. I can reproduce it every time. If I enable virtualization I get the eth0 doesn't exist error. If I disable virtualization it doesn't work until I create the blank tg3.conf. I've done it 6 times just know. Multiple reboots after disabling Vt-d won't fix the eth0 does not exist error. The second I touch the tg3.conf it works the next boot. I'm fully aware of JorgeB's efforts, you can refer to my post thanking him for taking the time to look at my issue. My forum account is new, but this is not my first day at the rodeo. I'm also aware of the driver used. However the blank tg3.conf was a workaround specifically for the "eth0 doesn't exist" issue that was caused by Unraid disabling the NIC on those system that were documented. I'm aware my config hasn't been tested or documented, but that doesn't mean it's impossible that it's affected by the Vt-d issue. I'm primarily posting in detail to help others who might come across the same problem as it completely disables unraid. The Dell 7010/9010 platform is insanely popular for projects like unraid that are designed to utilize old hardware. The posts that others made helped me find a fix for my system, which was completely disabled due to this bug. Unraid is disabling my NIC, I'm certainlly curious as to why it's happening. Remeber, win10 boots fine all day long with Vt-d enabled.

So, if I go into the bios and enable Vt-d, it won't disable my NIC? What if you're wrong?

Sure seems to have been the culprit with my Intel NIC. NOTHING else would fix it after weeks of trying.

So I got the guts to reboot today, no problem. The blank tg3.conf seems to have fixed the issue that has been plaguing me for weeks. I'm feeling gutsy, so will attempt an update to 6.10.3 😮

Cool, I appreciate your time. It never really felt like a driver issue, but who knows. I finally got the gust to reboot and still have network. So I'm still standing by my assessment that it's not hardware, but I've been troubleshooting for far too many years to be foolish enough to think that a hardware issue in this scenario is impossible. I'll have time for more testing in a few days, and I'll update here in case it helps anyone else.

I was referring more to NICs being disabled, then the corruption issue that triggered the code change. Another question, if I have a NIC problem(I'm assuming you meant hardware), are you thinking there is something in 6.10 that might fix it? If I don't have a hardware issue with my NIC, what do you think happened?

I thoroughly ruled out all physical NIC issues, it's perfectly fine in windows. It's been working for 24 hours so far after the touch command. I'm running 6.9.2 and I'm not upgrading to 6.10 until the NIC issue is clearly documented. I booted about 15 times and got eth0 does not exist every time. I then logged into unraid and ran the touch command and booted with a successful DHCP IP assignment.

Thank you very much for taking the time to look at my diagnostics and logs. I greatly appreciate it, given how frustrating the last month or so has been with unraid. Any idea why would it suddenly fail to initialize after working for months? And why would it suddenly work again after disabling virtualization in the bios. And then fail again after a simple reboot? I had already created the blank tg3.conf file on the usb using windows. But I found a thread mentioning creating the file at the unraid console and suddenly it boots again. All I did was enter this command at the unraid console after logging in: touch /boot/config/modprobe.d/tg3.conf To be honest, I'm afraid to do anything now that it's running with no explanation of why it has been down most of the time for nearly a month. Why would 6.9.2 be doing this? Isn't the tg3 thread all about issues in 6.10? is the Intel 82579LM one of the NICs with corruption issues. Around the time the network issue began I was getting weird parity errors.

ifconfig shows loopback and wg0 for wireguard

I logged in and typed ethtool eth0 at the console and got this: netlink error: no device matches name (offset 24)

I've swapped cables, booted into windows with network with the exact configuration, and tried both dhcp and setting a static IP. I really don't think there is a network issue, but I'm certainly open to the possibility I've missed something. Is there anything else that would prevent an ethtool result?

Thanks for the quick response, greatly appreciated. I've attached my diagnostics log summary. tower-diagnostics-20220703-1424.zip

to clarify, it's an integrated intel 82579LM on a Dell motherboard. Also, when I put in a Windows 10 SSD, the system boots up fine live on the network.

I've been running 6.9.2 for a while with no issues. Recently after a reboot, I started getting 169.254 IP addresses with my DHCP configuration. I tried setting up a static IP and that didn't help, there still was no network connectivity. I cleaned up my network.cfg to a minimal list of settings and began getting "eth0 doesn't exist" errors. I created a clean usb to boot from, and got the same error, so seem to have ruled out any usb issues (it's plugged into a usb2 port and named unraid). I then found the tg3 thread. I created the blank tg3.conf on the clean usb and still no network. I then went into my bios and disabled VT-d, put in the original licensed USB and it booted with an IP address from DHCP and was up and running. I just rebooted and now I'm getting the "eth0 doesn't exist" errors again. I have tried enabling and disabling VT-d and placing a blank tg3.conf on the USB with no change. Thanks in advanced for any assistance getting to the bottom of this pesky unraid issue.

copying folders from a mounted unassigned drive using krusader? The data is in the process of copying right now and there are already public shares for each of the 284 folders auto-generated. I can tell they were generated from the copy operation to the new drive because some folders are empty. First, what setting if any could have initiated this auto creation of folders? I didn't see any settings for shares in krusader's settings. The unassigned drive is not shared. More importantly, is there a tool or easy way to get rid of them (some are empty, most have data). Thanks!