August 30, 20169 yr I'm afraid I did something wrong...running 6.1.3 if it matters. Was running 3 disks - parity, disk 1, and cache. Wasn't happy with the performance of BF4 in my Windows 10 VM, so I built a separate box for unraid. Asus A78M-E and an A8 7600. Transferred these 3 disks and the USB key. Booted fine. The array looked exactly like it did on my i5 machine. But after starting the array, disk 1 was shown unmountable. I stopped the array, removed isolcpus from my syslinux config (wasn't needed anymore), and rebooted. Same issue. Unassigned disk 1, started the array, and the emulated disk was also labeled unmountable. Stopped, reassigned disk 1, started, and now it's running a data-rebuild. Even though it says "device contents emulated," my share isn't present in the webUI. What did I break? Thanks in advance tower-diagnostics-20160830-0533.zip
August 30, 20169 yr Community Expert This is a strange one, unRAID is complaining that disk1's UUID is not unique, well since it's your only data disk parity will have the same, but this shouldn't be a problem, type the below on the console/putty and post output: blkid /dev/sd*1
August 30, 20169 yr Author root@Tower:~# blkid /dev/sd*1 /dev/sda1: LABEL="UNRAID" UUID="CE45-A118" TYPE="vfat" /dev/sdb1: UUID="6a1758ff-eb08-4b30-a6bc-00192450707d" TYPE="xfs" /dev/sdc1: UUID="70633c45-30d2-418e-84d6-982261f0f9c3" TYPE="xfs" /dev/sdd1: UUID="70633c45-30d2-418e-84d6-982261f0f9c3" TYPE="xfs" Odd... why is disk 1 (ending in f9c3) showing up as sdc1 and sdd1? edit: rebuild is at 96.7% so I'll have to wait until this evening to play with it more. I didn't want to try a new config once the rebuild had started.
August 30, 20169 yr Community Expert That part is normal, because you only have one data disk the parity is a 100% mirror, so it has the same UUID, just don't understand why unRAID is complaining and not mounting disk1 since this is a normal situation in that case.
August 30, 20169 yr Community Expert When the rebuild finishes you can unassign the parity disk (or maybe you need to disconnect it from the server) and start the array with the data disk only, see if it mounts.
August 30, 20169 yr Author When the rebuild finishes you can unassign the parity disk (or maybe you need to disconnect it from the server) and start the array with the data disk only, see if it mounts. Rebuild finished. I stopped the array, unassigned parity, started, and disk1 still doesn't mount. Screenshot attached. Going to try a new config. Edit: now I'm more concerned. New config, checked "parity is already valid," started the array, disk1 still didn't mount but unraid began a parity check with "write corrections to parity disk." I stopped the check after a few seconds. Just can't figure out if this is hardware related or not.
August 30, 20169 yr Author Popped the flash drive over to my other pc. Checkdisk reports no issues. Created a new folder named unraid.6.1.3 and moved the flash contents into the folder. Downloaded unraid 6.2.0-rc4 & extracted to flash. Booted, assigned drives, checked "parity is already valid," and disk1 still fails to mount. I snagged this motherboard for $30 back on black friday, 2014. Asus has released 6 firmware updates since then. I don't have time tonight, but that's up next unless there's a better suggestion. I need disk1 & parity... could easily remove the cache disk during troubleshooting as I only wanted it for docker & eventually openelec.
August 30, 20169 yr Community Expert Is disk1 actually XFS? If it is something else but unRAID thinks it should be XFS for some reason then it will appear unmountable as XFS.
August 30, 20169 yr Community Expert Edit: now I'm more concerned. New config, checked "parity is already valid," started the array, disk1 still didn't mount but unraid began a parity check with "write corrections to parity disk." This is one of the reasons you should update, this bug was fixed on v6.1.5 Did you try disconnecting the parity disk?
September 1, 20169 yr Author This is one of the reasons you should update, this bug was fixed on v6.1.5 Did you try disconnecting the parity disk? Fair to say. Tried firmware update, disconnecting the parity disk, removing the (unused) SY-PEX40039 sata expansion card, and swapping parity & disk1 ports. When none of those worked, I reinstalled the expansion card, connected disk1 & parity to it, and still won't mount. Is disk1 actually XFS? If it is something else but unRAID thinks it should be XFS for some reason then it will appear unmountable as XFS. Yes it is. Parity & Disk1 were working with an SSD as cache on my previous build. I swapped the SSD for an older 160GB HDD because I returned my previous build to bare metal Windows 10. I started the array with this configuration, and disk1 mounted fine with the new cache. Moved the 3 drives and expansion card over to the new build, and disk1 hasn't mounted since. I appreciate the help so far. I think I'll add the 160GB to the array & recalculate parity just to change the UUID on the parity. If that's how it works. I have no idea how the UUID is generated, I'm just inferring based on johnnie.black's post: That part is normal, because you only have one data disk the parity is a 100% mirror, so it has the same UUID, just don't understand why unRAID is complaining and not mounting disk1 since this is a normal situation in that case. Edit: here's the diagnostics for tonight. I'm seeing errors... Aug 31 18:55:13 Tower kernel: XFS (md1): Corruption warning: Metadata has LSN (1:445683) ahead of current LSN (1:445198). Please unmount and run xfs_repair (>= v4.3) to resolve. Aug 31 18:55:13 Tower kernel: XFS (md1): log mount/recovery failed: error -22 Aug 31 18:55:13 Tower kernel: XFS (md1): log mount failed Aug 31 18:55:13 Tower root: mount: wrong fs type, bad option, bad superblock on /dev/md1, Aug 31 18:55:13 Tower root: missing codepage or helper program, or other error Aug 31 18:55:13 Tower root: Aug 31 18:55:13 Tower root: In some cases useful info is found in syslog - try Aug 31 18:55:13 Tower root: dmesg | tail or so. Aug 31 18:55:13 Tower emhttp: shcmd: shcmd (1473): exit status: 32 Aug 31 18:55:13 Tower emhttp: mount error: No file system (32) The worst part is that I cannot create a share with disk1 emulated. Anything I name a share just displays a page "Share <name> has been deleted." There are certain files I really want to recover, and would be easy if I could simply browse there from windows file explorer like I always have. tower-diagnostics-20160831-1900.zip
September 1, 20169 yr Author Ran xfs_repair from the webui, but I don't really know what all of this means: Phase 1 - find and verify superblock... - block cache size set to 260056 entries Phase 2 - using internal log - zero log... zero_log: head block 445198 tail block 445198 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:445691) is ahead of log (1:445198). Format log to cycle 4. XFS_REPAIR Summary Wed Aug 31 19:09:41 2016 Phase Start End Duration Phase 1: 08/31 19:08:35 08/31 19:08:35 Phase 2: 08/31 19:08:35 08/31 19:08:35 Phase 3: 08/31 19:08:35 08/31 19:08:37 2 seconds Phase 4: 08/31 19:08:37 08/31 19:08:37 Phase 5: 08/31 19:08:37 08/31 19:08:37 Phase 6: 08/31 19:08:37 08/31 19:08:39 2 seconds Phase 7: 08/31 19:08:39 08/31 19:08:39 Total run time: 4 seconds done edit: apparently it means xfs_repair fixed whatever I managed to do to disk1's file system! It mounted, my old shares are back, and I've grabbed the files I really wanted (not that was looking forward to re-ripping my movies, but still...) I will say figuring out xfs_repair was a huge pain. Unraid kept setting disk1 to auto instead of xfs, which meant "check filesystem" didn't appear in the webui. Figured it out though. Thanks for the help everyone.
Archived
This topic is now archived and is closed to further replies.