Jump to content

JorgeB

Moderators
  • Posts

    67,797
  • Joined

  • Last visited

  • Days Won

    708

Everything posted by JorgeB

  1. Graph strongly suggests disk is linking @ SATA1 (150MB/s), SMART report will confirm. @jbartlettIMHO it would be more useful to instead of showing the device max linking speed show the actual linking speed, or both.
  2. Yes, also note that the clear thread runs for all the disks at the same position, i.e., speed will be limited by the slowest disk at that point, screenshot appears to show the end sectors of the 4TB disks, since the 3TB dis already done, so 70/80MB/s at the inner sectors for those disks is normal, probably not the controller being the bottleneck in this case, still controllers with port multipliers are not recommended for performance and stability reasons.
  3. See if this applies to you, if yes, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.: https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/
  4. Doesn't look like a disk problem, suggest swapping cables(both power and SATA) or slot with a different disk and see if the issue follows the disk.
  5. The Ryzen related info might also be applicable, if that doesn't help enable the syslog server and post that after a crash.
  6. This suggests the controller uses one or more port multipliers, if yes bandwidth of any SATA port connected to one will be divide by all 5 ports, diags would confirm.
  7. It will autostart the VMs at first array start if array autostart is enabled.
  8. Unfortunately there's nothing relevant logged, does it only crash when running the VM? Also make sure you check this: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
  9. You cannot create new threads, you're supposed to use the existing docker support thread, in this case:
  10. Issues with parity and disk7 also look power/connection related.
  11. Looks like a flash drive issue, not necessarily a bad flash drive, try re-formatting again using diskpart or use a different one to test.
  12. Next time get the diags before rebooting.
  13. Server appears to have started based on that screenshot, errors are likely a corrupt docker image, see if you can get the diagnostics using the console.
  14. Syslog starts over after every boot, enable the syslog server and post that after a crash.
  15. It's anonymized so it's usually fine.
  16. This is done on purpose, sometimes users pass-through the wrong device to a VM and it can crash Unraid, or for example lose a controller, this way you can disable array auto-start, start the array and correct the VM settings.
  17. No, disk2 will remain invalid and you'll need to start over the rebuild from the beginning.
  18. Share appears to be correctly configured, I assume a transfer to the share via SMB or locally works correctly? If yes looks like a docker issue, you might try the docker support thread, if there' is one.
  19. This is usually a power/connection issue, and since it's affecting 4 disks connected to the motherboard, disks 7, 8, 9 and 10, see if they have something in common, like a power splitter, could also be a board issue but it's not very likely, also the other two disks connect to the same controller don't show any issues.
  20. Yes, if it's OK during the rebuild it will also be when it's done.
  21. Enable the syslog server and post that after a crash.
  22. You could just update, but re-reinstalling will get the latest version, so it's OK.
  23. Reboot, it's no longer part of the array.
×
×
  • Create New...