unRAID Server Release 5.0-beta6a Available

[SSD]

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

[bubbaQ]

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.

[limetech]

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.

[bubbaQ]

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.

[limetech]

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.

[bubbaQ]

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?

[SSD]

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.

[sacretagent]

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

 

[jamesbaker]

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

[jamesbaker]

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.

 

[prostuff1]

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.

[SSD]

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!

[SuperW2]

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

[sacretagent]

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

[SSD]

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?

[dyrewolfe]

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?

[SSD]

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!

[johnodon]

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

[SSD]

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

[BRiT]

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.

[dyrewolfe]

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.

[BRiT]

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

[Joe L.]

 

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?

 

[BRiT]

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.

[BRiT]

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.