Jump to content

quattro

Members
  • Posts

    21
  • Joined

  • Last visited

Posts posted by quattro

  1. 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.

     

     

  2. On 7/5/2022 at 9:52 AM, trurl said:

    When a write fails to a disk in the array, the disk is disabled and emulated from the parity calculation. After it is disabled the physical disk is not used again until rebuilt.

     

    Reads of the disk are emulated by reading all other disks and getting its data from the parity calculation. Writes of the disk are emulated by updating parity as if the disk had been written.

     

    That initial failed write is emulated and any subsequent writes are emulated. Since the physical disk is no longer in sync with the array it is "kicked out".

     

    That initial failed write and any subsequent writes can be recovered by rebuilding since the data can be recovered by reading the emulated disk. And the emulated disk is exactly what will be rebuilt.

     

    While a disk is being emulated (and even while it is rebuilding), you can still access the emulated data (and even write new data), provided the emulated disk is mountable. That is why we asked you to check the contents of the emulated disk since that is what is being rebuilt whether it is mountable or not.

     

    Since your screenshot and earlier diagnostics showed the disk had contents (and so was mounted) everything should come out OK.

     

     

     

    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!

  3. On 7/11/2022 at 1:51 AM, JorgeB said:

    I don't see how that is possible, let me explain what creating a blank tg3.conf does:

     

    -with Unraid v6.10.2, and only with that release, if VT-d is enabled and there is a NIC that used the tg3 driver that driver won't be loaded Unraid unless a blank tg3.conf file exists.

    -with any other Unraid release, including v6.10.3 that code doesn't exist, i.e., it won't make any difference having that file or not, even if you have a NIC that uses that driver.

     

    If your NIC isn't loading with VT-d enable it's a different problem, please post diags after booting witn VT-d enabled and VT-d disabled.

     

     

    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.  :)

     

     

  4. 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.  

     

     

  5. 4 minutes ago, JorgeB said:

    Again, it only affects Broadcom NIC, and it's resolved on v6.10.3, no NICs are disabled there.

     

    If it's really hardware it won't fix it, but since the driver is likely newer it might help if it's not.

     

    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.

    • Like 1
  6. 46 minutes ago, JorgeB said:

    It's up to you, but the data corruption issue is not NIC related, and even when we suspected it was it was with Broadcom NICs, not Intel.

    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?

     

  7. 46 minutes ago, JorgeB said:

    That suggests a NIC problem.

     

    You don't need to do that for v6.10.3, also your NIC wasn't affected even when you needed to use that.

     

    No, and those are fixed in v6.10.3, there could be some issue with your hardware though.

     

    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.

     

     

  8. 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.

     

     

     

  9. 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.

  10. 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!

×
×
  • Create New...