gfjardim

Community Developer
  • Posts

    2213
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by gfjardim

  1. Hi @jbartlett, just now I've tested your app, and it's magnificent! Well done, pal! One thing I've observed is that apparently disk reads are being cached. There are options in dd that prevent this behavior, did you use them?
  2. That's correct. It creates a GPT Protective partition so Unraid can recognize it. We must remember that when Unraid was first launched, we only had MBR partitioning scheme and disks were far from archiving more than a few gigabytes. This was the way that was found to implement a layer of compatibility in the transition to > 2.2TiB hard disks.
  3. This bug was introduced when you changed the start sector of disks larger than 2.2TiB to 64, and the verification routine remain expecting it to be 1. With the fix, now the correct partition size is set even if the disk is greater nan 2.2TiB and is precleared starting on sector 64. Tell me, is that blockdev -setro op really preventing changes in the MBR? PS: The verification step of the plugin obey the same logic of the original script, so it suffered the bug too.
  4. Yep, that's it. I've committed the fix to binhex too, we should see an update soon.
  5. Update the Preclear Plugin to version 2020.03.02 and test it again.
  6. Apparently I found the bug. Please update your plugin to 2020.03.02 and test it again, please. If we validate the solution, I'll commit the fix to binhex repository.
  7. That's not needed. You could test it using the plugin so we can see if it replicates on the other script? You can run the "Verify MBR Only" opoeration.
  8. Which command you passed to preclear_binhex.sh?
  9. Maybe you got a bad USB/SATA bridge controller. Try connecting it into the controller of another hard drive you've already shucked.
  10. 🤔 All in the same port? These are drives that you're planning to shuck?
  11. All other drives were 14TB? Maybe a loose cable or a power brownout.
  12. Yep, USB dropouts. You're not the first this week. If you can test the drive connected directly to a SATA port, we can troubleshoot it.
  13. Send the diagnostics file.
  14. Hi @jbrodriguez, any chance of implementing this?
  15. @HDRW, your hard drive is ok, it's a problem with your USB dock, with it's connection cable or with your USB controller.
  16. Not about the same time, the first time it ran for about 6 hours, now it only read 8.3GiB. Please send me the output of this command: smartctl -a /dev/sdb
  17. If you can run preclear on them again and send me your diagnostics file, I appreciate.
  18. Your hard drive returned input/output errors at Feb 22 22:15:01 and that made the preclear session to fail. This could be the hard drive controller's fault or could be your USB3 dock controller's fault, but I'm confident it's your USB3 dock fault, because hard drives usually present media errors and yours doesn't. Maybe it got hot, who knows. Try replacing it or try to add a small fan toward it.
  19. You can move it to /boot/rsnapshot.conf and always invoke rsnapshot using "rsnapshot -c /boot/rsnapshot.conf" command.
  20. UDEV rules are reloaded when Preclear is uninstalled, maybe that makes rc.unassigned reload all UDEV info Unassigned Devices caches, fixing the problem.
  21. Took a look at both Preclear and UD and this make no sense. Maybe some of the cached information didn't got updated correctly. I found no scenario where Preclear can prevent UD from correctly remove a partition.
  22. You're quite welcome. Enviado de meu SM-G973F usando o Tapatalk
  23. Very strange behavior. Let's be clear, when you @neruve clicked the X button after the partition mount point, nothing happened?