Gico Posted January 8, 2019 Author Share Posted January 8, 2019 One should have a backup to do that. It's plan to do that, hopefully this year. The original Disk11 is currently an unassigned device, device sdt. I ran repair on this device and still can't mount it: Jan 8 16:21:26 Juno unassigned.devices: Mount of '/dev/sdt1' failed. Error message: mount: /mnt/disks/WDC_WD101KRYZ-01JPDB0_7PGZ04BC: wrong fs type, bad option, bad superblock on /dev/sdt1, missing codepage or helper program, or other error. Following is the current xfs_repair report. Any suggestions? root@Juno:~# xfs_repair -nv /dev/sdt1 Phase 1 - find and verify superblock... - block cache size set to 690752 entries Phase 2 - using internal log - zero log... zero_log: head block 0 tail block 0 - scan filesystem freespace and inode maps... - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 1 - agno = 3 - agno = 0 - agno = 4 - agno = 6 - agno = 5 - agno = 7 - agno = 8 - agno = 9 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Quote Link to comment
itimpi Posted January 8, 2019 Share Posted January 8, 2019 You need to remove the -n option if you want a repair to be done. With the n present only a check is run (as indicated by the last line of the output). Quote Link to comment
Gico Posted January 8, 2019 Author Share Posted January 8, 2019 (edited) I already did this and still it doesn't mount. Edited January 8, 2019 by Gico Quote Link to comment
trurl Posted January 8, 2019 Share Posted January 8, 2019 1 hour ago, Gico said: One should have a backup to do that. It's plan to do that, hopefully this year. If you don't have a copy of anything important and irreplaceable that should be your first priority. Quote Link to comment
Gico Posted January 8, 2019 Author Share Posted January 8, 2019 This is only TV shows and movies. Losing it/some of it would be sad, but won't break my heart. For the important and irreplaceable stuff I have a Crashplan service. Quote Link to comment
JorgeB Posted January 8, 2019 Share Posted January 8, 2019 3 hours ago, Gico said: I already did this and still it doesn't mount. Since there's a clone of that disk on the array it will have the same UUID, and it won't mount because of that, you can change the one on the UD disk with: xfs_admin -U generate /dev/sdX1 Note the 1 in the end Quote Link to comment
Gico Posted January 9, 2019 Author Share Posted January 9, 2019 12 hours ago, johnnie.black said: Since there's a clone of that disk on the array it will have the same UUID, and it won't mount because of that, you can change the one on the UD disk with: xfs_admin -U generate /dev/sdX1 Note the 1 in the end That did it. Both original disk and the replacement are identical. 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.