March 7, 201115 yr If the MBR is unknown, perhaps change the background color of the pullown on the drive identification, to reinforce that the drive is not OK, and further alert the user to not start the array. And maybe taking it one step further would be to not allow them to start the array at all should a disk come up as MBR unknown. That would at least force them to come back here and request help. "It is impossible to make anything foolproof, as fools are so ingenious." -H.D. Thoreau
March 7, 201115 yr And maybe taking it one step further would be to not allow them to start the array at all should a disk come up as MBR unknown. That would at least force them to come back here and request help. I wouldn't do that, but on the pulldown, if the MBR is unknown, I would popup a message and require confirmation YES from the user that : You have selected a disk that unRAID does not recognize as containing a valid partition. In order to use this disk, unRAID will have to repartition this disk, and all data on this disk will be lost.
March 7, 201115 yr Author The difference in the partition table is the 02 01 and ff ff starting at offset 448. Yes definitely that's the problem with this disk. What is the history of this disk? I don't think there is any version of unRaid that would set up the MBR like that.
March 7, 201115 yr It is the disk1 for my bench/test rig for a long time.... it is possible that I did something that messed with it in the past in a way that earlier unRAID versions accepted it, but 5.0b6a did not like. I just tried a couple of other drives from another working unRAID 4.x box, and they were recognized OK. So the only real problem, is the multi-partition cache drive.
March 7, 201115 yr Author It is the disk1 for my bench/test rig for a long time.... it is possible that I did something that messed with it in the past in a way that earlier unRAID versions accepted it, but 5.0b6a did not like. Probably you partitioned it outside unRaid, but if this drive was ever considered "new" by any version of unRaid, it should have had it's MBR re-written. "New" would be it's state if ever used as a replacement, or used as an expansion disk, or just being present after an 'initconfig' command (or 'Restore' in older versions). I see it does have a 64-sector offset for start of partition 1, so that's a bit strange too. Oh well, I don't think this is the problem that's been reported by other users. My suspicion is that if you have a working drive that has an HPA, then you remove the HPA (via SeaTools, or hdparm command), this can be reported in -beta6/6a as 'unknown' MBR because after removing HPA, partition table probably not expanded to match new size of disk. So the only real problem, is the multi-partition cache drive. Right, that will be fixed in next beta, sorry.
March 7, 201115 yr My suspicion is that if you have a working drive that has an HPA, then you remove the HPA (via SeaTools, or hdparm command), this can be reported in -beta6/6a as 'unknown' MBR because after removing HPA, partition table probably not expanded to match new size of disk. That's very possible, since I also use this rig for testing forensic products... including their ability to detect HPA/DCO and acquire data hidden by HPA/DCO. So I'll wait on the next beta to fix the multi-partition cache drive issue. Soon?
March 8, 201115 yr I successfully installed 5.0beta6a on my new server. I had no MBR issues. I have no cache drive at the moment. My parity and one data disk are downsized 3T drives (to 2.2T). It is buliding parity now. Seems to be working fine.
March 8, 201115 yr I also succesfully upgrade to 5.0 beta6A no MBR issues although some of my disks have been in gpt and a bunch of other formats only issue i had was 1. for some reason he wouldn't boot from my flash drive got black screen with boot error so reformatted flash installed unraid and all ok he booted from the flash 2. I guess due to above issue put all disks as they were back in the array but no configuration is valid message so he started a parity sync after i started the array... Not a big issue in my eyes :0 My cache was never partitioned with multiple partitions so no issue there for me Greetz
March 8, 201115 yr Just confirmed BubbaQ's Cache disk partition bug. My cache drive was partitioned only a few weeks ago with fdisk in linux. The drive was identified fine, but after starting the array it was considered "unformatted" and the format button on the emhttp appeared. This configuration has worked fine until Beta 6, but Beta 6a destroys the partition table. Just lost all the data on the cache drive when the array was started, but I have backups of the important stuff. history of cache drive: I partitioned a seagate (ST3160815AS) 160gb drive with cfdisk primary partition 145,000MB device sdg1 second partition was 15,041MB device sdg2 mkreiserfs -l diskx /dev/sdg1 to format first partition and label it "diskx" mkswap -L swap /dev/sdg2 to format the second partition and label it "swap" Attached is the syslog The cache drive is detected as "sdg" After hitting the "start" button the log says Mar 8 19:16:30 Tower emhttp: shcmd (38): /usr/local/sbin/set_ncq sdg 1 >/dev/null Mar 8 19:16:30 Tower emhttp: writing mbr on disk 21 (sdg) with partition 1 offset 64 Can you give us an option NOT to repartition the drive? Or make it a part of the "format" button? Thanks syslog.cache.partition.error3.8.2011.txt
March 8, 201115 yr Tried running UNraid off an SD card These are the issues I got 1 can't find web interface on any ips 2 can't use "powerdown" or "shutdown now" commands. Had to reset computer 3 was able to telnet in at the usual IP address. Changed directory to /boot/config and couldn't find any files there. No "go" script or anything. When I looked at the card on my laptop everything was there. "go" script had the line "/usr/local/sbin/emhttp &" Tried this on SD and MMC cards. Haven't tried SDHC. CF cards work fine for running UNraid. The Flash GUID generated a key, and has been running a Plus server for a while. It's nice to use CF cards cause I can make backups and replace flash cards at any time. The Flash GUID is off the reader and not the CF card. No need to regenerate Flash GUID when changing CF cards. No one's going to steal the CF reader cause it's bolted into the computer. The only issue is CF cards are considered a hard disk in my Asus mb bios. If the CF card is removed and then rebooted you have to enter the bios to change the boot order of the HD's before you can boot again. SD card are considered a Removable disk, and don't have this issue Using SD cards as a viable Unraid usb drive is probably low on the priority list, but thought I would mention it.
March 8, 201115 yr Tried running UNraid off an SD card These are the issues I got 1 can't find web interface on any ips 2 can't use "powerdown" or "shutdown now" commands. Had to reset computer 3 was able to telnet in at the usual IP address. Changed directory to /boot/config and couldn't find any files there. No "go" script or anything. When I looked at the card on my laptop everything was there. "go" script had the line "/usr/local/sbin/emhttp &" Tried this on SD and MMC cards. Haven't tried SDHC. CF cards work fine for running UNraid. The Flash GUID generated a key, and has been running a Plus server for a while. It's nice to use CF cards cause I can make backups and replace flash cards at any time. The Flash GUID is off the reader and not the CF card. No need to regenerate Flash GUID when changing CF cards. No one's going to steal the CF reader cause it's bolted into the computer. The only issue is CF cards are considered a hard disk in my Asus mb bios. If the CF card is removed and then rebooted you have to enter the bios to change the boot order of the HD's before you can boot again. SD card are considered a Removable disk, and don't have this issue Using SD cards as a viable Unraid usb drive is probably low on the priority list, but thought I would mention it. Nothing in /boot usually means the flash drive was not mounted there, like it was supposed to be. This usually happens because the name on the flash drive is not UNRAID. As for using the flash card readers... it is a topic that has been discussed and the general problem with them is that they do not produce a unique GUID. There are some (I use one for testing) that works perfectly fine and has a Pro key on it.
March 9, 201115 yr Misc Fixes / Bugs with 5.0 beta 6a: 1 - (FIX) It DOES now read temperatures from BR10i attached disks 2 - It does not know how to spin down BR10i attached disks 3 - There is a double scrollbar on the far right (see attached screenshot) 4 - The banner image is too narrow - when it repeats on the top it leaves an unattractive vertical line (see attached screenshot) Check out the parity check speed (97 MB/sec). Combo of motherboard and BR10i slots with combo of green and 7200 RPM disks. I'm sure it will slow down, but this is fastest I have ever gotten!
March 9, 201115 yr Tom, I can confirm that beta6a resolves the "Replace Single Larger Disk" issue that I posted in this other thread with beta6(non-a) http://lime-technology.com/forum/index.php?topic=11526.0 It sat at "Spinning up all drives...Start array...Mounting disks..." for a while and is now doing a Data Rebuild on the replacement drive. It never made it that far before. Hopefully by this time tomorrow it will be done, (since I have 2 other new 1.5tb's that I'd also like to add soon). Estimated speed: 13.28 MB/sec Estimated finish: 1234 minutes
March 9, 201115 yr update parity check finished with no errors addons that work 1. SSH package from unmenu 2. Mover logging scripts in unmenu 3. unmenu although mymain needs an upgrade to show all info and solve the disk information pages (which i find very handy) 4. SAB/Couchpotato/sickbeard running on the cachedrive 5. hamachi without the tun driver in the package 6. cache dirs script 7. swapfile package from unmenu array spins down when possible no issues so far
March 9, 201115 yr Looks like parity checks in 6.0a are "NOCORRECT" by default, and there is no way to kick off a correcting parity check via the GUI. Is that WAD?
March 9, 201115 yr Looks like parity checks in 6.0a are "NOCORRECT" by default, and there is no way to kick off a correcting parity check via the GUI. Is that WAD? Not that I've tried it yet, but does checking "Correct any Parity-Sync errors by writing the Parity disk with corrected parity. " before clicking on the check button not do a correcting parity check?
March 9, 201115 yr Yep, I see it now. When I kicked off the parity check I didn't notice it. And when I saw in the syslog that it was running a NOCORRECT check, the checkbox wasn't being displayed. Now that I see it - all looks good!
March 9, 201115 yr 3 - There is a double scrollbar on the far right (see attached screenshot) 4 - The banner image is too narrow - when it repeats on the top it leaves an unattractive vertical line (see attached screenshot) I have always had these two issues...back to 5b2 but it only happens on my workstation at home that is running 1920x1080. The odd thing is that my work laptop runs the same rez and is fine. All other rez's I have tried seem to scale properly. You will also notice that there is a scrollbar at teh bottom. John
March 9, 201115 yr Found a rather major issue with BR10i support. It cannot spin down the disks, but it does know that they are spinning. So it continuously tries to spin down logging all the way. I ran a parity build 2 nights ago and a parity check last night and unRAID has logged over 14,000 lines. Attached is a syslog that covers the entire period of setting up the array (from first boot of 5.0b6a), assigning disks, running parity sync, and running a parity check that I throught might be helpful. You'll also see the downsized 3T drives in there. (Waiting patiently to be able to upsize them ). I saw that you stopped computing MB/sec and duration and changed the resync fields you return. I made some changes to unmenu/myMain to handle. Your commented out lines were very helpful! (Joe L., if you are reading I will send to you soon). Highlights from syslog: There is a line in there about logrotate exiting abnormally: Mar 8 04:40:02 Shark logrotate: ALERT - exited abnormally. Mostly you'll see these types of entries (1000s of lines of them): Mar 8 13:22:57 Shark emhttp: mdcmd: write: Invalid argument Mar 8 13:22:57 Shark kernel: mdcmd (47): spindown 4 Mar 8 13:22:57 Shark kernel: md: disk4: ATA_OP_STANDBYNOW1 ioctl error: -22 Also seeing this when trying to spinup the drives: Mar 8 19:12:08 Shark emhttp: Spinning up all drives... Mar 8 19:12:08 Shark kernel: mdcmd (2152): spinup 0 Mar 8 19:12:08 Shark kernel: mdcmd (2153): spinup 1 Mar 8 19:12:08 Shark kernel: mdcmd (2154): spinup 2 Mar 8 19:12:08 Shark kernel: mdcmd (2155): spinup 3 Mar 8 19:12:08 Shark kernel: md: disk3: ATA_OP_SETIDLE1 ioctl error: -22 Mar 8 19:12:08 Shark kernel: mdcmd (2156): spinup 4 Mar 8 19:12:08 Shark kernel: md: disk4: ATA_OP_SETIDLE1 ioctl error: -22 Mar 8 19:12:08 Shark kernel: mdcmd (2157): spinup 5 Mar 8 19:12:08 Shark kernel: mdcmd (2158): spinup 6 Mar 8 19:12:08 Shark kernel: md: disk6: ATA_OP_SETIDLE1 ioctl error: -22 Mar 8 19:12:08 Shark kernel: mdcmd (2159): spinup 7 Mar 8 19:12:08 Shark kernel: md: disk7: ATA_OP_SETIDLE1 ioctl error: -22 Mar 8 19:12:08 Shark kernel: mdcmd (2160): spinup 8 Mar 8 19:12:08 Shark kernel: md: disk8: ATA_OP_SETIDLE1 ioctl error: -22 Mar 8 19:12:08 Shark kernel: mdcmd (2161): spinup 9 Thanks Tom! syslog-2011-03-09.zip
March 9, 201115 yr Yeah, the constant spin-down retry became an issue. I had to set the drives on the controller to spindown NEVER, and then manage it via hdparm.
March 9, 201115 yr Yeah, the constant spin-down retry became an issue. I had to set the drives on the controller to spindown NEVER, and then manage it via hdparm. That's what I did except I forgot to remove the spin up group entry for the drives. unRAID then got confused thinking the drive was bad and disabled it.
March 9, 201115 yr Alright, I installed a new Linux Kernel on my Slackware Current distro that uses LILO to boot from /dev/sda and rebooted. Upon reboot ALL of my drives showed up as "MBR: Unknown". The data drives /dev/sdg and /dev/sdh are Sector64, the drives /dev/sdc, /dev/sdd, /dev/sde are Sector63, and parity drive /dev/sdb was made Sector64 on the previous snafu. Any idea on what happened here? "] Disk /dev/sdb: 243201 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdb1 64 3907029167 3907029104 83 Linux /dev/sdb2 0 - 0 0 Empty /dev/sdb3 0 - 0 0 Empty /dev/sdb4 0 - 0 0 Empty Disk /dev/sdc: 243201 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdc1 63 3907029167 3907029105 83 Linux /dev/sdc2 0 - 0 0 Empty /dev/sdc3 0 - 0 0 Empty /dev/sdc4 0 - 0 0 Empty Disk /dev/sdd: 243201 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdd1 63 3907029167 3907029105 83 Linux /dev/sdd2 0 - 0 0 Empty /dev/sdd3 0 - 0 0 Empty /dev/sdd4 0 - 0 0 Empty Disk /dev/sde: 243201 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sde1 63 3907029167 3907029105 83 Linux /dev/sde2 0 - 0 0 Empty /dev/sde3 0 - 0 0 Empty /dev/sde4 0 - 0 0 Empty Disk /dev/sdg: 243201 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdg1 64 3907029167 3907029104 83 Linux /dev/sdg2 0 - 0 0 Empty /dev/sdg3 0 - 0 0 Empty /dev/sdg4 0 - 0 0 Empty Disk /dev/sdh: 243201 cylinders, 255 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdh1 64 3907029167 3907029104 83 Linux /dev/sdh2 0 - 0 0 Empty /dev/sdh3 0 - 0 0 Empty /dev/sdh4 0 - 0 0 Empty Please post output of these two command: cat /sys/block/sdb/size /size"] 3907029168 3907029168 3907029168 3907029168 3907029168 3907029168 dd status=noxfer count=1 if=/dev/sdb | od -Ad -t x1 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 99 9c a8 24 cf c9 00 00 0000448 00 00 83 00 00 00 40 00 00 00 70 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 7e 8a 17 09 cf c9 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 71 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 d8 2a a5 0a cf c9 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 71 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 ce 1b 01 46 cf c9 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 71 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 be a4 7a 61 cf c9 00 00 0000448 00 00 83 00 00 00 40 00 00 00 70 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 07 d9 79 6a cf c9 00 00 0000448 00 00 83 00 00 00 40 00 00 00 70 88 e0 e8 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512
March 9, 201115 yr The bytes at addressees 440 through 445 would normally be zero in an official MBR written by the preclear script, and presumably one written by unRAID itself. 0000432 00 00 00 00 00 00 00 00 99 9c a8 24 cf c9 00 00 0000432 00 00 00 00 00 00 00 00 7e 8a 17 09 cf c9 00 00 0000432 00 00 00 00 00 00 00 00 d8 2a a5 0a cf c9 00 00 0000432 00 00 00 00 00 00 00 00 ce 1b 01 46 cf c9 00 00 0000432 00 00 00 00 00 00 00 00 be a4 7a 61 cf c9 00 00 0000432 00 00 00 00 00 00 00 00 07 d9 79 6a cf c9 00 00 Something written perhaps by your disk controller? Is it a RAID controller? Is it in a RAID mode of some kind?
March 9, 201115 yr Only /dev/sdg and /dev/sdh are connected to the BR10i. The other drives, /dev/sd[bcde] are connected to the MSI H55 Intel ICH10 SATA ports.
March 9, 201115 yr I repaired the MBRs using the mkmbr program to what unRAID 5.0b6a expects. I rebooted the system and everything was recognized as expected. I rebooted a second time and everything remains recognized.
Archived
This topic is now archived and is closed to further replies.