Jump to content

tuxbass

Members
  • Content Count

    93
  • Joined

  • Last visited

Community Reputation

0 Neutral

About tuxbass

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

623 profile views
  1. Got also extra cables, just in case; tried different SATA ports on the MOBO - still no go. Now I feel like smartmontools were incorrectly reporting non-error state. Yesterday opened smart check for the drive, and the smart test history showed "Completed without error" for all the jobs, yet there are 3 reports of UNC sectors at LBA: Error 3 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 06 c2 00 00 e0 Error: UNC 6 sectors at LBA = 0x000000c2 = 194 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 06 c2 00 00 e0 08 00:11:36.012 READ DMA ef 10 02 00 00 00 a0 08 00:11:36.012 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:36.011 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:36.011 SET FEATURES [Set transfer mode] Error 2 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c1 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c1 = 193 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c1 00 00 e0 08 00:11:28.997 READ DMA ef 10 02 00 00 00 a0 08 00:11:28.997 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:28.996 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:28.996 SET FEATURES [Set transfer mode] Error 1 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c0 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c0 = 192 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c0 00 00 e0 08 00:11:21.982 READ DMA ef 10 02 00 00 00 a0 08 00:05:27.450 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:05:27.449 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:05:27.449 SET FEATURES [Set transfer mode] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 7530 - # 2 Extended offline Completed without error 00% 7518 - # 3 Short offline Completed without error 00% 7445 - # 4 Short offline Completed without error 00% 7412 - ^ note all statuses of latest checks are marked as completed w/o error. Now I ran couple of additional short tests, and at least it admits erroneous state; latest report: root@Tower:~# smartctl -a /dev/sde smartctl 7.0 2018-12-30 r4883 [x86_64-linux-4.19.41-Unraid] (local build) Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red Device Model: WDC WD40EFRX-68WT0N0 Serial Number: WD-WCC4E3KNSS6C LU WWN Device Id: 5 0014ee 2b7cd5d6e Firmware Version: 82.00A82 User Capacity: 4,000,787,030,016 bytes [4.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat May 25 17:37:47 2019 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 115) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: (52860) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 529) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x703d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 104 3 Spin_Up_Time 0x0027 218 180 021 Pre-fail Always - 6091 4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1259 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 188 188 000 Old_age Always - 393 9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 7540 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 100 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 55 193 Load_Cycle_Count 0x0032 198 198 000 Old_age Always - 6035 194 Temperature_Celsius 0x0022 115 104 000 Old_age Always - 37 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 24 SMART Error Log Version: 1 ATA Error Count: 3 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 3 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 06 c2 00 00 e0 Error: UNC 6 sectors at LBA = 0x000000c2 = 194 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 06 c2 00 00 e0 08 00:11:36.012 READ DMA ef 10 02 00 00 00 a0 08 00:11:36.012 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:36.011 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:36.011 SET FEATURES [Set transfer mode] Error 2 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c1 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c1 = 193 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c1 00 00 e0 08 00:11:28.997 READ DMA ef 10 02 00 00 00 a0 08 00:11:28.997 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:11:28.996 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:11:28.996 SET FEATURES [Set transfer mode] Error 1 occurred at disk power-on lifetime: 7531 hours (313 days + 19 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 c0 00 00 e0 Error: UNC 1 sectors at LBA = 0x000000c0 = 192 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 c0 00 00 e0 08 00:11:21.982 READ DMA ef 10 02 00 00 00 a0 08 00:05:27.450 SET FEATURES [Enable SATA feature] ec 00 00 00 00 00 a0 08 00:05:27.449 IDENTIFY DEVICE ef 03 46 00 00 00 a0 08 00:05:27.449 SET FEATURES [Set transfer mode] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed: read failure 30% 7540 4296320 # 2 Short offline Completed: read failure 10% 7540 4329336 # 3 Short offline Completed without error 00% 7540 - # 4 Short offline Completed without error 00% 7530 - # 5 Extended offline Completed without error 00% 7518 - # 6 Short offline Completed without error 00% 7445 - # 7 Short offline Completed without error 00% 7412 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Could this be the root of it all? Can this be recovered from? Have read soft bad sectors might be recovered by writing zeros over them. Is that the case?
  2. Missed the SMART test bit. Ran it overnight, full diag included. tl;dr: no errors found. Will proceed to check the cables tonight. tower-diagnostics-20190521-1740_SMART.zip Edit: tried swapping cables with sdd drive, still the same. Tried formatting the drive - still same. Is it possible that format + not going through data re-build (how to achieve that?) might help?
  3. > This makes me thinks is still related to the UUID issue You were right again. This time started array & changed UUID of /dev/md2 (as opposed to /dev/sde1) and drive now mounts every time upon reboot. The drive is still marked as 'disabled' in array though. Tried re-adding it to the array by taking it off of it, re-adding, and doing the data re-build from the parity drive. At the beginning of rebuild it threw some IO errors as before; chose to 'continue' the rebuild in webui, then after some 9h it was done. From what I can see, it has the same data as before rebuild (which includes the data I copied there from cache when I started seeing the IO errors in syslog. No guarantee, but form what i can see, all the data is there). As mentioned, disk2 (/dev/sde1) mounts now every time when array is brought on-line, but drive still shows as 'disabled' in webui; is it because of the IO errors during rebuild? Should I pull the drive from the array once again and reformat as you suggested? Should a re-build from parity be attempted in that case? Adding longs just in case - from the time when drive was re-enabled in array and data rebuilt form parity (think it starts at line 'May 19 04:03:14 Tower kernel: md: recovery thread: recon D2 ..', and other logs after system was rebooted, and no obvious errors can no longer be seen in syslog. tower-diagnostics-20190519-1821_disk2_recovery.zip tower-diagnostics-20190520-0415_current.zip
  4. What if file is copied from say /mnt/disk1/dir/file to /mnt/user/dir2/dir/file?
  5. Is copying from disk share (eg /mnt/disk1) to user share (somewhere under /mnt/user) guaranteed to result in data loss? Would only the copy target be lost, or also the source (data on disk1)?
  6. This is never-ending. After reboot, drive 2 is unmountable again; this time seems to be a different issue. Not too sure what to do anymore. Judging by the used data on disk2, I guess it's safe to say the data is all gone? May 16 21:09:10 Tower kernel: BTRFS info (device md2): disk space caching is enabled May 16 21:09:10 Tower kernel: BTRFS info (device md2): has skinny extents May 16 21:09:10 Tower kernel: BTRFS error (device md2): bad fsid on block 21020672 May 16 21:09:10 Tower kernel: BTRFS warning (device md2): failed to read root (objectid=9): -5 May 16 21:09:10 Tower root: mount: /mnt/disk2: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error. May 16 21:09:10 Tower emhttpd: shcmd (4240): exit status: 32 May 16 21:09:10 Tower emhttpd: /mnt/disk2 mount error: No file system May 16 21:09:10 Tower emhttpd: shcmd (4241): umount /mnt/disk2 May 16 21:09:10 Tower kernel: BTRFS error (device md2): open_ctree failed root@Tower:/mnt# fdisk -l Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 2D1D29E4-02F1-424D-92A4-C70F879B3F9D Device Start End Sectors Size Type /dev/sde1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 97A12352-C3D3-49DD-8534-74235E24C9FF Device Start End Sectors Size Type /dev/sdd1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/md1: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md2: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@Tower:/mnt# blkid /dev/sde1 /dev/sde1: UUID="10fe804c-e43d-4d9c-b225-551fac35006c" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="f3b03bdc-d205-4405-b01e-b2f045413e29" root@Tower:/mnt# blkid /dev/sdd1 /dev/sdd1: UUID="c73b4aa5-be66-4536-b0d7-ff172541bbfa" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="729740b6-a655-48f3-a493-97318e1249ff" root@Tower:/mnt# btrfs fi show /dev/sde1 Label: none uuid: 10fe804c-e43d-4d9c-b225-551fac35006c Total devices 1 FS bytes used 233.10MiB devid 1 size 3.64TiB used 2.02GiB path /dev/md2 root@Tower:/mnt# btrfs fi show /dev/sdd1 Label: none uuid: c73b4aa5-be66-4536-b0d7-ff172541bbfa Total devices 1 FS bytes used 2.10TiB devid 1 size 3.64TiB used 2.10TiB path /dev/md1 tower-diagnostics-20190516-1919.zip
  7. Right, went on to generate new UUID via btrfstune -u /dev/sde1 and everything looked good. Started array, drive was added to array no problem. Then I started moving everything from cache to array (need to change cache drive) by invoking mover, which led to issues with drive, and unraid showing drive as disabled; see https://i.imgur.com/gwwUaQS.png and https://i.imgur.com/OL3olqv.png Note the mover didn't actually stop; waited until mover was done, and data can be seen under disk2. Under syslog bunch of read & write errors can be seen; is it okay to trust this data? How likely something's corrupted? (in syslog, mover is started on line "May 14 20:27:39 Tower emhttpd: req (9): cmdStartMover=Move+now&csrf_token=****************") tower-diagnostics-20190514-1941.zip
  8. How come preclear can be skipped - doesn't this break the partiy as per wiki?
  9. Right, that's odd. Guess at this point I should be following the new drive addition tutorial (ie. format & preclear), and re-add it to the array? In any case, cheers for your help man, much obliged.
  10. Was thinking the same thing, only that I'm 100% sure I haven't touched the array disks after the setup was built in the beginning. Is it possible there's some shortcut for it on the webUI, and this was done unintentionally? Or anything else that could've caused this? Are you sure that "used 1.02GiB" isn't actual data? I'm almost sure disk2 did contain something. But can't recall 100% as the server was dormant for a year or so.
  11. root@Tower:~# btrfs fi show /dev/sde1 Label: none uuid: c73b4aa5-be66-4536-b0d7-ff172541bbfa Total devices 1 FS bytes used 384.00KiB devid 1 size 3.64TiB used 1.02GiB path /dev/sde1 ... root@Tower:~# btrfs fi show /dev/sdd1 WARNING: adding device /dev/sde1 gen 16 but found an existing device /dev/sdd1 gen 6712 ERROR: cannot scan /dev/sde1: File exists Label: none uuid: c73b4aa5-be66-4536-b0d7-ff172541bbfa Total devices 1 FS bytes used 2.10TiB devid 1 size 3.64TiB used 2.10TiB path /dev/sdd1 ... root@Tower:~# blkid /dev/sde1 /dev/sde1: UUID="c73b4aa5-be66-4536-b0d7-ff172541bbfa" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="f3b03bdc-d205-4405-b01e-b2f045413e29" ... root@Tower:~# blkid /dev/sdd1 /dev/sdd1: UUID="c73b4aa5-be66-4536-b0d7-ff172541bbfa" UUID_SUB="5f56d3d8-f921-4fc5-8116-a08a2961cc32" TYPE="btrfs" PARTUUID="729740b6-a655-48f3-a493-97318e1249ff" ... root@Tower:~# fdisk -l (only showing relevant drives) Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 97A12352-C3D3-49DD-8534-74235E24C9FF Device Start End Sectors Size Type /dev/sdd1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 2D1D29E4-02F1-424D-92A4-C70F879B3F9D Device Start End Sectors Size Type /dev/sde1 64 7814037134 7814037071 3.7T Linux filesystem Both drives have same UUIDs? How's that possible? Not sure if relevant, but server was dormant from the end of 2017 (v 6.3.5) 'til last september when it was upgraded to 6.5.2, followed by 6.6.7 update couple of days ago, and 6.7.0 yesterday.
  12. Recently upgraded unraid ver, and now discovered one of the three drives (non-parity one) is no longer mounting. It's part of the array, ie not a cache drive; formatted in btrfs. 1) I can't even tell how long i've been having issues with this drive. Shouldn't unraid inform us with a pop-up or something if drive that used to be mounted is no longer operational? 2) what's next - first follow faq on this matter? Am not too sure about the first step (mounting) in that post: For a single device: replace X with actual device, don't forget the 1 in the end, e.g., /dev/sdf1 For a pool: replace X with any of the devices from the pool to mount the whole pool (as long as there are no devices missing), don't forget the 1 in the end, e.g., /dev/sdf1, if the normal read only recovery mount doesn't work, e.g., because there's a damaged or missing device you should use instead: mount -o degraded,usebackuproot,ro /dev/sdX1 /x Replace X with any of the remaining pool devices to mount the whole pool, don't forget the 1 in the end, e.g., /dev/sdf1, if all devices are present and it doesn't mount with the first device you t ried use the other(s), filesystem on one of them may be more damaged then the other(s). Note that if there are more devices missing than the profile permits for redundancy it may still mount but there will be some data missing, e.g., mounting a 4 device raid1 pool with 2 devices missing will result in missing data. As my drive is part of an array, that means it's not a single device but a pool, correct? Regardless, what is even the difference in that excerpt between the single device & pool instructions? Note in my array, the other data drive (that's ok) is mounted as /mnt/md1 (as opposed to /mnt/sdd1); should the faulty drive be mounted from /dev/sde1 or /dev/md2? In any case, tried mounting both, but got "mount(2) system call failed file exists". 3) if no way to recover the file system - isn't this the perfect moment to put parity drive to a good use? -------------------------------------- Relevant bit from syslog: May 12 20:29:13 Tower root: Starting diskload May 12 20:29:13 Tower emhttpd: Mounting disks... May 12 20:29:13 Tower emhttpd: shcmd (993): /sbin/btrfs device scan May 12 20:29:13 Tower root: ERROR: device scan failed on '/dev/md2': File exists May 12 20:29:13 Tower root: ERROR: there are 1 errors while registering devices May 12 20:29:13 Tower root: Scanning for Btrfs filesystems May 12 20:29:13 Tower emhttpd: shcmd (993): exit status: 1 May 12 20:29:13 Tower emhttpd: shcmd (994): mkdir -p /mnt/disk1 May 12 20:29:13 Tower emhttpd: shcmd (995): mount -t btrfs -o noatime,nodiratime /dev/md1 /mnt/disk1 May 12 20:29:13 Tower kernel: BTRFS info (device md1): disk space caching is enabled May 12 20:29:13 Tower kernel: BTRFS info (device md1): has skinny extents May 12 20:29:16 Tower emhttpd: shcmd (996): btrfs filesystem resize max /mnt/disk1 May 12 20:29:16 Tower root: Resize '/mnt/disk1' of 'max' May 12 20:29:16 Tower emhttpd: shcmd (997): mkdir -p /mnt/disk2 May 12 20:29:16 Tower kernel: BTRFS info (device md1): new size for /dev/md1 is 4000786976768 May 12 20:29:16 Tower emhttpd: shcmd (998): mount -t btrfs -o noatime,nodiratime /dev/md2 /mnt/disk2 May 12 20:29:16 Tower root: mount: /mnt/disk2: mount(2) system call failed: File exists. May 12 20:29:16 Tower emhttpd: shcmd (998): exit status: 32 May 12 20:29:16 Tower emhttpd: /mnt/disk2 mount error: No file system May 12 20:29:16 Tower emhttpd: shcmd (999): umount /mnt/disk2 May 12 20:29:16 Tower kernel: BTRFS warning (device md1): duplicate device fsid:devid for c73b4aa5-be66-4536-b0d7-ff172541bbfa:1 old:/dev/md1 new:/dev/md2 May 12 20:29:16 Tower root: umount: /mnt/disk2: not mounted. May 12 20:29:16 Tower emhttpd: shcmd (999): exit status: 32 May 12 20:29:16 Tower emhttpd: shcmd (1000): rmdir /mnt/disk2 May 12 20:29:16 Tower emhttpd: shcmd (1001): mkdir -p /mnt/cache May 12 20:29:16 Tower emhttpd: shcmd (1002): mount -t btrfs -o noatime,nodiratime /dev/sdc1 /mnt/cache Running 6.7.0. Diags: tower-diagnostics-20190512-1831.zip
  13. /boot/changes.txt has Version 6.3.5 listed top of the file, so I'm assuming this is the last one. Assuming the jump was in fact from 6.3.5 to 6.5.2, how bad of a damage can I be looking at?
  14. Due to lack of time, the server sat dormant for nearly a year 'til month ago or so. The OS got upgraded to ver 6.5.2, but I'm not sure which version I upgraded from, in order to go through required post-upgrade steps. Is there somewhere a log or other way of finding out what version the system was upgraded from?