unRAID Server Release 5.0-beta7 Available

Download | Release Notes

Two new features in this beta:

1. Support of hard drives larger than 2TB.

2. Support proper spin up/down for "pure" SCSI/SAS controllers.

Hard drives larger than 2TB uses GPT (GUID Partition Table) instead of MBR partitioning.  The GPT is set up so that partition 1 starts in sector 64 and uses all available space on the hard drive.  If you have a >2TB hard drive which is using MBR partitioning (that is, using just 2TB), and you wish to retain your data on that drive, do not Start your array without posting here first for instructions on how to retain your data.

Spin up/down now uses the linux "SG_IO" interface for sending drive commands (and if this fails, falls back to "HDIO" method).

The linux kernel was also updated to 2.6.37.6 in order to pick up some mvsas driver fixes.  (I wanted to update to the latest kernel release, 2.6.39.1, but parity check speed was cut by 80% using this kernel    for some reason that I haven't figured out yet.)

Very nice, thanks.

Upgrading requires same steps as prior betas?

What's the deal regarding this "mbr unknown" issue that people are getting at the moment?

Very nice, thanks.

 

Upgrading requires same steps as prior betas?

Yes, sorry, added Release Notes link in first post.

Nice one!

Thanks, I'll be trying it out soon.

Just did a comparison of webGui changes and the changes in my custom webGui. You can use my custom webGui without issue.

Awesome!

Thanks Tom!

Tom,

Nice to see GPT partitions are supported now.

Did not see it mentioned in the release notes...  (the release notes for the transition from 5.0-beta6a to 5.0-beta6b is missing )

Did you fix the bug where a cache drive with multiple partitions is considered "unknown" ??

(The bug caused unRAID to re-partition the cache drive to only have one partition, wiping out the other purposely created partitions)

For those of you who are annoyed at the speed of development, take this into consideration; Drobo still hasn't managed to make 3Tb drives usable on all of their units yet. I suspect their development team is far larger than one person.

Tom, thanks for taking a sane approach to the development of unRAID.

One thing that would make most complaints go away, be a little more transparent! I hate to say it, but twitter feed? Just post any findings or interesting tid-bits on an adhoc basis, and people won't think you've disappeared for months on end.

What a pleasant surprise this is!

Did you fix the bug where a cache drive with multiple partitions is considered "unknown" ??

(The bug caused unRAID to re-partition the cache drive to only have one partition, wiping out the other purposely created partitions)

Ditto.

I might be the first to get this far, but I loaded the new bzroot and bzimage on my test server that was running 5.0b6a and rebooted.

Now unRAID is asking for my ID/Password.   I did not have one previously for the "root" ID on the test server.

In the same way, attempting to log in via telnet blocks me with repeated login/password prompts until it closes my session with too many ineffective attempts.

OK Tom, is the root password no longer blank?  Or no longer used from the saved copy on the flash drive?  Or did I do something dumb in copying bzroot and bzimage to the test server?   (Don't worry, I can re-name my files and re-boot, but I might have to pull the flash drive to get to it, since it is internal to the server case  )

Using unMENU, the syslog has this:

Jun 7 18:06:39 Tower2 login[4905]: REPEATED login failures on `pts/0' from `192.168.2.6'

Jun 7 18:07:00 Tower2 in.telnetd[4906]: connect from 192.168.2.6 (192.168.2.6) (Routine)

Jun 7 18:07:04 Tower2 login[4907]: no shadow password for `root' on `pts/0' from `192.168.2.6'

Jun 7 18:07:15 Tower2 login[4907]: invalid password for `root' on `pts/0' from `192.168.2.6' (Logins)

Jun 7 18:07:37 Tower2 login[4907]: no shadow password for `root' on `pts/0' from `192.168.2.6'

Jun 7 18:07:40 Tower2 login[4907]: invalid password for `root' on `pts/0' from `192.168.2.6' (Logins)

Jun 7 18:07:43 Tower2 login[4907]: no shadow password for `root' on `pts/0' from `192.168.2.6'

Jun 7 18:07:45 Tower2 login[4907]: invalid password for `root' on `pts/0' from `192.168.2.6' (Logins)

Jun 7 18:07:45 Tower2 login[4907]: REPEATED login failures on `pts/0' from `192.168.2.6'

user-error...  never-mind. I copied wrong bzroot/bzimage into place.

Joe L.

Still have issue with unknown showing up as the disk type. This is different than beta 6, as that showed MBR: Unknown. What's strange is that a disk that I formatted in beta 6 (which showed correct MBR), now shows as unknown for filesystem type (same as rest of drives), but shows correct partition type.

On the main screen, the drives I assign to the correct slots bring up "Found 1 new disk". It asks me to add the disk to the array.

I haven't started my array just yet.

Joe, not getting the password issues.

Added new screenshot for array. Added syslog.

syslog.zip

If you have a >2TB hard drive which is using MBR partitioning (that is, using just 2TB), and you wish to retain your data on that drive, do not Start your array without posting here first for instructions on how to retain your data.

I am not using MBR partitioning, but have manually created an HPA, to downsize 2 3T drives each to 2.2T.

One is parity, and one is a data disk.

I also have a spare 3T drive that is precleared.  Not in the array.

I had planned to remove the HPA from the parity disk, zero the beginning of the disk, and then rebuild parity (should create a 3T parity).

Then unplug my 2.2T data drive and verify it is simulated properly.

Then rebuild the simulated 2.2T disk onto a new 3T drive (keeping the 2.2T physical disk as a backup).

If all goes well, add physical 2.2T data disk as my cache disk.  Perform some data comparision between it and the rebuilt 3T disks.

Fill the 3T disk.  Make sure it works up to close to its capacity.

Once convinced all is stable ... remove the HPA from the old 2.2T data disk, zero the beginning of the disk, run preclear on it, and add it to the array.

Finally, run a parity check.

Will this work?

Joe, not getting the password issues.

1. Support of hard drives larger than 2TB.

Joe, not getting the password issues.

Did you have a root password assigned?

Yes. However, I've tried on a VM with a clean setup (no root password), no issues.

rebuilding the parity on a 3TB hitachi drive as we speak!

i got a deal at Fry's Dallas. they were mark at $49.84 EACH (they had two of them) ... that is not a typo either. I asked the guy working what was going on and he said that they were only showing up at 800GB on their windows machines. I got home and put them into my MacPro and they showed up with 2 partions on each. one partition was 800GB and the other was unpartitioned. I reformatted them in my mac and they showed up at 3TB each. i ran all the tests from TechTool Pro 5 and they showed no errors.

So far so good.

Thanks Tom!!!

I might be the first to get this far, but I loaded the new bzroot and bzimage on my test server that was running 5.0b6a and rebooted.

 

Now unRAID is asking for my ID/Password.   I did not have one previously for the "root" ID on the test server.

 

In the same way, attempting to log in via telnet blocks me with repeated login/password prompts until it closes my session with too many ineffective attempts.

 

OK Tom, is the root password no longer blank?  Or no longer used from the saved copy on the flash drive?  Or did I do something dumb in copying bzroot and bzimage to the test server?   (Don't worry, I can re-name my files and re-boot, but I might have to pull the flash drive to get to it, since it is internal to the server case  )

 

Using unMENU, the syslog has this:

Jun 7 18:06:39 Tower2 login[4905]: REPEATED login failures on `pts/0' from `192.168.2.6'

Jun 7 18:07:00 Tower2 in.telnetd[4906]: connect from 192.168.2.6 (192.168.2.6) (Routine)

Jun 7 18:07:04 Tower2 login[4907]: no shadow password for `root' on `pts/0' from `192.168.2.6'

Jun 7 18:07:15 Tower2 login[4907]: invalid password for `root' on `pts/0' from `192.168.2.6' (Logins)

Jun 7 18:07:37 Tower2 login[4907]: no shadow password for `root' on `pts/0' from `192.168.2.6'

Jun 7 18:07:40 Tower2 login[4907]: invalid password for `root' on `pts/0' from `192.168.2.6' (Logins)

Jun 7 18:07:43 Tower2 login[4907]: no shadow password for `root' on `pts/0' from `192.168.2.6'

Jun 7 18:07:45 Tower2 login[4907]: invalid password for `root' on `pts/0' from `192.168.2.6' (Logins)

Jun 7 18:07:45 Tower2 login[4907]: REPEATED login failures on `pts/0' from `192.168.2.6'

 

Joe L.

Did you do this ...

If present, delete these files from the flash (sorry, you will have to re-enter all your users after booting this release):

- config/passwd

- config/shadow

- config/smbpasswd

basically that is what I did... and I then discovered my stupidity when I was finally able to log in...  I copied the wrong bzroot/bzimage into place.

with the correct bzroot/bzimage it works much better.

[embarrassed]

I'll go hang my head in shame now....

[/embarrassed]

Any ideas on why this is happening? I have a feeling it'd be easier just to start my server all over again... 

http://lime-technology.com/forum/index.php?topic=13371.msg126928#msg126928

Any ideas on why this is happening? I have a feeling it'd be easier just to start my server all over again... 

 

http://lime-technology.com/forum/index.php?topic=13371.msg126928#msg126928

Please post the output of the commands described in this post:

http://lime-technology.com/forum/index.php?topic=11540.msg109913#msg109913

(make sure you do it for your drive, "sdb" was used for the example)

From earlier post:

SDD - ST31000340AS:

1953523055

1+0 records in

1+0 records out

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 81 db 81 db 00 00 00 00

0000448 00 00 83 00 00 00 3f 00 00 00 30 65 70 74 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

SDA - ST31000340AS:

1953525168

1+0 records in

1+0 records out

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 a8 2f 52 92 00 00 00 00

0000448 00 00 83 00 00 00 3f 00 00 00 71 6d 70 74 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

SDC - ST31000333AS:

1953525168

1+0 records in

1+0 records out

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 3f 80 47 2e 00 00 00 00

0000448 00 00 83 00 00 00 3f 00 00 00 71 6d 70 74 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

SDE - ST31500341AS:

2930275055

1+0 records in

1+0 records out

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 22 80 47 2e 00 00 00 00

0000448 00 00 83 00 00 00 3f 00 00 00 b0 72 a8 ae 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

To "speeding ant" - you have very old Gigabyte board and at present two of the HDs are with HPA. I am not sure of your exact upgrade path so far but it was supposed for everyone to upgrade first to 4.7, check out if everything was OK and then proceed to 5.xxx.

However I do recall having a HPA was a big "no go" for upgrade to 4.7

Perhaps the "new" hard drive that you have is new because of a new second instance of the HPA, then the MBR will be affected and you may get the symptoms you have now.

BIOS:

Jun  8 10:31:40 Media kernel: DMI: Gigabyte Technology Co., Ltd. EP35-DS3/EP35-DS3, BIOS F4 06/19/2009

Jun  8 10:31:40 Media kernel: ata5.00: HPA detected: current 1953523055, native 1953525168

Jun  8 10:31:40 Media kernel: ata5.00: ATA-8: ST31000340AS, SD15, max UDMA/133

Jun  8 10:31:40 Media kernel: ata6.00: HPA detected: current 2930275055, native 2930277168

Jun  8 10:31:40 Media kernel: ata6.00: ATA-8: ST31500341AS, SD1B, max UDMA/133

Jun  8 10:31:40 Media emhttp: Device inventory:

Jun  8 10:31:40 Media emhttp: ST31000340AS_9QJ0PVWK (sda) 976762584

Jun  8 10:31:40 Media emhttp: ST31000333AS_9TE1KPE1 (sdc) 976762584

Jun  8 10:31:40 Media emhttp: ST31000340AS_9QJ0TBQ1 (sdd) 976761527

Jun  8 10:31:40 Media emhttp: ST31500341AS_9VS0B8ER (sde) 1465137527

Jun  8 10:31:40 Media emhttp: ST3500418AS_6VMG8Z7K (sdg) 488386584

Jun  8 10:31:40 Media emhttp: WDC_WD15EARS-00Z5B1_WD-WMAVU1362121 (sdf) 1465138584

Thanks for the reply. I was using 4.7 stable for quite a while before moving through to 5 Beta 5. Everything worked without issue until Beta 6+ came along.

I understand there is HPA on my drives. I've updated BIOS to stop this from happening by default. This is my home server, so I'm hesitant to remove HPA until I have another copy of my data.

I think I'm going to have to pre-clear and remove HPA from each single drive, and add to a fresh array. I'll be rebuilding my server soon, so this is probably my best option.