unRAID Server Release 5.0-beta6 Available

[johnodon]

Upgraded...assigned drives...parity sync running.

 

[SSD]

Is it a parity build or a parity check that is occurring?  I would think if you delete super.dat, it would rebuild parity.

 

If so, it might be a good idea to run a parity check before moving from and earlier 5.0 beta to beta 6, as the ability to recover from a failure will be lost until the parity build completes.

[johnodon]

Oooops...meant to say Parity Sync (as seen in the pic)...

[ehfortin]

Hi,

 

I also got the problem that Brit reported where disks are showing as unformatted. I can see in the log that a new MBR was written by Unraid at some point (11h14m48s). Is that related to the fact that I did use the "Identify disk"? The disks that shows with the new MBR are the one not recognized anymore.

 

I'm including my syslog.

 

I've not tried the script discussed by Joe (if I remember well) and Brit.

 

Should I proceed with the script? I'm not changing anything until I hear from somebody.

 

--EDIT--

I just tried the script on one of the drive that was not working. Based on the info from the script, the new MBR was on 64 where the old one was on 63 (sorry, I don't remember the unit but I think it was "sector"). I've let it recreate the MBR on 63 as before. My drive was /dev/sdk and I had a partition /dev/sdk1. Now, I don't have /dev/sdk1 anymore and I'm still unable to do anything with /dev/sdk. I wanted to try the reiserfschk --rebuild-sb but it is asking some question. I guessed the block size to be the default at 4096 bytes. I assume the journal was there by default. Then, it said the MBR was probably modified by something else (which is the case) and was telling that if I was sure the partition was fine to rebuild the journal header. The default here is "no". If I select "no", it just stop there and do nothing. I've not tried "yes" as I want to make sure I don't loose any files that are there. Is rebuilding the journal header will recreate the /dev/sdk1?? If not, how do I fix this?

 

--EDIT 2 --

Well, I figured I could copy the first 512 bytes from another disk (dd bs=512 count=1 if=/dev/sd[source] of=/dev/sd[target]. This got me back my /dev/sdk1. So now, I can see the drives in Unraid as before. But they are still seen as unformatted in Unraid. Seems like I can't use the script in it's current form. I notice that Brit said he changed a few lines. Maybe that's what I need as well but I will wait for input from those that know instead of trying and risking a restore of a drive (which is a pain).

 

Thank you.

 

ehfortin

syslog.zip

[lionelhutz]

I'm still unable to do anything with /dev/sdk.

 

You run the reiserfsck commands on the partition /dev/sdk1, not /dev/sdk.

 

Sounds like you now have a partition but not a file system so run reiserfsck on the partition.

 

Peter

 

[pras1011]

Damn! I was hoping to upgrade from 4.7 to this. Better not!

[ehfortin]

Hi,

 

I'm still unable to do anything with /dev/sdk.

 

You run the reiserfsck commands on the partition /dev/sdk1, not /dev/sdk.

 

Sounds like you now have a partition but not a file system so run reiserfsck on the partition.

 

Peter

 

 

I just tried this. I have the same result. Should I accept to rebuild the journal header?

 

In the order, the reiserfschk --rebuild-sb is asking for:

 

reiserfs version: I assume 3.6 which is the most recent in the list.

Block size: Default is 4096

Presence of journal: Default is yes

Rebuild of journal header: Default is no

 

Process stop there if I says no. That being said, after I accepted the first 3 questions, it told me there was no GUID (or something like this) and generated a new one.

 

Hum... Just tried something interesting. As I have a few disks that don't have any issue, I've copied the MBR from those to my /dev/sdk. It works. I now get it back as recognized under Unraid. I guess I can do the same for all the disks that were originally modified for an unknown reason (I'll keep a copy of the modified MBR if somebody want to have a look at it).

 

Will let you know. Thanks.

 

-- EDIT --

 

Did use a working MBR on all disks. They are now all recognized by Unraid except for the cache drive. Is it also based on reiserfs? I've not checked this before.

 

Thanks.

 

ehfortin

[dbknightx]

I'm continuing (since 5.0 beta 4) to have an issue where two of my drives are showing up missing.  I didn't try pre-beta 4 so I don't know if it is a new problem.

 

It is not cabling related as everything works fine if I revert to 4.7.

 

Any ideas what may be going on?  Screenshot and syslog attached.

 

 

-David

syslog.txt.zip

[Stokkes]

I'm continuing (since 5.0 beta 4) to have an issue where two of my drives are showing up missing.  I didn't try pre-beta 4 so I don't know if it is a new problem.

 

It is not cabling related as everything works fine if I revert to 4.7.

 

Any ideas what may be going on?  Screenshot and syslog attached.

 

 

-David

 

Are you still having this issue on beta6?

 

Did you:

 

1) Make note of where your drives are assigned

2) delete config/super.dat

3) copy bzroot/bzimage to your flash

4) shutdown and reboot your server

5) When it comes back up, re-assign your drives

6) Run the parity sync

7) stop array/reboot after the parity sync is complete..

 

If you follow these steps, do the drives still show up as missing after #7?

 

[limetech]

I'm continuing (since 5.0 beta 4) to have an issue where two of my drives are showing up missing.  I didn't try pre-beta 4 so I don't know if it is a new problem.

 

It is not cabling related as everything works fine if I revert to 4.7.

 

Any ideas what may be going on?  Screenshot and syslog attached.

 

 

-David

 

The syslog shows numerous errors being reported on those two disks.  What controller are they attached to?

[dbknightx]

The syslog shows numerous errors being reported on those two disks.  What controller are they attached to?

They are both connected to motherboard (ASUS M4A785-M) sata ports.  You're right, there are a ton of errors in the logs.  However, the system does start up and mount those drives successfully under 4.7.  Every beta of 5.0 I've tried has failed similarly to this one.

 

Anything else I can try?  BTW I've never seen any errors reported in the 4.x web UI, but I admit I've not scanned through the syslog too closely in the past.  These two drives were brand new ones I purchased at the time I set up my UNRAID server around 3 months ago.

 

-David

[limetech]

The syslog shows numerous errors being reported on those two disks.  What controller are they attached to?

They are both connected to motherboard (ASUS M4A785-M) sata ports.  You're right, there are a ton of errors in the logs.  However, the system does start up and mount those drives successfully under 4.7.  Every beta of 5.0 I've tried has failed similarly to this one.

 

Anything else I can try?  BTW I've never seen any errors reported in the 4.x web UI, but I admit I've not scanned through the syslog too closely in the past.  These two drives were brand new ones I purchased at the time I set up my UNRAID server around 3 months ago.

 

-David

 

You should try booting 4.7 again and see if there are errors being reported in the system log.  Those errors are happening in device discovery before any unRaid component is started.

[Zeron]

Upgraded to 5.0b5b and successfully upgraded my 80Gb disk to a 160Gb.  Then Created a new Share called Anime, but did not write to it.

 

Now I have upgraded to 5.0b6 and wrote to the share.  Two things happened:

  1. Got out of disk space error while writing.

  2. Get an access denied error when I try to open any folder in the Share.

 

Before writing, Disk 1 have 100Gb free, Disk 2 had 33Gb free.

 

The Share was configured as:

    Alloc Method: High-water

    Min Free Space: 0

    Split level: 2

    Export: Yes

    Security: Public

 

I mounted the share from a Linux server (mnt //192.168.99.99/Anime /mnt/temp) and started copying 120Gb of Anime files too it.

 

The Files are in this structure:

<Series Name>/Season <x>/Episode.mkv

 

After 100Gb copes, disk full error.  Try to continue copying, same disk full error.

 

From my Windows 7 PC, I tried to Browse the Anime share, and it gives an error:

"You do not have permission to access \\MEDIASERVBER1\Anime\Cowboy Bebop"

 

Trying from the disk1 share give the same error:

"You do not have permission to access \\MEDIASERVBER1\disk1\Anime\Cowboy Bebop"

 

ls -la /mnt/disk1/Anime

drwxrwx---  3 root  root  264 2009-04-23 04:15 Cowboy\ Bebop/

...

 

Syslog:

http://pastebin.com/u1geW0ke

[dbknightx]

The syslog shows numerous errors being reported on those two disks.  What controller are they attached to?

They are both connected to motherboard (ASUS M4A785-M) sata ports.  You're right, there are a ton of errors in the logs.  However, the system does start up and mount those drives successfully under 4.7.  Every beta of 5.0 I've tried has failed similarly to this one.

 

Anything else I can try?  BTW I've never seen any errors reported in the 4.x web UI, but I admit I've not scanned through the syslog too closely in the past.  These two drives were brand new ones I purchased at the time I set up my UNRAID server around 3 months ago.

 

You should try booting 4.7 again and see if there are errors being reported in the system log.  Those errors are happening in device discovery before any unRaid component is started.

 

Looks like I have errors on two drives in 4.7 as well (they are numbered differently - ata9 and ata10 instead of ata2 and ata3).  I'm sure they are the same ones, however.  The drives do show up just fine in my array and if I didn't look in the syslog, I'd never know there were any issues.

 

Not to take this thread off track any further, are there recommended posts / threads / wikis on how to go about fixing these two drives?

 

-David

syslog-dbknightx-4.7.txt.zip

[nia]

Its really good to see how issues are addressed immediately.  Looking forward to 5 getting stable enough to dare attemting insalling it on a production server.

 

Hmm, red or orange? Don't know - should I be concerned? Here is a screenshot:

Based on the screenshot - this seems like good input for a usability improvement in color optimisation  (i.e. clearly discernible colors) when the more functional stuff has been ironed out

[BRiT]

Before writing, Disk 1 have 100Gb free, Disk 2 had 33Gb free.

 

The Share was configured as:

   Alloc Method: High-water

   Min Free Space: 0

   Split level: 2

   Export: Yes

   Security: Public

 

After 100Gb copies, disk full error.  Try to continue copying, same disk full error.

 

That is expected behavior because of the way you have it configured.

 

You need to set the Min Free Space to something reasonable. The typical setting should be larger than the typical size of files you'll be writing to it.

 

Unfortunately the way most if not all file copies are done is the file is created as 0 bytes and then has bytes appended to it. Since your drive can easily store a 0 byte file, the user share never detects the drive can not store the file and thus never moves on to using your second drive in the share.

[PeterB]

I have taken the plunge and upgraded my server from b4 to b6 (yes, I know ... I like living dangerously!).

 

The Parity-sync is now 97% complete - well past the 50% mark where any data drives are involved.  Do I detect the parity drive status changing from red to orange once the parity calculation has passed the end of the largest data drive - or is that just a problem in discerning the difference between the orange and red dots?

 

The upgrade process went exactly as detailed in the release notes - no untoward happenings. Everything appears to be running well - there seems to be some improvement in write speeds (to cache disk) with 5.0, compared to 4.x.

 

One small question - what has become of /proc/acpi/sleep - it seems to have vanished in 5?

 

Thank you, Tom, for all the hard work (and heartaches?) in developing unRAID, and many thanks to all the Hero members who provide such excellent support and advice.

[johnodon]

Quick question...

 

Now that I have successfully upgraded to v5b6, I have decided that I have a drive in my array that I really don't want.  I don't want to replace it...I just want to remove it completely.  The drive in question does not have any data on it.

 

Will this strategy accomplish my goal:  stop the array, delete \config\super.dat, power down, remove the drive, reassign all disks and let it rebuild parity.

 

TIA for the help!

 

John

[limetech]

One small question - what has become of /proc/acpi/sleep - it seems to have vanished in 5?

 

See here:

http://acpi.sourceforge.net/documentation/sleep.html

 

[Joe L.]

Quick question...

 

Now that I have successfully upgraded to v5b6, I have decided that I have a drive in my array that I really don't want.  I don't want to replace it...I just want to remove it completely.  The drive in question does not have any data on it.

 

Will this strategy accomplish my goal:  stop the array, delete \config\super.dat, power down, remove the drive, reassign all disks and let it rebuild parity.

 

TIA for the help!

 

John

That will do it.  you can do the equivalent by

Stop the array

un-assign the disk you wish to remove

power down , remove it

power up

with the array stopped, go to the "Utils" tab, click on "New Config"

On that screen, check the "I'm sure" box and click on the button  (Basically, unRAID then removes the super.dat file for you, but re-creates it with the remaining assigned drives so you do not have to re-assign all of them)

 

Then, start the array.  Parity will be calculated on the new disk configuration.

[johnodon]

with the array stopped, go to the "Utils" tab, click on "New Config"

 

Thx Joe.

 

I wasn't sure if the New Config tool would delete all of my shares and other settings so I have stayed away from it! 

 

Thx again!

 

John

[Joe L.]

with the array stopped, go to the "Utils" tab, click on "New Config"

 

Thx Joe.

 

I wasn't sure if the New Config tool would delete all of my shares and other settings so I have stayed away from it! 

 

Thx again!

 

John

I think everything stays the same.  The "New Config" basically just re-names super.dat to super.old. (Or at least that is what is does in earlier releases)

[limetech]

Quick question...

 

Now that I have successfully upgraded to v5b6, I have decided that I have a drive in my array that I really don't want.  I don't want to replace it...I just want to remove it completely.  The drive in question does not have any data on it.

 

Will this strategy accomplish my goal:  stop the array, delete \config\super.dat, power down, remove the drive, reassign all disks and let it rebuild parity.

 

TIA for the help!

 

John

 

Yes.  But I think I'm going to add ability to 'Start' array with missing disk(s) and invalidate parity (so that a parity sync will start).  This will let you remove disk(s) without having to re-assign everything again.

[limetech]

You can repair the MBR with a utility I wrote a while back.  It will create a correctly defined MBR for  a partition starting on sector 63.    The utility is attached here http://lime-technology.com/forum/index.php?topic=5072.msg47122#msg47122

 

There is an error in that post where it says, "Never invoke it on your parity disk... the parity disk does not have a partition table since it has no file system."  This is not correct - parity disk has same MBR and partition structure as all the other disks.

 

I will release 5.0-beta6a soon which outputs a bit more information on the Disk Status page that indicates the MBR format of each disk.  I can not reproduce the problem where some disks appear unformatted after updating to -beta6, so this will help us figure out what's happening.  In addition, I will include a command line utility called 'mkmbr' that I use to write MBR's.  This can be used to repair and/or experiment with different MBR's.  Instructions will be provided with the release.

[Joe L.]

You can repair the MBR with a utility I wrote a while back.  It will create a correctly defined MBR for  a partition starting on sector 63.    The utility is attached here http://lime-technology.com/forum/index.php?topic=5072.msg47122#msg47122

 

There is an error in that post where it says, "Never invoke it on your parity disk... the parity disk does not have a partition table since it has no file system."  This is not correct - parity disk has same MBR and partition structure as all the other disks.

 

I will release 5.0-beta6a soon which outputs a bit more information on the Disk Status page that indicates the MBR format of each disk.  I can not reproduce the problem where some disks appear unformatted after updating to -beta6, so this will help us figure out what's happening.  In addition, I will include a command line utility called 'mkmbr' that I use to write MBR's.  This can be used to repair and/or experiment with different MBR's.  Instructions will be provided with the release.

I can fix that line in that post.  At the time I did not know it had an MBR too.

 

I'm also going to upload the updated/fixed version of that utility.  It has an "-A" option to allow you to force a partition start on sector 64.  It also fixes the need for leading zeros on the shell values.

 

Joe L.