Jump to content

JorgeB

Moderators
  • Posts

    67,594
  • Joined

  • Last visited

  • Days Won

    707

Everything posted by JorgeB

  1. This works to spin up the disk, but it doesn't update the GUI status, so the disk won't spin down again.
  2. I mean clone old disk3 (not the emulated disk) with ddrescue.
  3. Disk1 dropped offline so there's no SMART, but this is usually not a disk problem, check/replace cables, could also be a power problem.
  4. The errors were not on the parity drive, though they are more likely to happen during a parity sync due to the heavy IO, do the errors happen to any disk on the different controllers? Maybe they are limited to a controller or backplane?
  5. Disk dropped offline, if the emulated disk is mounting and contents look correct you can rebuild on top.
  6. If it boots in safe mode it suggests a plug-in issue, remove them all and then add one by one.
  7. Boot in safe mode with all dockers/VMs disable, then start enabling them one by one an wait to see to see if you can find the culprit.
  8. Not just re-format, you need to delete existing partition, v6.9 uses a more optimized partition layout for SSDs: https://wiki.unraid.net/Unraid_OS_6.9.0#SSD_1_MiB_Partition_Alignment
  9. You can try resetting network config buy deleting network.cfg and network-rules.cfg, then reboot.
  10. Possibly the device dropped offline, diags could show more clues, you can also run smartctl on the console.
  11. Btrfs is finding data corruption, Ryzen with overclocked RAM is known to do that in some cases, reduce RAM speed and run memtest if errors persist.
  12. Cache filesystem is corrupt, best bet is to backup and re-format, there are some recovery options here if needed.
  13. Disk3 needs to be replaced, but if the filesystem in the emulated disk can't be fixed you can use ddrescue on it and it should be able to recover almost everything.
  14. If contents look correct you can rebuild, still and if you have a spare use it for the rebuild so you can keep the old disk intact if needed.
  15. Mar 5 13:51:20 Tower dhcpcd[1598]: br0: soliciting a DHCP lease Mar 5 13:51:20 Tower dhcpcd[1598]: br0: offered 10.0.0.15 from 10.0.0.1 Mar 5 13:51:25 Tower dhcpcd[1598]: br0: probing for an IPv4LL address Mar 5 13:51:30 Tower dhcpcd[1598]: br0: using IPv4LL address 169.254.148.36 Mar 5 13:51:30 Tower dhcpcd[1598]: br0: adding route to 169.254.0.0/16 Not really a network guy but looks like a network problem, it's being offered a DHCP address but it's not getting that and using a private IP address instead.
  16. That is usually a flash drive problem, try redoing it, back up current flash, redo using the UBS tool, restore config folder.
  17. Seems to be related to the Marvell IOMMU issue, you can try this (or disabling IOMMU if not needed), but if it's an option I would recommend replacing that controller with an LSI HBA, those controllers have multiple known issues and are not recommended for a long time.
  18. There have been multiple users with issues with the 8TB Ironwof + LSI, for now best to stick with v6.8.3 or connect those disks to a non LSI controller.
  19. Yes, if they shutdown before you hit the global shutdown timeout (settings - shutdown time out)
  20. For now run a filesystem check on the emulated disk1, not the actual disk.
  21. That's expected, libvirt is where the XMLs are stored, and should always have a backup.
×
×
  • Create New...