September 10, 201015 yr Hello Support Community, I setup a new unRAID with 8 drives. I have 1 parity drive and 5 other drives configured for the RAID. The 5th drive would not format, and comes right back and says it is unformatted. I stopped the array, changed to another available drive and same issue. I have included the syslog.txt(compressed as it was too large to upload to the forum). I also am considering wiping out the system and starting over from stratch, but I do not have any choices to remove the array when it is stopped. I would prefer to fix the problem as I have been fighting thisa issue for weeks now. Not a good start to first time unRaid user. Thanks for any assistance. -Michael syslog.zip
September 10, 201015 yr Couple of question Michael; Are those Advanced Format technology drives (should say it on the label if they are)? If so, do you have a jumper across pins 7&8? What motherboard are you using and how are the 8 drives connected? I assume you have at least 1 PCI / pcix / pcie controller card, is there any significance with the drives that show as unformatted (i.e are they all connected to the motherboard or all connected to a controller card). What size power supply are you using and are you using any power splitters? I'd also highly recommend using the PreClear script that is available on the forum if you aren't already. One big advantage is it allows you to format the drives while outside the array so the amt of time the array is unavailable is minimized. Also, it will help in diagnosing any disk problems prior to adding them to the array. Edit - also noticed this error in your syslog: Sep 11 03:19:14 Tower kernel: REISERFS warning (device md5): sh-2006 read_super_block: bread failed (dev md5, block 2, size 4096) Sep 11 03:19:14 Tower kernel: REISERFS warning (device md5): sh-2006 read_super_block: bread failed (dev md5, block 16, size 4096) Sep 11 03:19:14 Tower kernel: REISERFS warning (device md5): sh-2021 reiserfs_fill_super: can not find reiserfs on md5 Sep 11 03:19:21 Tower logger: The problem has occurred looks like a hardware problem. If you have Sep 11 03:19:21 Tower logger: bad blocks, we advise you to get a new hard drive, because once you Sep 11 03:19:21 Tower logger: get one bad block that the disk drive internals cannot hide from Sep 11 03:19:21 Tower logger: your sight,the chances of getting more are generally said to become Sep 11 03:19:21 Tower logger: much higher (precise statistics are unknown to us), and this disk Sep 11 03:19:21 Tower logger: drive is probably not expensive enough for you to you to risk your Sep 11 03:19:21 Tower logger: time and data on it. If you don't want to follow that follow that Sep 11 03:19:21 Tower logger: advice then if you have just a few bad blocks, try writing to the Sep 11 03:19:21 Tower logger: bad blocks and see if the drive remaps the bad blocks (that means Sep 11 03:19:21 Tower logger: it takes a block it has in reserve and allocates it for use for Sep 11 03:19:21 Tower logger: of that block number). If it cannot remap the block, use badblock Sep 11 03:19:21 Tower logger: option (-B) with reiserfs utils to handle this block correctly. Sep 11 03:19:21 Tower logger: Sep 11 03:19:21 Tower logger: bread: Cannot read the block (0): (Input/output error). Sep 11 03:19:21 Tower logger: Sep 11 03:19:21 Tower kernel: __ratelimit: 23 callbacks suppressed Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 0 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 1 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 2 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 3 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 4 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 5 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 6 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 7 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 8 Sep 11 03:19:21 Tower kernel: Buffer I/O error on device md5, logical block 9 Sep 11 03:19:21 Tower emhttp: shcmd (94): mkdir /mnt/disk5 Sep 11 03:19:21 Tower emhttp: shcmd (95): set -o pipefail ; mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md5 /mnt/disk5 2>&1 | logger Sep 11 03:19:21 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md5, Sep 11 03:19:21 Tower logger: missing codepage or helper program, or other error Sep 11 03:19:21 Tower logger: In some cases useful info is found in syslog - try Sep 11 03:19:21 Tower logger: dmesg | tail or so Sep 11 03:19:21 Tower logger: Sep 11 03:19:21 Tower emhttp: _shcmd: shcmd (95): exit status: 32 Sep 11 03:19:21 Tower emhttp: disk5 mount error: 32 Sep 11 03:19:21 Tower emhttp: shcmd (96): rmdir /mnt/disk5 Sep 11 03:19:21 Tower kernel: REISERFS warning (device md5): sh-2006 read_super_block: bread failed (dev md5, block 2, size 4096) Little confused as I would take that to mean Unraid thinks disk 5 is a part of the array, but that shouldn't occur until after the format is complete - one of the others with more experience can probably give more insight. In any case, you should definitely run the preclear script on the drives.
September 10, 201015 yr I'd also highly recommend using the PreClear script that is available on the forum if you aren't already. One big advantage is it allows you to format the drives while outside the array so the amt of time the array is unavailable is minimized. Also, it will help in diagnosing any disk problems prior to adding them to the array. One small correction. The pre-clear script DOES NOT FORMAT any drive. It does partition a drive, and completely zeros it otherwise after writing a specific pre-clear signature to the drive's master boot record. To unRAID the description "unformatted" simply indicates it is unable to be mounted as a reiserfs, or that it does not contain the expected partition and file-system. Joe L.
September 10, 201015 yr A disk is part of the array as soon as it is assigned. At that point it is attached logically to am "md" device. It does not need to be formatted, in fact, the formatting is done to the /dev/mdX device and that way parity is kept in sync. The error messages all seem to indicate that disk5 (/dev/sdb) is un-responsive. It might be the cabling to it, or a poor connection, or a bad power splitter, or even an overloaded power supply. To see if it responds at all type: hdparm -i /dev/sdb This set of messages in the syslog might indicate the driver did not get loaded properly: Sep 11 03:16:28 Tower kernel: ------------[ cut here ]------------ Sep 11 03:16:28 Tower kernel: WARNING: at fs/proc/generic.c:590 proc_register+0x11c/0x14b() Sep 11 03:16:28 Tower kernel: Hardware name: X7SB4/E Sep 11 03:16:28 Tower kernel: proc_dir_entry 'scsi_tgt/mvst_scst' already registered Sep 11 03:16:28 Tower kernel: Modules linked in: mvsas(+) libsas scst scsi_transport_sas Sep 11 03:16:28 Tower kernel: Pid: 829, comm: modprobe Not tainted 2.6.32.9-unRAID #5 Sep 11 03:16:28 Tower kernel: Call Trace: Sep 11 03:16:28 Tower kernel: [<c102449e>] warn_slowpath_common+0x60/0x77 Sep 11 03:16:28 Tower kernel: [<c10244e9>] warn_slowpath_fmt+0x24/0x27 Sep 11 03:16:28 Tower kernel: [<c109cf0e>] proc_register+0x11c/0x14b Sep 11 03:16:28 Tower kernel: [<c109d0cc>] proc_mkdir_mode+0x2f/0x43 Sep 11 03:16:28 Tower kernel: [<c109d0ef>] proc_mkdir+0xf/0x11 Sep 11 03:16:28 Tower kernel: [<f841ea36>] scst_build_proc_target_dir_entries+0x55/0xdc [scst] Sep 11 03:16:28 Tower kernel: [<f8405ca9>] __scst_register_target_template+0x16c/0x3af [scst] Sep 11 03:16:28 Tower kernel: [<f8483d5d>] mvst_init+0x3b/0x5b [mvsas] Sep 11 03:16:28 Tower kernel: [<f8488895>] mvs_pci_init+0xaa5/0xaf7 [mvsas] Sep 11 03:16:28 Tower kernel: [<c10062d9>] ? dma_generic_alloc_coherent+0x0/0xdb Sep 11 03:16:28 Tower kernel: [<c1142050>] local_pci_probe+0xe/0x10 Sep 11 03:16:28 Tower kernel: [<c11426ad>] pci_device_probe+0x48/0x66 Sep 11 03:16:28 Tower kernel: [<c1194956>] driver_probe_device+0x79/0xed Sep 11 03:16:28 Tower kernel: [<c1194a0d>] __driver_attach+0x43/0x5f Sep 11 03:16:28 Tower kernel: [<c11940a7>] bus_for_each_dev+0x39/0x5a Sep 11 03:16:28 Tower kernel: [<f8490000>] ? mvs_init+0x0/0x45 [mvsas] Sep 11 03:16:28 Tower kernel: [<c119482f>] driver_attach+0x14/0x16 Sep 11 03:16:28 Tower kernel: [<c11949ca>] ? __driver_attach+0x0/0x5f Sep 11 03:16:28 Tower kernel: [<c119451c>] bus_add_driver+0x9f/0x1c5 Sep 11 03:16:28 Tower kernel: [<f8490000>] ? mvs_init+0x0/0x45 [mvsas] Sep 11 03:16:28 Tower kernel: [<c1194ccf>] driver_register+0x7b/0xd7 Sep 11 03:16:28 Tower kernel: [<f8490000>] ? mvs_init+0x0/0x45 [mvsas] Sep 11 03:16:28 Tower kernel: [<c1142882>] __pci_register_driver+0x39/0x8c Sep 11 03:16:28 Tower kernel: [<f8490000>] ? mvs_init+0x0/0x45 [mvsas] Sep 11 03:16:28 Tower kernel: [<f8490030>] mvs_init+0x30/0x45 [mvsas] Sep 11 03:16:28 Tower kernel: [<c1001139>] do_one_initcall+0x4c/0x131 Sep 11 03:16:28 Tower kernel: [<c1042e6e>] sys_init_module+0xa7/0x1dd Sep 11 03:16:28 Tower kernel: [<c1002935>] syscall_call+0x7/0xb Sep 11 03:16:28 Tower kernel: ---[ end trace 9ae3996c42852c55 ]--- Sep 11 03:16:28 Tower kernel: [829]: scst: __scst_register_target_template:253:***ERROR***: Target driver mvst_scst already registered Sep 11 03:16:28 Tower kernel: [829]: scst: __scst_register_target_template:293:***ERROR***: Failed to register target t Joe L.
September 25, 201015 yr Author Thank you Joe and Jazzy, Sorry for the delay, I was not by the unRAID server but did the following with the same issues: 1. I tried again and used the Preclear script and everything looked fine on the drive, but still the same problem. 2. Tried to add 3 different drives that are available and same issue. 3. I am using 8 WD20EVDS drives and have the jumper across pins 7&8. 4. I am using a Supermicro MBD-X7SBE, Norco RPC-4220 chassis, 4GB Memory, CORSAIR CMPSU-750TX 750W PS, 2 of the Supermicro AOC-Saslp-MV8 8-Port SAS SATA cards. Everything is from the recommended list. If you have anything additional I could try I would love to entertain this. If not, how can I go about and start from scratch again? I am unable to find any directions on starting with the default config. Thanks again for any assistance. -Michael
September 25, 201015 yr Basically, attempts to read that disk all fail. you can try that same disk with a different SATA cable, or on a different port on the disk controller, but it could be as simple as it being a defective disk. Sep 25 08:14:58 Tower emhttp: shcmd (108): mkreiserfs -q /dev/md5 2>&1 | logger Sep 25 08:14:58 Tower logger: mkreiserfs 3.6.21 (2009 www.namesys.com) Sep 25 08:14:58 Tower logger: Sep 25 08:14:58 Tower logger: Sep 25 08:14:58 Tower logger: The problem has occurred looks like a hardware problem. If you have Sep 25 08:14:58 Tower logger: bad blocks, we advise you to get a new hard drive, because once you Sep 25 08:14:58 Tower logger: get one bad block that the disk drive internals cannot hide from Sep 25 08:14:58 Tower logger: your sight,the chances of getting more are generally said to become Sep 25 08:14:58 Tower logger: much higher (precise statistics are unknown to us), and this disk Sep 25 08:14:58 Tower logger: drive is probably not expensive enough for you to you to risk your Sep 25 08:14:58 Tower logger: time and data on it. If you don't want to follow that follow that Sep 25 08:14:58 Tower logger: advice then if you have just a few bad blocks, try writing to the Sep 25 08:14:58 Tower logger: bad blocks and see if the drive remaps the bad blocks (that means Sep 25 08:14:58 Tower logger: it takes a block it has in reserve and allocates it for use for Sep 25 08:14:58 Tower logger: of that block number). If it cannot remap the block, use badblock Sep 25 08:14:58 Tower logger: option (-B) with reiserfs utils to handle this block correctly. Sep 25 08:14:58 Tower logger: Sep 25 08:14:58 Tower logger: bread: Cannot read the block (0): (Input/output error). Sep 25 08:14:58 Tower logger: Sep 25 08:14:58 Tower kernel: __ratelimit: 23 callbacks suppressed Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 0 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 1 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 2 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 3 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 4 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 5 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 6 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 7 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 8 Sep 25 08:14:58 Tower kernel: Buffer I/O error on device md5, logical block 9
September 25, 201015 yr Since you are using Norco 4220 you have another thing that you must investigate - the backplane (could have cracked trace, bad solder joint, etc.) Move this HD (or the whole set of four HDs that are sharing the cable if you do not have other cable) to a different backplane and try again. Could be as simple as that. Another thing - you are using "8 WD20EVDS drives and have the jumper across pins 7&8". I am not familiar with these - any indications that these are "advanced formatting" drives-otherwise they should run jumperless or as indicated somewhere on the labels. Edit - as per WD specs here - http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701250.pdf these are not "advanced formatting" and in this case they should run without any jumpers.
October 2, 201015 yr Author Thank you folks, I have tried everything and nothing did work. Replaced drives, put them in another row, different SAS card, etc. Same results. I finally ended up losing a full drive worth of data and give up trying to resolve this issue. I would just like to clear out the config and start from factory defaults. I could not find anything or anywhere on how to do this. If I removed all the drives and rebooted and started again, unRAID still does want to recreate the last unRAID. I am very leery of unRAID software now as I thought I had it rough with Thecus. Any assistance or pointed on what config file or command to try and delete everything. The GUI does not seem to have much functionality. Thanks for any assistance once again. Peace, Michael
October 2, 201015 yr Thank you folks, I have tried everything and nothing did work. Replaced drives, put them in another row, different SAS card, etc. Same results. I finally ended up losing a full drive worth of data and give up trying to resolve this issue. I would just like to clear out the config and start from factory defaults. I could not find anything or anywhere on how to do this. If I removed all the drives and rebooted and started again, unRAID still does want to recreate the last unRAID. I am very leery of unRAID software now as I thought I had it rough with Thecus. Any assistance or pointed on what config file or command to try and delete everything. The GUI does not seem to have much functionality. Thanks for any assistance once again. Peace, Michael Stop the array, go to the devices page on the web-management utility and Un-assign the drives you no longer want in the array. With the array still stopped, Log in on the system, console, or via telnet as "root". Type initconfig Respond to its prompt with "Yes" (respond with three letters, a capital "Y" and lower case "es") Refresh your web-management page in the browser, all the remaining assigned drives will have blue indicators and when you the press "Start" a new parity calculation based on the new configuration of data drives will begin. Joe L.
Archived
This topic is now archived and is closed to further replies.