Paul_Ber Posted February 12, 2017 Share Posted February 12, 2017 I went from 6.1.9 to 6.3.1 with mostly no problems. Just did the recommended stuff. Uninstalled the old powerdown plugin. My system was upgraded from 6.1.9 to 6.2 then back to 6.1.9 almost right away. Wait a few months to go to 6.3.1. The only problem is my App tab has disappeared. I did just have a non-responsive VM and web gui and ssh not connectable, had to do a hard powerdown as the press the powerbutton once didn't shut it down gracefully as I would of seen the HD light go crazy. unraid-diagnostics-20170211-1608.zip Quote Link to comment
trurl Posted February 12, 2017 Share Posted February 12, 2017 I went from 6.1.9 to 6.3.1 with mostly no problems. Just did the recommended stuff. Uninstalled the old powerdown plugin. My system was upgraded from 6.1.9 to 6.2 then back to 6.1.9 almost right away. Wait a few months to go to 6.3.1. The only problem is my App tab has disappeared. I did just have a non-responsive VM and web gui and ssh not connectable, had to do a hard powerdown as the press the powerbutton once didn't shut it down gracefully as I would of seen the HD light go crazy. The Apps tab comes from Community Applications plugin, which you don't seem to have installed. Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 I went from 6.1.9 to 6.3.1 with mostly no problems. Just did the recommended stuff. Uninstalled the old powerdown plugin. My system was upgraded from 6.1.9 to 6.2 then back to 6.1.9 almost right away. Wait a few months to go to 6.3.1. The only problem is my App tab has disappeared. I did just have a non-responsive VM and web gui and ssh not connectable, had to do a hard powerdown as the press the powerbutton once didn't shut it down gracefully as I would of seen the HD light go crazy. Ok after the upgrade it was locking up. So I powered off and backed up the UNRAID USB stick, Formatted it and put 6.3.1 on it. Made it bootable. It is booted into the GUI. I was able to reassign my one Party Drive, 3 Data drives, 2 Cache drives. I hit start. It says mounting disk, Parity and 3 Data drives are blue on the GUI. Cache and USB is green, The UNRAID at tower is unresponsive. HD LED is not going on. I can still use the Firefox in a different tab to write this reply. I am running AMD FX-6300. Is this an AMD thing again? I had nothing but troubles a few months ago in Sept 2016 from 6.1.9 to 6.2, withing a day I went back to 6.1.9. Now this upgrade 6.1.9 to 6.3.1 is just frozen on the setup of Drives. How do I get a copy of 6.1.9 again? I have a Pro key. I am almost to try and copy the previous folder to get back to 6.1.9. ?? Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 OK now I am deep in the water. Restored the USB stick by copying the contents of the /previous folder to the root of the USB. Well I am worse off now. XDS (md3): Metadata corruption detected at xfs_agf_read_verify+0xb/0xc1, block 0x1 Fffff etc. XAGF.......Etc 3 more lines of above XDS (md3): Metadata I/o error block ("xfs_trans_read_buf_map") error 117 numblks 1 So I tried xfs_repair -nv /dev/md3 It goes to a new line and no more info, HD LED not lighting up. What now? Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 OK md3 turns out to be /dev/sdd which happens to be my parity drive. So I am trying xfs_repair -v /dev/sdd It said something about bad super lock at the very beginning then tons of "." going by. Can a bad parity drive cause the system to lock up? Could of that been my troubles all along? Quote Link to comment
Helmonder Posted February 12, 2017 Share Posted February 12, 2017 OK md3 turns out to be /dev/sdd which happens to be my parity drive. So I am trying xfs_repair -v /dev/sdd It said something about bad super lock at the very beginning then tons of "." going by. Can a bad parity drive cause the system to lock up? Could of that been my troubles all along? Stop... Your parity drive does not have a file system... So its not XFS, ReiserFS or BTRFS... Its -nothing-. Errors wrt filesystem on your parity drive are not real.. Somehow the system is thinking there is a filesystem where there is not. I have had the same issue yesterday. If you "repair" your parity drive you will corrupt parity.. Quote Link to comment
gubbgnutten Posted February 12, 2017 Share Posted February 12, 2017 OK md3 turns out to be /dev/sdd which happens to be my parity drive. So I am trying xfs_repair -v /dev/sdd It said something about bad super lock at the very beginning then tons of "." going by. Can a bad parity drive cause the system to lock up? Could of that been my troubles all along? Seems like you are panicking and trying things randomly. You are probably making things worse... /dev/sdX is not guaranteed to be consistent between boots. Did you identify the drive based on model/serial number or just sdd? If md3 is your parity drive, assignments are messed up. And parity does not have a file system, so if that is the case it shouldn't be "repaired" by xfs_repair. Also, do you understand the implications of working against /dev/sdd? Quote Link to comment
JorgeB Posted February 12, 2017 Share Posted February 12, 2017 OK now I am deep in the water. Restored the USB stick by copying the contents of the /previous folder to the root of the USB. Well I am worse off now. XDS (md3): Metadata corruption detected at xfs_agf_read_verify+0xb/0xc1, block 0x1 Fffff etc. XAGF.......Etc 3 more lines of above XDS (md3): Metadata I/o error block ("xfs_trans_read_buf_map") error 117 numblks 1 So I tried xfs_repair -nv /dev/md3 It goes to a new line and no more info, HD LED not lighting up. What now? md3 is always disk3 but you need to start the array in maintenance mode before running xfs_repair, so after starting in maintenance mode run: xfs_repair -nv /dev/md3 Quote Link to comment
itimpi Posted February 12, 2017 Share Posted February 12, 2017 OK md3 turns out to be /dev/sdd which happens to be my parity drive.that is not possible. /dev/md3 will always be equivalent to disk3. You cannot rely on the /dev/sdX type identifiers for drives as they can change between boots (particularly if a drive is not responding as it normally does). So I am trying xfs_repair -v /dev/sdd It said something about bad super lock at the very beginning then tons of "." going by. Can a bad parity drive cause the system to lock up? Could of that been my troubles all along? you cannot 'repair' the parity drive as it has no file system on it. Any attempt to do so would corrupt parity. Also if by any chance the problem disk was /dev/sdd then the command you used was incorrect. When using raw devices (i.e. Not the 'mdX' ones) you have to include the partition number (e.g. /dev/sdd1). However you should not normally work at the raw device level as repairing at that level always invalidates parity and compromises rebuilding any drives with problems. When you tried the repair on /dev/md3 did you have the repair running in Maintenance mode? You cannot repair a drive while the array is running in normal mode. Quote Link to comment
trurl Posted February 12, 2017 Share Posted February 12, 2017 Since this was getting offtrack for the 6.3.1 Release I have moved this part of the discussion to General Support. Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 I cannot get the web gui with the partiy drive connected, it happens to be sata 3. There is something about the parity drive that locks up the system. Quote Link to comment
trurl Posted February 12, 2017 Share Posted February 12, 2017 I cannot get the web gui with the partiy drive connected, it happens to be sata 3. There is something about the parity drive that locks up the system. Based on your evident confusion in this thread, we don't know what you mean when you say the parity drive is sata 3. From the diagnostics you posted earlier, assuming you haven't changed anything, your parity disk is: Feb 11 15:48:44 unRAID kernel: md: import disk0: (sdd) WDC_WD50EFRX-68L0BN1_WD-WX41DA5F87ZD size: 4883770532 Note that the only relevant part of this is that it is disk0, and its serial number is unique. We often refer to disks by serial number or a part thereof. The fact that it was sdd on this occasion is no guarantee that it will always be sdd, so sdd will only apply to this set of diagnostics and I usually don't even look at that when I am reading them. SMART for that serial number looks OK, as does SMART for your other disks. If you are now having a problem that disappears when you disconnect a drive, it may have developed after you posted your diagnostics. We need to figure out which disk you really mean though. Do you know the serial number? Quote Link to comment
gubbgnutten Posted February 12, 2017 Share Posted February 12, 2017 I cannot get the web gui with the partiy drive connected, it happens to be sata 3. There is something about the parity drive that locks up the system. SATA 3 as in the motherboard port labeled as such? That has absolutely zero connection with md3, which is always disk3 in unRAID. Disk numbering in unRAID is based on how they were assigned manually when setup, not how they happen to be connected. Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 Well the SATA 3 port is connected to my 5TB Parity drive. I disconnect that sata port and I can boot into web gui of UNRAID. With that drive plugged in, I cannot get the the web gui. I am going out today to buy a new Parity drive. And swap them out. Quote Link to comment
JorgeB Posted February 12, 2017 Share Posted February 12, 2017 See if you can get the diagnostics on the console after trying to start the array with current parity disk. Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 How do I get diags from console? How would I save that? I took a picture of what showed on the console screen right after starting array. Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 Here is the syslog I am going to try and swap out the new Parity drive I bought. My drives that have green icons are: 2 Cache, 3 data The parity drive is a orange triangle. The USB stick is running brand new 6.3.1 with key copied to config. Not sure to try only 6.1.9 on the replacement parity drive? I know that works for sure. Maybe I should try 6.1.9 without changing the parity drive? syslog.txt Quote Link to comment
Squid Posted February 12, 2017 Share Posted February 12, 2017 Swapping out the parity won't do anything. You have file system corruption on disk 3, and need to check the filesystem Quote Link to comment
JorgeB Posted February 12, 2017 Share Posted February 12, 2017 Like I said before you need to start in maintenance mode and run xfs_repair on disk3 (dev/md3) Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 OK now I am deep in the water. Restored the USB stick by copying the contents of the /previous folder to the root of the USB. Well I am worse off now. XDS (md3): Metadata corruption detected at xfs_agf_read_verify+0xb/0xc1, block 0x1 Fffff etc. XAGF.......Etc 3 more lines of above XDS (md3): Metadata I/o error block ("xfs_trans_read_buf_map") error 117 numblks 1 So I tried xfs_repair -nv /dev/md3 It goes to a new line and no more info, HD LED not lighting up. What now? md3 is always disk3 but you need to start the array in maintenance mode before running xfs_repair, so after starting in maintenance mode run: xfs_repair -nv /dev/md3 root@Tower:~# xfs_repair -nv /dev/md3 Phase 1 - find and verify superblock... - block cache size set to 3028856 entries Phase 2 - using internal log - zero log... zero_log: head block 369445 tail block 369417 - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0x1/0x200 flfirst 118 in agf 0 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan sb_fdblocks 201379159, counted 201386130 - found root inode chunk Phase 3 - for each AG... - scan (but don't 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 = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Sun Feb 12 13:20:40 2017 Phase Start End Duration Phase 1: 02/12 13:17:56 02/12 13:17:56 Phase 2: 02/12 13:17:56 02/12 13:18:00 4 seconds Phase 3: 02/12 13:18:00 02/12 13:20:38 2 minutes, 38 seconds Phase 4: 02/12 13:20:38 02/12 13:20:39 1 second Phase 5: Skipped Phase 6: 02/12 13:20:39 02/12 13:20:40 1 second Phase 7: 02/12 13:20:40 02/12 13:20:40 Total run time: 2 minutes, 44 seconds Do I run it again without the n? Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 root@Tower:~# xfs_repair -v /dev/md3 Phase 1 - find and verify superblock... - block cache size set to 3028856 entries Phase 2 - using internal log - zero log... zero_log: head block 369445 tail block 369417 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. root@Tower:~# xfs_repair -vL /dev/md3 Phase 1 - find and verify superblock... - block cache size set to 3028856 entries Phase 2 - using internal log - zero log... zero_log: head block 369445 tail block 369417 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0x1/0x200 flfirst 118 in agf 0 too large (max = 118) sb_fdblocks 201379159, counted 201386137 - 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 = 3 - agno = 1 - agno = 2 - agno = 0 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 (4:369441) is ahead of log (1:2). Format log to cycle 7. XFS_REPAIR Summary Sun Feb 12 13:33:19 2017 Phase Start End Duration Phase 1: 02/12 13:26:51 02/12 13:26:51 Phase 2: 02/12 13:26:51 02/12 13:28:00 1 minute, 9 seconds Phase 3: 02/12 13:28:00 02/12 13:30:39 2 minutes, 39 seconds Phase 4: 02/12 13:30:39 02/12 13:30:39 Phase 5: 02/12 13:30:39 02/12 13:30:39 Phase 6: 02/12 13:30:39 02/12 13:30:41 2 seconds Phase 7: 02/12 13:30:41 02/12 13:30:41 Total run time: 3 minutes, 50 seconds done So the Disk 3 is one I do not trust 100%. I know I screwed up my Parity. (I tried the xfs_repair thing on sdd, and then tried formatting, yes my super bad) So if I can get the array up, I already bought a new WD RED 6TB drive, and if the data seems fine(don't really have a choice now), can i shut down properly, swap out the 6TB for the 5TB, Turn back on run Parity on new 6TB drive? 10-12 hours later take out disk 3 which is 3TB and replace it with the 5TB one? Quote Link to comment
Paul_Ber Posted February 12, 2017 Author Share Posted February 12, 2017 Ok I am back up and running on 6.3.1, thanks for everyones help, sorry to be such a noob Well i decided to put in the new Parity Drive I bought of 6TB. After all back up and running, will swap out the Disk 3 3TB drive for the old parity 5TB. I had used a totally new 6.3.1 with just the Plus copied to config, some how one of my VMs just started to work on its own. So after the new 6TB Parity HD is sync'd, what is the process to swap out the Disk 3 3TB drive for the 5TB drive? Just have to add my Dockers again. I was freaking out for the last 24hrs. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.