August 21, 200718 yr Yes, I set all of the devices to the correct slots so no it's not that. Upgraded from 3.0 to 4.1, had to set volume name on USB media but overall it was just as the directions said until after I'd selected the drives and gone to the main page. For some reason I still have the first 4 drives listed as being incorrect with the little red balloons on them. I suspect that perhaps there's a setting for the onboard BIOS that might beincorrect. This is the very original Intel board that was used in the first iteration of the product and it has occasionally lost settings. I also wonder if perhaps in the revisions of the code if perhaps some setting might have changed - I seem to recall that the channels had to be set to "legacy"? There used to be a VERY nice page on the site with instructions that detailed what each BIOS setting needed to be - alas I cannot find them :-( Any chance this is still around and has somethnig changed? I have no monitor nor keyboard on the little beast so I'm not sure what's up - before digging I'd like to know what I'm looking for. For now I'm dead in the water so any help is appareciated! Looking forward to checking out the new features :-)
August 21, 200718 yr BLKMGK, Intel D865GLCLK BIOS settings (linked to at the bottom of this page http://www.lime-technology.com/wordpress/?page_id=19: http://www.lime-technology.com/wordpress/?page_id=14 Hope it helps, -kenshin
August 21, 200718 yr Author Gah, so obvious! Thank you - checking them now! Honestly suspect this is no big deal so not tooo worried. I might be able to just do a reset too but this is just too coincidental that it's the onboard ports on my motherboard that are whacked for me not to at least check this. Fingers crossed!
August 21, 200718 yr Author As usual a bunch of stuff was "different"! Tom has the advice for any of those settings changed over time? USB speed for instance? Sure seemed to boot MUCH faster! Sadly this did NOT clear my error. I do not think this is a loose cable since the drives are seen, they just are not seen as valid for some reason. I will reseat anyway and then tell it to reset the array I guess. Not sure what else I can do at this point - very weird!
August 21, 200718 yr Author WHOA! Now THAT was weird! Just before shutting it down I decided to have a look at the devices page again. Now, I am POSITIVE I set this right - I did them in order! I'm pretty sure I even checked it again on first power up however now having checked it a second time I fouond that the first 4 entries were back to "unassigned"! Fixed that and now I have all green - very weird (lol) but it appears healthy. Whew! Hopefully no one else hits this and if they do they will see this and poke around more before taking any drastic measures.
August 22, 200718 yr Interesting. Did the main page ever say that the drives where "Not Installed"? It sounds like you basically had to: Upgrade -> Assign the drives -> Start the array -> Restart -> Start the array - > Stop the array -> Reassign the drives -> Start the array and it worked? Whew! That's a little convoluted. Glad you were able to get it working. I hope that it doesn't mysteriously "unassign" your drives again. -kenshin
August 22, 200718 yr Author Nah, the array won't start when it sees the drives as being wrong. I powered it up, assigned drives, switched to main page, saw the problem, powered it down, powered it up, saw same problem, reassigned the drives, went to main page and it was ready to roll. Not as quick as all that mind you and maybe a few extra reboots hoping it would clear and to fiddle the BIOS but close enough. Working good now. Need to speed check it moving some DVD images but the data flow looks more steady instead of th eroller coaster I had before. It can max out a 100meg connection it looked like but my 1Gig barely breathes hard. <shrug> Fast enough to stream though so I don't care :-)
August 25, 200718 yr Author Well, guess that was too easy Last night the system began acting strange - programs began reporting shares unavailable. This morning I attempted to investigate. I issued a Samab Stop command intending to Resierfsck the specific drive that seemed to be having issues. That command worked. When I attempted to umount the disk I was informed that it was "busy". Waiting didn't help. I attempted to stop things from the WEB interface so that I could reboot using that - it hung the interface. Finally I issued a Reboot from the commandline - all processed went to sleep but no reboot I was forced to hard reset the system. Upon reboot I got the SAME error - Too many missing disks. Same disks. Reassigned them in the interface and went to main page - still showing red balloomns and same error but at least they are assigned. Looking in the Syslog it appears to be acting like the devices aren't there :-( Here's what I'm seeing: l Duplex, Flow Control: RX/TX Aug 25 08:00:34 BEAST dhcpcd[1235]: dhcpIPaddrLeaseTime=4294967295 in DHCP server response. Aug 25 08:00:34 BEAST dhcpcd[1235]: dhcpT1value is missing in DHCP server response. Assuming 2147483647 sec Aug 25 08:00:34 BEAST dhcpcd[1235]: dhcpT2value is missing in DHCP server response. Assuming 3758096383 sec Aug 25 08:00:34 BEAST dhcpcd[1235]: DHCP_OFFER received from (192.168.1.1) Aug 25 08:00:34 BEAST dhcpcd[1235]: broadcasting DHCP_REQUEST for 192.168.1.101 Aug 25 08:00:34 BEAST dhcpcd[1235]: dhcpIPaddrLeaseTime=4294967295 in DHCP server response. Aug 25 08:00:34 BEAST dhcpcd[1235]: dhcpT1value is missing in DHCP server response. Assuming 2147483647 sec Aug 25 08:00:34 BEAST dhcpcd[1235]: dhcpT2value is missing in DHCP server response. Assuming 3758096383 sec Aug 25 08:00:34 BEAST dhcpcd[1235]: DHCP_ACK received from (192.168.1.1) Aug 25 08:00:34 BEAST dhcpcd[1235]: infinite IP address lease time. Exiting Aug 25 08:00:34 BEAST ifplugd(eth0)[1324]: ifplugd 0.28 initializing. Aug 25 08:00:34 BEAST ifplugd(eth0)[1324]: Using interface eth0/00:11:11:83:5D:31 with driver <e1000> (vers ion: 7.6.5-NAPI) Aug 25 08:00:34 BEAST ifplugd(eth0)[1324]: Using detection mode: SIOCETHTOOL Aug 25 08:00:34 BEAST ifplugd(eth0)[1324]: Initialization complete, link beat detected. Aug 25 08:00:34 BEAST ifplugd(eth0)[1324]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Aug 25 08:00:34 BEAST ifplugd(eth0)[1324]: Program executed successfully. Aug 25 08:00:34 BEAST emhttp[1356]: unRAID System Management Utility version 4.1 Aug 25 08:00:34 BEAST emhttp[1356]: Copyright (C) 2005-2007, Lime Technology, LLC Aug 25 08:00:34 BEAST emhttp[1356]: Device inventory: Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:00:1f.1-scsi-1:0:1:0 (sdd) scsi-SATA_ST3400620A_5QH00QT6 Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:00:1f.1-scsi-1:0:0:0 (sdc) scsi-SATA_ST3400620A_3QG043W1 Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:00:1f.1-scsi-0:0:0:0 (sda) scsi-SATA_ST3500641A_3PM11V97 Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:00:1f.1-scsi-0:0:1:0 (sdb) scsi-SATA_ST3400632A_5NF0Z9KP Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:00.0-ide-1:1 (hdh) ata-ST3500641A_3PM00HC4 Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:00.0-ide-1:0 (hdg) ata-ST3500641A_3PM0JFCG Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:01.0-ide-1:1 (hdl) ata-ST3400620A_5QG02J9B Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:01.0-ide-1:0 (hdk) ata-WDC_WD3000JB-00KFA0_WD-WCAMR1587689 Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:01.0-ide-0:1 (hdj) ata-WDC_WD3000JB-00KFA0_WD-WCAMR1641443 Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:01.0-ide-0:0 (hdi) ata-ST3400620A_5QH030AD Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:00.0-ide-0:0 (hde) ata-ST3300831A_4NF08RJX Aug 25 08:00:34 BEAST emhttp[1356]: pci-0000:02:00.0-ide-0:1 (hdf) ata-ST3300831A_3NF0WH07 Aug 25 08:00:34 BEAST emhttp[1356]: assign_device stat /dev/disk/by-path/pci-0000:00:1f.1-ide-0:0: 2 Aug 25 08:00:34 BEAST emhttp[1356]: assign_device stat /dev/disk/by-path/pci-0000:00:1f.1-ide-0:1: 2 Aug 25 08:00:34 BEAST emhttp[1356]: assign_device stat /dev/disk/by-path/pci-0000:00:1f.1-ide-1:0: 2 Aug 25 08:00:34 BEAST emhttp[1356]: assign_device stat /dev/disk/by-path/pci-0000:00:1f.1-ide-1:1: 2 Aug 25 08:00:34 BEAST emhttp[1356]: shcmd (1): rmmod md-mod >>/var/log/go 2>&1 Aug 25 08:00:34 BEAST emhttp[1356]: shcmd (2): modprobe md-mod super=/boot/config/super.dat slots=0,0,0,0,0 ,0,0,0,33,0,33,64,34,0,34,64,56,0,56,64,57,0,57,64,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Aug 25 08:00:35 BEAST kernel: [ 58.877617] md: unRAID driver 0.92.0 installed Aug 25 08:00:35 BEAST kernel: [ 59.226389] md: xor using function: pIII_sse (4110.800 MB/sec) Aug 25 08:00:35 BEAST kernel: [ 59.227517] md: reading superblock from /boot/config/super.dat Aug 25 08:00:35 BEAST kernel: [ 59.228607] md: superblock events: 37 Aug 25 08:00:35 BEAST kernel: [ 59.228951] md0: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.228956] md0: missing Aug 25 08:00:35 BEAST kernel: [ 59.228958] md1: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.228959] md1: missing Aug 25 08:00:35 BEAST kernel: [ 59.228961] md2: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.228963] md2: missing Aug 25 08:00:35 BEAST kernel: [ 59.228964] md3: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.228966] md3: missing Aug 25 08:00:35 BEAST kernel: [ 59.228980] md4: import [33,0] (hde) ST3300831A 4NF08RJX offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.229313] md5: import [33,64] (hdf) ST3300831A 3NF0WH07 offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.229420] md6: import [34,0] (hdg) ST3500641A 3PM0JFCG offset: 63 size: 488386552 Aug 25 08:00:35 BEAST kernel: [ 59.229531] md7: import [34,64] (hdh) ST3500641A 3PM00HC4 offset: 63 size: 488386552 Aug 25 08:00:35 BEAST kernel: [ 59.229658] md8: import [56,0] (hdi) ST3400620A 5QH030AD offset: 63 size: 390711352 Aug 25 08:00:35 BEAST kernel: [ 59.229790] md9: import [56,64] (hdj) WDC WD3000JB-00KFA0 WD-WCAMR1641443 offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.229921] md10: import [57,0] (hdk) WDC WD3000JB-00KFA0 WD-WCAMR1587689 offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.230053] md11: import [57,64] (hdl) ST3400620A 5QG02J9B offset: 63 size : 390711352 Aug 25 08:00:35 BEAST kernel: [ 59.230182] md12: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.230185] md13: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.230187] md14: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.230189] md15: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.233818] md0: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.233822] md0: missing Aug 25 08:00:35 BEAST kernel: [ 59.233824] md1: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.233826] md1: missing Aug 25 08:00:35 BEAST kernel: [ 59.233828] md2: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.233829] md2: missing Aug 25 08:00:35 BEAST kernel: [ 59.233831] md3: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.233833] md3: missing Aug 25 08:00:35 BEAST kernel: [ 59.233845] md4: import [33,0] (hde) ST3300831A 4NF08RJX offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.234175] md5: import [33,64] (hdf) ST3300831A 3NF0WH07 offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.234263] md6: import [34,0] (hdg) ST3500641A 3PM0JFCG offset: 63 size: 488386552 Aug 25 08:00:35 BEAST kernel: [ 59.234349] md7: import [34,64] (hdh) ST3500641A 3PM00HC4 offset: 63 size: 488386552 Aug 25 08:00:35 BEAST kernel: [ 59.234435] md8: import [56,0] (hdi) ST3400620A 5QH030AD offset: 63 size: 390711352 Aug 25 08:00:35 BEAST kernel: [ 59.234552] md9: import [56,64] (hdj) WDC WD3000JB-00KFA0 WD-WCAMR1641443 offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.234684] md10: import [57,0] (hdk) WDC WD3000JB-00KFA0 WD-WCAMR1587689 offset: 63 size: 293036152 Aug 25 08:00:35 BEAST kernel: [ 59.234813] md11: import [57,64] (hdl) ST3400620A 5QG02J9B offset: 63 size : 390711352 Aug 25 08:00:35 BEAST kernel: [ 59.234895] md12: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.234897] md13: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.234899] md14: import: no device Aug 25 08:00:35 BEAST kernel: [ 59.234901] md15: import: no device Aug 25 08:00:35 BEAST emhttp[1356]: shcmd (3): killall -w smbd nmbd Aug 25 08:00:36 BEAST emhttp[1356]: Scanning user shares... Aug 25 08:00:36 BEAST emhttp[1356]: shcmd (4): rm -r /mnt/user/* 2>/dev/null Aug 25 08:00:36 BEAST emhttp[1356]: merge_dir opendir: No such file or directory Aug 25 08:00:36 BEAST emhttp[1356]: shcmd (5): /usr/sbin/nmbd -D Aug 25 08:00:36 BEAST emhttp[1356]: shcmd (6): /usr/sbin/smbd -D Aug 25 08:00:46 BEAST in.telnetd[1396]: connect from 192.168.1.120 (192.168.1.120) Aug 25 08:00:49 BEAST login[1397]: ROOT LOGIN on `pts/0' from `monster' Aug 25 08:01:08 BEAST kernel: [ 92.223670] md0: import: no device Aug 25 08:01:08 BEAST kernel: [ 92.223676] md0: missing Aug 25 08:01:08 BEAST kernel: [ 92.223678] md1: import: no device Aug 25 08:01:08 BEAST kernel: [ 92.223680] md1: missing Aug 25 08:01:08 BEAST kernel: [ 92.223682] md2: import: no device Aug 25 08:01:08 BEAST kernel: [ 92.223684] md2: missing Aug 25 08:01:08 BEAST kernel: [ 92.223685] md3: import: no device Aug 25 08:01:08 BEAST kernel: [ 92.223687] md3: missing <snip> I'm going to recycle the machine via the WEB interface but if it's still red afterwards I'll be stuck I think. I'll check physical connections etc. but after that not sure - BIOS maybe?
August 25, 200718 yr Author Reboot changed nothing. Went through the BIOS and found a couple of things like a serial port enabled but nothing major - drives ARE seen by the BIOS just fine! Tailing the syslog I again see "no such device errors" and have red balloons but it also shows those first 4 slots not assigned. Assign them in the Devices page and now we have green balloons. Array is now starting up but Disk1 and Disk11 are just sitting at "mounting" with reads incrementing on ALL disks and writes appearing on Parity, Disk1, and Disk11 Syslog last message says something about not being able to shrink the filesystem on-line. I cannot afford to lose this datas so I sure hope that this is recovarable. Worse I have a party tomorrow and had HOPED to be able to use my A/V system! It's not clear what's going on and the array is not accessible - the HD activity light is having a party. I'm not sure what to do Tailed the log from Telnet not console. I'm seeing a TON of messages like -> Aug 25 08:38:30 BEAST emhttp[1101]: oldpath=/mnt/disk6/MP3/Various Artists - SLC Punk/Various Artists - SLC Punk - 06 - Remones - Cretin Hop.mp3 already exists It seems to be rebuilding SOMETHING but I do not know what. Okay, it's up. I can access data on the last disk no problem and the others appear okay. Tom, a better status would be VERY nice as well as an explanation if possible. Parity check is running, I'm going to stop the array though and do a FSCK. I do not trust things at this point... Seems this is no longer valid -> http://lime-technology.com/forum/index.php?topic=463.0 /dev/md1 does not exist. Better and better. I'm going to restart the array with crossed fingers and await some advice. NOT a big Linux guy here and some of this is making no sense since Tom has given advice in 4.x threads about using /dev/md1. System appears to AGAIN be checking quite a few of my files like I saw above but pretty quick this time. system is up claiming VALID Parity this time <shiver> I'm checking it anyway...
August 25, 200718 yr Author Syslog is talking to me Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.044299] ------------[ cut here ]------------ Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.044553] invalid opcode: 0000 [#1] Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.045550] CPU: 0 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.045552] EIP: 0060:[<c017af43>] Not tainted VLI Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.045553] EFLAGS: 00010246 (2.6.22.1 #3) Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.045916] EIP is at reiserfs_cache_bitmap_metadata+0x74/0x7c Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.046041] eax: e4a54000 ebx: f8e5fb00 ecx: ffffffff edx: e4a53ffc Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.046169] esi: ed470160 edi: 00000000 ebp: f8e5fb00 esp: ecfe1c1c Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.046298] ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.046423] Process smbd (pid: 2855, ti=ecfe0000 task=dffe5ab0 task.ti=ecfe0000) Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.046552] Stack: ed470160 03600000 f36ff000 c017affb 00001000 f8e6210c 00000000 ecfe1ec4 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.047415] 000006c0 ecfe1cac 00000ba4 f36ff000 c0179943 00000001 ecfe1c70 00000000 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.048276] 00000000 f8e5fb00 000006c0 ecfe1ec4 00000000 00000000 000006c0 f36ff000 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.049140] Call Trace: Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.049375] [<c017affb>] reiserfs_read_bitmap_block+0xb0/0xba Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.049580] [<c0179943>] scan_bitmap_block+0x63/0x22c Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.049783] [<c0179d74>] scan_bitmap+0x1a2/0x1fb Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.049991] [<c017ad89>] reiserfs_allocate_blocknrs+0x2cc/0x3d2 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.050193] [<c0184ba2>] reiserfs_allocate_blocks_for_region+0x1f0/0x1141 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.050402] [<c0191b31>] search_for_position_by_key+0x4b/0x306 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.050608] [<c0198db6>] do_journal_end+0x11a/0x86c Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.050808] [<c0180299>] make_cpu_key+0x43/0x4a Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.051008] [<c0190cf9>] pathrelse+0x1b/0x26 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.051214] [<c01865a4>] reiserfs_prepare_file_region_for_write+0x4ad/0x77d Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.051426] [<c0159e8a>] file_update_time+0x86/0x8b Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.051631] [<c0186bcd>] reiserfs_file_write+0x359/0x4bc Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.051841] [<c014ad69>] vfs_write+0x8b/0x106 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.052047] [<c014af59>] sys_pwrite64+0x48/0x5f Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.052256] [<c0103a62>] syscall_call+0x7/0xb Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.052463] ======================= Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.052590] Code: 40 74 d2 b9 1f 00 00 00 0f a3 0a 19 c0 85 c0 75 0f 8d 04 0f 66 89 03 0f b7 43 02 40 66 89 43 02 49 79 e5 eb b0 66 83 3b 00 75 04 <0f> 0b eb fe 5b 5e 5f c3 55 89 d1 57 89 c7 56 53 83 ec 10 8b 58 Message from syslogd@BEAST at Sat Aug 25 08:57:06 2007 ... BEAST kernel: [ 1831.057822] EIP: [<c017af43>] reiserfs_cache_bitmap_metadata+0x74/0x7c SS:ESP 0068:ecfe1c1c Aug 25 08:57:06 BEAST kernel: [ 1831.044299] ------------[ cut here ]------------ Aug 25 08:57:06 BEAST kernel: [ 1831.044430] kernel BUG at fs/reiserfs/bitmap.c:1287! Aug 25 08:57:06 BEAST kernel: [ 1831.044553] invalid opcode: 0000 [#1] Aug 25 08:57:06 BEAST kernel: [ 1831.044674] Modules linked in: md_mod ide_disk pdc202xx_new ata_piix libata piix ide_core e1000 Aug 25 08:57:06 BEAST kernel: [ 1831.045550] CPU: 0 Aug 25 08:57:06 BEAST kernel: [ 1831.045552] EIP: 0060:[<c017af43>] Not tainted VLI Aug 25 08:57:06 BEAST kernel: [ 1831.045553] EFLAGS: 00010246 (2.6.22.1 #3) Aug 25 08:57:06 BEAST kernel: [ 1831.045916] EIP is at reiserfs_cache_bitmap_metadata+0x74/0x7c Aug 25 08:57:06 BEAST kernel: [ 1831.046041] eax: e4a54000 ebx: f8e5fb00 ecx: ffffffff edx: e4a53ffc Aug 25 08:57:06 BEAST kernel: [ 1831.046169] esi: ed470160 edi: 00000000 ebp: f8e5fb00 esp: ecfe1c1c Aug 25 08:57:06 BEAST kernel: [ 1831.046298] ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Aug 25 08:57:06 BEAST kernel: [ 1831.046423] Process smbd (pid: 2855, ti=ecfe0000 task=dffe5ab0 task.ti=ecfe0000) Aug 25 08:57:06 BEAST kernel: [ 1831.046552] Stack: ed470160 03600000 f36ff000 c017affb 00001000 f8e6210c 00000000 ecfe1ec4 Aug 25 08:57:06 BEAST kernel: [ 1831.047415] 000006c0 ecfe1cac 00000ba4 f36ff000 c0179943 00000001 ecfe1c70 00000000 Aug 25 08:57:06 BEAST kernel: [ 1831.048276] 00000000 f8e5fb00 000006c0 ecfe1ec4 00000000 00000000 000006c0 f36ff000 Aug 25 08:57:06 BEAST kernel: [ 1831.049140] Call Trace: Aug 25 08:57:06 BEAST kernel: [ 1831.049375] [<c017affb>] reiserfs_read_bitmap_block+0xb0/0xba Aug 25 08:57:06 BEAST kernel: [ 1831.049580] [<c0179943>] scan_bitmap_block+0x63/0x22c Aug 25 08:57:06 BEAST kernel: [ 1831.049783] [<c0179d74>] scan_bitmap+0x1a2/0x1fb Aug 25 08:57:06 BEAST kernel: [ 1831.049991] [<c017ad89>] reiserfs_allocate_blocknrs+0x2cc/0x3d2 Aug 25 08:57:06 BEAST kernel: [ 1831.050193] [<c0184ba2>] reiserfs_allocate_blocks_for_region+0x1f0/0x1141 Aug 25 08:57:06 BEAST kernel: [ 1831.050402] [<c0191b31>] search_for_position_by_key+0x4b/0x306 Aug 25 08:57:06 BEAST kernel: [ 1831.050608] [<c0198db6>] do_journal_end+0x11a/0x86c Aug 25 08:57:06 BEAST kernel: [ 1831.050808] [<c0180299>] make_cpu_key+0x43/0x4a Aug 25 08:57:06 BEAST kernel: [ 1831.051008] [<c0190cf9>] pathrelse+0x1b/0x26 Aug 25 08:57:06 BEAST kernel: [ 1831.051214] [<c01865a4>] reiserfs_prepare_file_region_for_write+0x4ad/0x77d Aug 25 08:57:06 BEAST kernel: [ 1831.051426] [<c0159e8a>] file_update_time+0x86/0x8b Aug 25 08:57:06 BEAST kernel: [ 1831.051631] [<c0186bcd>] reiserfs_file_write+0x359/0x4bc Aug 25 08:57:06 BEAST kernel: [ 1831.051841] [<c014ad69>] vfs_write+0x8b/0x106 Aug 25 08:57:06 BEAST kernel: [ 1831.052047] [<c014af59>] sys_pwrite64+0x48/0x5f Aug 25 08:57:06 BEAST kernel: [ 1831.052256] [<c0103a62>] syscall_call+0x7/0xb Aug 25 08:57:06 BEAST kernel: [ 1831.052463] ======================= Aug 25 08:57:06 BEAST kernel: [ 1831.052590] Code: 40 74 d2 b9 1f 00 00 00 0f a3 0a 19 c0 85 c0 75 0f 8d 04 0f 66 89 03 0f b7 43 02 40 66 89 43 02 49 79 e5 eb b0 66 83 3b 00 75 04 <0f> 0b eb fe 5b 5e 5f c3 55 89 d1 57 89 c7 56 53 83 ec 10 8b 58 Aug 25 08:57:06 BEAST kernel: [ 1831.057822] EIP: [<c017af43>] reiserfs_cache_bitmap_metadata+0x74/0x7c SS:ESP 0068:ecfe1c1c Aug 25 08:57:06 BEAST kernel: [ 1831.058159] WARNING: at kernel/exit.c:869 do_exit() Aug 25 08:57:06 BEAST kernel: [ 1831.058287] [<c0119210>] do_exit+0x41/0x300 Aug 25 08:57:06 BEAST kernel: [ 1831.058487] [<c0104c12>] die+0x188/0x190 Aug 25 08:57:06 BEAST kernel: [ 1831.058854] [<c0104e8c>] do_invalid_op+0x0/0x8a Aug 25 08:57:06 BEAST kernel: [ 1831.059050] [<c0104f0d>] do_invalid_op+0x81/0x8a Aug 25 08:57:06 BEAST kernel: [ 1831.059253] [<c017af43>] reiserfs_cache_bitmap_metadata+0x74/0x7c Aug 25 08:57:06 BEAST kernel: [ 1831.059459] [<c02bf27e>] io_schedule+0xe/0x16 Aug 25 08:57:06 BEAST kernel: [ 1831.059665] [<c02bf3a2>] __wait_on_bit+0x4a/0x51 Aug 25 08:57:06 BEAST kernel: [ 1831.059872] [<c02bf417>] out_of_line_wait_on_bit+0x6e/0x76 Aug 25 08:57:06 BEAST kernel: [ 1831.060072] [<c0162caf>] sync_buffer+0x0/0x2e Aug 25 08:57:06 BEAST kernel: [ 1831.060278] [<c0124ed1>] wake_bit_function+0x0/0x3c Aug 25 08:57:06 BEAST kernel: [ 1831.060490] [<c02bfb9a>] error_code+0x6a/0x70 Aug 25 08:57:06 BEAST kernel: [ 1831.060699] [<c017af43>] reiserfs_cache_bitmap_metadata+0x74/0x7c Aug 25 08:57:06 BEAST kernel: [ 1831.060903] [<c017affb>] reiserfs_read_bitmap_block+0xb0/0xba Aug 25 08:57:06 BEAST kernel: [ 1831.061104] [<c0179943>] scan_bitmap_block+0x63/0x22c Aug 25 08:57:06 BEAST kernel: [ 1831.061299] [<c0179d74>] scan_bitmap+0x1a2/0x1fb Aug 25 08:57:06 BEAST kernel: [ 1831.061508] [<c017ad89>] reiserfs_allocate_blocknrs+0x2cc/0x3d2 Aug 25 08:57:06 BEAST kernel: [ 1831.061718] [<c0184ba2>] reiserfs_allocate_blocks_for_region+0x1f0/0x1141 Aug 25 08:57:06 BEAST kernel: [ 1831.061921] [<c0191b31>] search_for_position_by_key+0x4b/0x306 Aug 25 08:57:06 BEAST kernel: [ 1831.062126] [<c0198db6>] do_journal_end+0x11a/0x86c Aug 25 08:57:06 BEAST kernel: [ 1831.062329] [<c0180299>] make_cpu_key+0x43/0x4a Aug 25 08:57:06 BEAST kernel: [ 1831.062527] [<c0190cf9>] pathrelse+0x1b/0x26 Aug 25 08:57:06 BEAST kernel: [ 1831.062722] [<c01865a4>] reiserfs_prepare_file_region_for_write+0x4ad/0x77d Aug 25 08:57:06 BEAST kernel: [ 1831.062932] [<c0159e8a>] file_update_time+0x86/0x8b Aug 25 08:57:06 BEAST kernel: [ 1831.063501] [<c0186bcd>] reiserfs_file_write+0x359/0x4bc Aug 25 08:57:06 BEAST kernel: [ 1831.063673] [<c014ad69>] vfs_write+0x8b/0x106 Aug 25 08:57:06 BEAST kernel: [ 1831.063882] [<c014af59>] sys_pwrite64+0x48/0x5f Aug 25 08:57:06 BEAST kernel: [ 1831.064093] [<c0103a62>] syscall_call+0x7/0xb Aug 25 08:57:06 BEAST kernel: [ 1831.064297] ======================= That not look good.... Parity check time climing higher and higher but speed of check not dropping. Getting network errors again on downloads and access denied errors too. Restarting parity check. Parity continues to run, almost 60% done but slowing some. No additional errors thrown to Syslog or console right now. Torrents I'd been trying to download last night are reporting errors like Access Denied and Semephore Timeouts. Starting the torrents up again allows them to run a little longer but then they fail again. I can browse the drive fine so far. It appears that there's some sort of corruption requiring a FSCK but the umount command doesn't appear to work for me after I've stopped SAMBA. Ideas anyone?
August 25, 200718 yr You appear to have 4 disk controllers with 4 drives each, in the disk inventory above. Even though it looks like 12 IDE drives, the first controller *looks* like a SATA controller, and the other 3 are IDE controllers, with one unused (and a little odd). It is the 'SATA' controller that seems to be having a problem, controlling the first 4 drives sda through sdd. It seems likely to me that the driver assigned to work with the 'SATA' drives may be incompatible or having issues with your board. I found this thread, with a very similar syslog and problem (missing first 4 drives on upgrade to 4.1): http://lime-technology.com/forum/index.php?topic=885.0. In it he comments that "Anytime I reboot the system, the drives go missing again. As you said, unRaid thinks that they are SCSI/SATA and I have to reassign them again.". Your syslog 'bug' extract included this line: Modules linked in: md_mod ide_disk pdc202xx_new ata_piix libata piix ide_core e1000 I did a little research and found others having problems with the ata_piix driver. In addition, there were comments about piix being deprecated, and ata_piix used instead. That makes me wonder if both piix and ata_piix should be loaded at the same time, and are perhaps conflicting. I would love to hear from someone with far more experience in these things than I have. I would suggest typing lsmod and reporting the results (and list your motherboard). Perhaps others with the same board could do the same, and report differences. Since it may be a driver problem, why not try unRAID 4.0? It's just a matter of copying the bzroot and bzimage files from the 4.0 distro, and that would load a slightly older kernel and driver set. I believe almost all have found it to be stable. Another undesirable choice is to return to 3.0, until a future release. If it were me, I would unassign the parity drive, until the system was running reliably. I've been in similar situations where I was continuously rebuilding parity, only to crash again, which makes parity not 'trustable' even when you briefly have it. Once the problems are fixed, then turn it on. Until then, you might avoid unnecessary access to unRAID drives with data that is not backed up elsewhere.
August 26, 200718 yr Author I am running the very first original Intel board that Tom used. I do indeed have a SATA controller onboard - it's not used by anything. I *think* it's not even enabled but if so I wold expect that the software wouldn't see it - I may check that next time I'm forced to reboot <shiver> As of this time the system has completed parity checking and to my surprise says ZERO errors. I am restarting my Torrent app but won't be surprised if it again errors out (yup, it just did). I may indeed be forced to drop back a software rev but since so many are using this board I'd think it would've been one of the ones tested on. I really think the biggest issue is a need to ReiserFSCK the F/S but issuing the commands given elsewhere doesn't work. I will try it with Samba enabled and see what happens - I'll need parity again though. Thank you for pointing out that someone else also had this issue, I was starting to think it was just me
August 26, 200718 yr Author Okay, was able to Resierfsck my drives, found minor issues on 2 of them. Until I got to the last drive - the one giving me issues - #11. Attempts to mount if give me this root@BEAST:~# umount /dev/md11 umount: /mnt/disk11: device is busy umount: /mnt/disk11: device is busy This is why I thought the FSCK wasn't working earlier, seems it's JUST this drive :-( Nothing appears in syslog when I attempt to run this command. Not sure where to go from here, will remount the other drives and check parity again I guess just to be sure. Frustrating but I dare not make any radical moves for fear I'll cook data. Remounting I got a clue - looks like maybe SAMBA didn't unmount the drive whenit stopped? root@BEAST:~# mount /dev/md11 /mnt/disk11 mount: /dev/md11 already mounted or /mnt/disk11 busy mount: according to mtab, /dev/md11 is already mounted on /mnt/disk11 A mount command is also "interesting" -> root@BEAST:~# mount /dev/sda1 on /boot type vfat (rw) /dev/md11 on /mnt/disk11 type reiserfs (rw,noatime,nodiratime) /dev/md1 on /mnt/disk1 type reiserfs (rw) /dev/md2 on /mnt/disk2 type reiserfs (rw) /dev/md3 on /mnt/disk3 type reiserfs (rw) /dev/md4 on /mnt/disk4 type reiserfs (rw) /dev/md5 on /mnt/disk5 type reiserfs (rw) /dev/md6 on /mnt/disk6 type reiserfs (rw) /dev/md7 on /mnt/disk7 type reiserfs (rw) /dev/md8 on /mnt/disk8 type reiserfs (rw) /dev/md9 on /mnt/disk9 type reiserfs (rw) /dev/md10 on /mnt/disk10 type reiserfs (rw)
August 26, 200718 yr Author Gah, screwed up and forgot to restart Samba. Attempted to do a parity from WEB page, realized error, tried to cancel, systm hung, rebooted after a shutdown fromconsole appeared to hang. My day today it seems. System came up, drives seen properly, stopped Samba, umounted disk 11 and it worked - is FSCK'ing now. Slow but it cranking, fingers crossed! Heh -> 7670 found corruptions can be fixed when running with --fix-fixable
August 26, 200718 yr Author Well, a 24.6 Gig file was missing .3% when done, still checking some others. This is a drive mainly for Torrents so if that's the only issue I'm not worried since I can redownload from source. This morning when I came downstairs I was greeted with another set of "share no longer exists" errors for two files on that drive - one of them being the refilling of this file. Is anyone else getting errors like this?
August 26, 200718 yr Author Okay, I'm now checking ALL of my torrents. It's official - due to this upgrade it seems I've LOST data so beware folks. I've got at least one file (so far) that I value that no longer has anyone seeding it and data has been lost. On the previous 26+ gig file over 100megs was toast but I'm getting it back but on this last one I might not. This is NOT cool! System ran for months on the old 3.x and was fine, one day on 4.1 and data is cooked. I hadn't had a crash on 3.1 in ages, not so lucky on 4.1. Today already I've seen drive missing errors twice and once my data is checked i'll probably be dropping back to at least 4.0. Tom, I'd appreciate some guidance.
August 27, 200718 yr Wow, I hope Tom is able to help out. I'd like to know what caused the issue, as the posts I've read concerning data loss have mainly dealt with hardware issues (bad drives, etc.). Sorry to hear about your files; Good luck!
August 28, 200718 yr Author I lost several hundred megs worth of files - mostly stuff I can replace and nothing that will end my world. The weird disconnects seem to have settled down but then I've just found my torrent client locked up for the first time in as long as I can remember so who knows. From this thread -> http://lime-technology.com/forum/index.php?topic=784.0 it looks like this is an issue that may have been seen before. So far I guess Tom hasn't noticed this thread so I don't know what he thinks about it. I am continuing to run 4.1 in the hopes that this is a bump in the road from 3.x to 4.x as that thread seemed to indicate - I guess I'll know if others begin screaming about lost data or if issues crop up for me again
September 9, 200718 yr For some reason I still have the first 4 drives listed as being incorrect with the little red balloons on them. I just encountered the same problem, and I'm using the same "starter pack" Intel motherboard, so perhaps there's some hardware/software combination issue. I also recently upgraded from 3.x to 4.1 - another similarity. In my case, I don't normally leave unRaid running for days at a time, so after I did the upgrade and assigned the drives, everything seemed fine, I've moved some files around and copied to and fro. Yesterday I started the server again to play some music (farewell, Pavarotti) and that went OK. But when I tried to shutdown a couple of hours later, the admin webpage was unresponsive, and I couldn't get to the server while telnet. Interestingly, for some reason "tower" (the name I use for the server) was pointing to my router, so when I tried to telnet to "tower" I ended up at the router. Typing in the direct unRaid server IP address also didn't work. (I could ping "tower" - because it was the router - but not the IP address.) I thought it might be a glitch with the router, so I rebooted that, but that remained the same. Not knowing what else to do, I held down the power button to shut down the server, and then restarted it. This time, when I tried to open the web admin page, I got the "Too many wrong and/or missing disks" error, and like BLKMGK, they were the first four disks in the array, including the parity drive. So I rebooted (via the web page), but had the same problem. I then shutdown and restarted to get into the BIOS. Nothing had changed - they were all the same as the recommended settings. But after I quit the BIOS (exited without saving) and the boot up continued, suddenly all the drives were back online BUT it's now doing an automatic parity check, so I don't know whether any data has been affected. Looks to me like there's a real bug here.
September 9, 200718 yr I get the same error when I restart my system sometimes. It seems that the Disk.cfg file is getting changed. My system is all IDE but sometimes the first 4 drives come up as SATA. When it does, I copy a backup Disk.cfg that I made to the flash and restart the server. That corrects the problem till the next reboot.
September 9, 200718 yr Parity check has completed, and fortunately no errors found. Ftopol, what motherboard are you using, and which version of unRaid?
September 22, 200718 yr Author Never heard from Tom on this <sigh> but I see new versions have been released and I will be upgrading ASAP. Last night in the middle of a file transfer the array suddenly became unresponsive. The SSH session showed NOTHING new (I run tail in the background). Pulling up the WEB page was possible and sure enough those first 4 drives were "missing" I reassigned the drives to no avail. I then used the WEBpage to try and reboot - it hung and SSH became unresponsive - I was forced to power off. I reassigned the drives AGAIN and now the system was ready to roll. A parity check showed no errors but from past experience I wouldn't hold much faith in that - it simply means that the parity drive and data drives agree not that you don't have corruption all over your disks. If you have some corruption somewhere the parity drive will happily protect that too :-) Anyway, it's well not exactly "nice" but good to see that again I've seen an error that in the end turned out not to be unique to me. Hopefully describig how I got around it helped others. <sigh> We'll see if the later versions are more stable! Edit: Actually - seeing some of the reported issues with 4.2b4 I might hold off!
September 22, 200718 yr BLKMGK, I'm still running 4.0 and it has been rock solid stable for me, though admittedly I am not doing nearly as much read/write activity as you are with your torrents. Perhaps you can upgrade to one of the final 4.X releases, such as 4.1. Bill
Archived
This topic is now archived and is closed to further replies.