TaterSalad Posted August 21, 2013 Share Posted August 21, 2013 Back story: I dual boot my UNRAID box with Windows. I occasionally need to boot into Windows. This normally works fine. However, I made the mistake this time of not disconnecting my UNRAID drives before booting into Windows. I am guessing this may have corrupted my filesystems. After booting back into UNRAID and starting the array, my 4 data disks now show as Unformatted. # reiserfsck --check /dev/md1 ..says I need to do an --rebuild-sb. Checking the others disks with reiserfsck say the same. Should I try a --rebuild-sb ? Do I issue this against /dev/mdX while the array is up? Or against /dev/sdX1? Using UNRAID Version 5.0RC11 Relevant syslog: 1 Aug 20 20:14:36 tower emhttp: Spinning up all drives... 2 Aug 20 20:14:36 tower kernel: mdcmd (30): spinup 0 3 Aug 20 20:14:36 tower kernel: mdcmd (31): spinup 1 4 Aug 20 20:14:36 tower kernel: mdcmd (32): spinup 2 5 Aug 20 20:14:36 tower kernel: mdcmd (33): spinup 3 6 Aug 20 20:14:36 tower kernel: mdcmd (34): spinup 4 7 Aug 20 20:14:36 tower emhttp: shcmd (27): /usr/local/sbin/set_ncq sda 1 >/dev/null 8 Aug 20 20:14:36 tower emhttp: shcmd (28): /usr/local/sbin/set_ncq sdc 1 >/dev/null 9 Aug 20 20:14:36 tower emhttp: shcmd (29): /usr/local/sbin/set_ncq sdd 1 >/dev/null 10 Aug 20 20:14:36 tower emhttp: shcmd (30): /usr/local/sbin/set_ncq sdf 1 >/dev/null 11 Aug 20 20:14:36 tower emhttp: shcmd (31): /usr/local/sbin/set_ncq sde 1 >/dev/null 12 Aug 20 20:14:36 tower emhttp: writing mbr on disk 0 (sda) with partition 1 offset 64 13 Aug 20 20:14:36 tower emhttp: re-reading (sda) partition table 14 Aug 20 20:14:36 tower kernel: sda: sda1 15 Aug 20 20:14:37 tower emhttp: writing mbr on disk 1 (sdc) with partition 1 offset 64 16 Aug 20 20:14:37 tower emhttp: re-reading (sdc) partition table 17 Aug 20 20:14:37 tower kernel: sdc: sdc1 18 Aug 20 20:14:38 tower emhttp: writing mbr on disk 2 (sdd) with partition 1 offset 64 19 Aug 20 20:14:38 tower emhttp: re-reading (sdd) partition table 20 Aug 20 20:14:38 tower kernel: sdd: sdd1 21 Aug 20 20:14:39 tower emhttp: writing mbr on disk 3 (sdf) with partition 1 offset 64 22 Aug 20 20:14:39 tower emhttp: re-reading (sdf) partition table 23 Aug 20 20:14:39 tower kernel: sdf: sdf1 24 Aug 20 20:14:40 tower emhttp: writing mbr on disk 4 (sde) with partition 1 offset 64 25 Aug 20 20:14:40 tower emhttp: re-reading (sde) partition table 26 Aug 20 20:14:40 tower kernel: sde: sde1 27 Aug 20 20:14:41 tower kernel: mdcmd (35): start STOPPED 28 Aug 20 20:14:41 tower kernel: unraid: allocating 28600K for 1280 stripes (5 disks) 29 Aug 20 20:14:41 tower emhttp: Start array... 30 Aug 20 20:14:41 tower kernel: md1: running, size: 976762552 blocks 31 Aug 20 20:14:41 tower kernel: md2: running, size: 976762552 blocks 32 Aug 20 20:14:41 tower kernel: md3: running, size: 976762552 blocks 33 Aug 20 20:14:41 tower kernel: md4: running, size: 1953514552 blocks 34 Aug 20 20:14:41 tower emhttp: shcmd (32): udevadm settle 35 Aug 20 20:14:41 tower emhttp: shcmd (33): /usr/local/sbin/emhttp_event array_started 36 Aug 20 20:14:41 tower emhttp_event: array_started 37 Aug 20 20:14:41 tower kernel: mdcmd (36): check NOCORRECT 38 Aug 20 20:14:41 tower kernel: md: recovery thread woken up ... 39 Aug 20 20:14:41 tower kernel: md: recovery thread checking parity... 40 Aug 20 20:14:41 tower emhttp: Mounting disks... 41 Aug 20 20:14:41 tower emhttp: shcmd (34): mkdir /mnt/disk4 42 Aug 20 20:14:41 tower emhttp: shcmd (35): mkdir /mnt/disk3 43 Aug 20 20:14:41 tower emhttp: shcmd (36): mkdir /mnt/disk2 44 Aug 20 20:14:41 tower emhttp: shcmd (37): mkdir /mnt/disk1 45 Aug 20 20:14:41 tower emhttp: shcmd (38): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md3 /mnt/disk3 2>&1 |logger 46 Aug 20 20:14:41 tower emhttp: shcmd (39): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md4 /mnt/disk4 2>&1 |logger 47 Aug 20 20:14:41 tower emhttp: shcmd (40): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md2 /mnt/disk2 2>&1 |logger 48 Aug 20 20:14:41 tower emhttp: shcmd (41): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md1 /mnt/disk1 2>&1 |logger 49 Aug 20 20:14:41 tower kernel: REISERFS warning (device md1): sh-2021 reiserfs_fill_super: can not find reiserfs on md1 50 Aug 20 20:14:41 tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md1, 51 Aug 20 20:14:41 tower logger: missing codepage or helper program, or other error 52 Aug 20 20:14:41 tower logger: In some cases useful info is found in syslog - try 53 Aug 20 20:14:41 tower logger: dmesg | tail or so 54 Aug 20 20:14:41 tower logger:. 55 Aug 20 20:14:41 tower emhttp: disk1 mount error: 32 56 Aug 20 20:14:41 tower emhttp: shcmd (42): rmdir /mnt/disk1 57 Aug 20 20:14:41 tower kernel: REISERFS warning (device md2): sh-2021 reiserfs_fill_super: can not find reiserfs on md2 58 Aug 20 20:14:41 tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md2, 59 Aug 20 20:14:41 tower logger: missing codepage or helper program, or other error 60 Aug 20 20:14:41 tower logger: In some cases useful info is found in syslog - try 61 Aug 20 20:14:41 tower logger: dmesg | tail or so 62 Aug 20 20:14:41 tower logger:. 63 Aug 20 20:14:41 tower emhttp: disk2 mount error: 32 64 Aug 20 20:14:41 tower emhttp: shcmd (43): rmdir /mnt/disk2 65 Aug 20 20:14:41 tower kernel: REISERFS warning (device md4): sh-2021 reiserfs_fill_super: can not find reiserfs on md4 66 Aug 20 20:14:41 tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md4, 67 Aug 20 20:14:41 tower logger: missing codepage or helper program, or other error 68 Aug 20 20:14:41 tower logger: In some cases useful info is found in syslog - try 69 Aug 20 20:14:41 tower logger: dmesg | tail or so 70 Aug 20 20:14:41 tower logger:. 71 Aug 20 20:14:41 tower emhttp: disk4 mount error: 32 72 Aug 20 20:14:41 tower emhttp: shcmd (44): rmdir /mnt/disk4 73 Aug 20 20:14:41 tower kernel: REISERFS warning (device md3): sh-2021 reiserfs_fill_super: can not find reiserfs on md3 74 Aug 20 20:14:41 tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md3, 75 Aug 20 20:14:41 tower logger: missing codepage or helper program, or other error 76 Aug 20 20:14:41 tower logger: In some cases useful info is found in syslog - try 77 Aug 20 20:14:41 tower logger: dmesg | tail or so 78 Aug 20 20:14:41 tower logger:. 79 Aug 20 20:14:41 tower emhttp: disk3 mount error: 32 80 Aug 20 20:14:41 tower emhttp: shcmd (45): rmdir /mnt/disk3 81 Aug 20 20:14:42 tower kernel: md: using 1152k window, over a total of 1953514552 blocks. 82 Aug 20 20:14:42 tower kernel: md: parity incorrect: 64 83 Aug 20 20:14:42 tower kernel: md: parity incorrect: 72 84 Aug 20 20:14:42 tower kernel: md: parity incorrect: 120 ... (parity errors go on) Quote Link to comment
Joe L. Posted August 21, 2013 Share Posted August 21, 2013 do you know for SURE that your partitions were created to start on sector 64? (because they are now according to your syslog excerpt.) If they were created starting on sector 63, then the superblock would NOT be found, because you are looking for it in the wrong place and the MBR needs t be corrected. If it was originally on sector 64, then you can proceed. (Using /dev/mdX if the array is up, or, if you do not care about keeping parity correct, on the /dev/sdX1 device, knowing you MUST run a correcting parity sync afterwords to fix it) Quote Link to comment
TaterSalad Posted August 21, 2013 Author Share Posted August 21, 2013 I honestly can't remember. However, your comment did make me notice something else. In the past, my MBR for my data disks has said MBR: unaligned but now it is showing as MBR: 4K-aligned. Could that be the issue? Quote Link to comment
dgaschk Posted August 21, 2013 Share Posted August 21, 2013 Yes. Unaligned is 63 and 4K-aligned is 64. The MBR needs to be corrected. Quote Link to comment
Joe L. Posted August 21, 2013 Share Posted August 21, 2013 Yes. Unaligned is 63 and 4K-aligned is 64. The MBR needs to be corrected. See this thread for how to confirm the location of the reiserfs file-system superblock and how to re-write the partitin to match its location. http://lime-technology.com/forum/index.php?topic=15385.msg144423#msg144423 Quote Link to comment
TaterSalad Posted August 21, 2013 Author Share Posted August 21, 2013 Here are my results from fdisk -lu [root@tower ~]# fdisk -lu /dev/sdc Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 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 identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 64 1953525167 976762552 83 Linux Partition 1 does not end on cylinder boundary. [root@tower ~]# fdisk -lu /dev/sdd Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 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 identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdd1 64 1953525167 976762552 83 Linux Partition 1 does not end on cylinder boundary. [root@tower ~]# fdisk -lu /dev/sde Disk /dev/sde: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 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 identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sde1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary. [root@tower ~]# fdisk -lu /dev/sdf Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 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 identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdf1 64 1953525167 976762552 83 Linux Partition 1 does not end on cylinder boundary. The MBR says to start on sector 64. But to confirm the super block is actually on sector 63, I did the following dd: [root@tower ~]# dd if=/dev/sdc count=195 | od -c -A d | sed 30q 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 p m p t \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0097792 256 \r 216 016 330 m 343 \0 227 332 Q 004 022 \0 \0 \0 0097808 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 263 214 274 L 0097824 204 003 \0 \0 036 \0 \0 \0 \0 \0 \0 \0 \0 020 314 003 0097840 234 \0 001 \0 R e I s E r 2 F s \0 \0 \0 0097856 003 \0 \0 \0 005 \0 035 035 002 \0 \0 \0 366 , \0 \0 0097872 001 \0 \0 \0 031 315 \0 242 7 025 B V 242 - 236 365 0097888 g 326 \r 340 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0097904 \0 \0 \0 \0 250 \0 036 \0 026 ] 307 L \0 N 355 \0 0097920 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0097984 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 0098000 ~ \0 \0 \0 177 \0 \0 \0 201 \0 \0 \0 202 \0 \0 \0 0098016 204 \0 \0 \0 212 \0 \0 \0 E 001 \0 \0 F 001 \0 \0 0098032 I 001 \0 \0 J 001 \0 \0 L 001 \0 \0 M 001 \0 \0 0098048 364 002 \0 \0 365 002 \0 \0 366 002 \0 \0 E 003 \0 \0 0098064 F 003 \0 \0 G 003 \0 \0 201 005 \0 \0 202 005 \0 \0 0098080 346 005 \0 \0 347 005 \0 \0 353 005 \0 \0 354 005 \0 \0 0098096 $ 006 \0 \0 % 006 \0 \0 & 006 \0 \0 ' 006 \0 \0 0098112 ! \a \0 \0 # \a \0 \0 1 016 \0 \0 p 016 \0 \0 0098128 315 021 \0 \0 316 021 \0 \0 327 021 \0 \0 330 021 \0 \0 0098144 " 027 \0 \0 = 027 \0 \0 < 033 \0 \0 W 033 \0 \0 0098160 y 036 \0 \0 z 036 \0 \0 | 036 \0 \0 177 036 \0 \0 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00225564 s, 44.3 MB/s The ResierFS string appears at 0097840, which corresponds to sector 63. So adjusting the MBR to start on sector 63 would look something like this, correct? # mkmbr /dev/sdX 63 0x83 Quote Link to comment
dgaschk Posted August 21, 2013 Share Posted August 21, 2013 No. See here: http://lime-technology.com/forum/index.php?topic=5072.msg47122#msg47122 Quote Link to comment
TaterSalad Posted August 21, 2013 Author Share Posted August 21, 2013 Ran unraid_partition_disk.sh in test mode and got the following output: [root@tower ~]# ./unraid_partition_disk.sh /dev/sdc ######################################################################## Model Family: SAMSUNG SpinPoint F2 EG series Device Model: SAMSUNG HD103SI Serial Number: xxxxxxxxxxxxxxxx Firmware Version: 1AG01118 User Capacity: 1,000,204,886,016 bytes Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 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 identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 64 1953525167 976762552 83 Linux Partition 1 does not end on cylinder boundary. ######################################################################## ============================================================================ == Disk /dev/sdc is NOT partitioned for unRAID properly. == expected start = 63, actual start = 64 == expected size = 1953525105, actual size = 1953525104 ============================================================================ All that seems expected. Then, the following: # ./unraid_partition_disk.sh -p /dev/sdX should modify the MBR to start the partition on sector 63, correct? Quote Link to comment
Joe L. Posted August 22, 2013 Share Posted August 22, 2013 Ran unraid_partition_disk.sh in test mode and got the following output: [root@tower ~]# ./unraid_partition_disk.sh /dev/sdc ######################################################################## Model Family: SAMSUNG SpinPoint F2 EG series Device Model: SAMSUNG HD103SI Serial Number: xxxxxxxxxxxxxxxx Firmware Version: 1AG01118 User Capacity: 1,000,204,886,016 bytes Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 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 identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 64 1953525167 976762552 83 Linux Partition 1 does not end on cylinder boundary. ######################################################################## ============================================================================ == Disk /dev/sdc is NOT partitioned for unRAID properly. == expected start = 63, actual start = 64 == expected size = 1953525105, actual size = 1953525104 ============================================================================ All that seems expected. Then, the following: # ./unraid_partition_disk.sh -p /dev/sdX should modify the MBR to start the partition on sector 63, correct? You already used the "dd' command as listed in that thread to confirm the location of the "R e I s E r 2 F s" string. That did tell you where the superblock resides for sure. The unraid_partition_disk.sh command just confirmed that the partition currently starts n sector 64. If you had invoked it with the -A option, it would have reported the partition was as expected. But, to answer your question, you can invoke unraid_partition_disk.sh -p /dev/sdc and it will set the MBR as if unRAID partitioned it for MBR-unalligned. (starting on sector 63) The then you can reboot and see if it will mount. If not, you can again try reiserfsck /dev/md1 and see what it says. Quote Link to comment
TaterSalad Posted August 22, 2013 Author Share Posted August 22, 2013 Back in business! Drives mounted and all data is there. Thank you, JoeL. How many petabytes of data have you collectively saved from your top-notch advice? Thanks again. Quote Link to comment
Joe L. Posted August 24, 2013 Share Posted August 24, 2013 Back in business! Drives mounted and all data is there. Thank you, JoeL. How many petabytes of data have you collectively saved from your top-notch advice? Thanks again. probably a few... You might want to perform a reiserfsck on each of the /dev/mdX devices, just in case windows did something else besides write the MBR.. Joe L. 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.