Jump to content

JorgeB

Moderators
 View Profile  See their activity

  • Posts

    67,540

  • Joined

  • Last visited

  • Days Won

    707

 Content Type 

Everything posted by JorgeB

  1. JorgeB
    Same issue as this:
  2. JorgeB
    Most likely some hardware issue/compatibility, unfortunately those are difficult to diagnose remotely, basically you need to start swapping some parts around, one thing you can easily do is to test with only part of the RAM, like just 1 or 2 DIMMs.
  3. JorgeB
    Just sector 0 was corrected, which is kind of unusual, run another one.
  4. JorgeB
    Yep, of course you'll be unprotected if a drive fails, but if you don't have enough slots it's the easiest option.
  5. JorgeB
    You can't remove/add new devices to the array without a new config, but if you're going change the array config then parity won't be valid, so best to just no assign one, do the new config normally, assign all the data disks you need, don't assign parity.
  6. JorgeB
    If rebuild completed before it won't start another, i.e., if all disks have a green ball. If needed you can always do a new config with parity and just check it's already valid before array start.
  7. JorgeB
    You need to start in normal mode, or the drives won't mount. 1GB is not much for v6, but just to copy the data should be OK.
  8. JorgeB
    Problem is with the cache filesystem, you need to reformat, if there's any important data there you can try these recovery options.
  9. JorgeB
    Sorry, missed the "killed part". Most likely the issue, you need about 1GB per filesystem TB.
  10. JorgeB
    You just needed to stop array, unassign parity2, start array, stop array, re-assign parity2 to any available data slot.
  11. JorgeB
    In the flash drive: /config/go Copy all the bz* files from the release to the flash drive replacing existing ones.
  12. JorgeB
    Everything looks normal so far, enable log mirror to flash drive and start the array, if it crashes post that log.
  13. JorgeB
    What filesystem?
  14. JorgeB
    You're not the first complaining of this, but it's an elusive issue and difficult to replicate.
  15. JorgeB
    The checksum errors stated happening with the igb Intel driver a few releases ago, they are harmless, the eth0 renamed logs are normal, they are related to the docker engine.
  16. JorgeB
    Changed Priority to Other
  17. JorgeB
    Just the wait, it will take several hours. You can fist see if it mounts, but no harm in running --check, after that depends on the output of --check.
  18. JorgeB
    Yes, if you can access the old disk always good to make a comparison with the data recovered on this one, assuming reiserfs works, and it should.
  19. JorgeB
    Rsync the command doesn't need to be enable, if you mean rsync server then don't know, never needed that, but if you search the forum or google it you should get multiple hits.
  20. JorgeB
    Yep, instructions here: https://wiki.unraid.net/Check_Disk_Filesystems#Rebuilding_the_superblock And when done you'll need to run: reiserfsck --rebuild-tree --scan-whole-partition /dev/md2
  21. JorgeB
    That's not something that exists in Unriad, rsync you can use.
  22. JorgeB
    And what is RTRR?
  23. JorgeB
    That's why I said no need to say you're bumping the thread, just report that. That's worth a try, hopefully it will catch something.
  24. JorgeB
    This. XFS is usually the recommended for the average user.
  25. JorgeB
    Please don't crosspost, anyone wanting to reply use the original thread:
×
×
  • Create New...