unRAID 5.0b6a - "Stable" Beta

[SSD]

The 5.0b6a release is now 1 month old.  It was the culmination of a full sprint of 7 betas in 5 days in early February!  That may be a record.

 

After a month of use on test arrays and some brave souls that have updated production arrays, the moderators have agreed (with no dissent) that the 6a beta should no longer be classified as dangerous.  I am therefore promoting it to “stable beta” (whatever that means ).

 

As a result, you will notice that the news banner has been updated to reference this post, and the warnings removed.  This does not mean that 5.0b6a is perfect or ready to be a release, but it does mean that the danger of data loss is low and that those interested in the new features afforded in this version (mainly AFP, enhanced device support, auto slot assignment (I love this feature), and a new GUI look and feel) can move cautiously to the beta.

 

The most serious problem with 5.0b6a remains a routine inside unRAID that will re-write the MBR for disks that appear foreign.  It occasionally thinks an unRAID disk is a foreign disk.  This was detected in 5.0b6, and 5.0b6a was introduced almost immediately with diagnostic code to help protect users and uncover the reason.  The diagnostic code does two things –

 

1 – It includes an option to NOT start the array automatically (it does not start the array by default).  As a result, any possible MBR overwriting will not occur simply by booting the 6a version.

 

2 – It tells you if the MBR looks foreign by displaying an “MBR – unknown” indicator.  This is your clue to NOT start the array with 5.0b6a!  If you boot 6a and see this, follow the instructions HERE.  If you don’t see this warning, you can start the array and not have your MBR overwritten.  (But remember this is a beta and you need to know what to do should it happen).

 

There are experienced Linux members that have created multi-partitioned cache drives or have used boot managers (LILO) in the past, that have funny looking MBRs that unRAID will overwrite.  If you have such a cache drive, know going in that you will need to allow unRAID to lay down a standard MBR in order to use 6a.  But, if you know enough to do these fancy things with your cache disk, you likely know enough to mount your existing cache drive outside the array, and avoid the unRAID processing.

 

If you are a new user or fear loading the beta, by all means DO NOT DO IT.  But if you are considering it, remember, that stable releases are only stable releases because the community has, historically, been willing to install betas and test them.  Only with use on a diverse set of arrays of community members can the defects be identified, fixed, and stable releases be produced.  (Said another way, if the community does not participate in the beta program, release versions will be buggy)

 

To participate, I suggest reading the 6a announcement thread HERE.  It will familiarize you with the issues in 6a, so if you see them they will not be a surprise.  Pay particular attention to the mkmbr, a tool to rebuild your MBR should 5.0b6a overwrite it (which is extremely unlikely if you follow the instructions).  If you don’t have enough time to read the announcement thread, I would not suggest loading the beta.

 

I personally have been using 6a from the beginning on a new build.  I migrated some disks from my prior build, added a bunch of new disks, ran parity builds, parity checks, enhanced myMain to be compatible, installed numerous addons, and generally feel  I’ve given it a workout.  I saw no trace of the MBR problem.  You’ll see a few minor issues I’ve found in the announcement thread, but I am very happy using it with no plans to go back to 4.7.

 

Joe L. suggests following these instructions prior to upgrading to 6a:

 

Perhaps the very first step of the upgrade to 5.0b6a should be to run the following command on the PRIOR release, before upgrading, and save the contents for later use if requested.  

(if you use the following command, the output is saved on the flash drive in the top most directory in a file disk_mbr_debug.txt)

 

for d in /dev/[sh]d?; do echo -e "\n$d " $(cat /sys/block/$(basename $d)/size); dd status=noxfer count=1 if=$d | od -Ad -t x1; done | tee /boot/disk_mbr_debug.txt

 

[squirrellydw]

So do we have any idea yet when 5 might be officially released?

[prostuff1]

So do we have any idea yet when 5 might be officially released?

 

No, there are still a lot of things on the road map that LimeTech would like to get into final 5.0.

[christuf]

Is there any kind of list anywhere of which packages (installed from unMENU) are compatable with 5.0-beta6a?

 

I am very keen to upgrade from 4.7 (to get AFP support), but have a bunch of packages installed which I'm worried about losing .  The install guide says to disable them before the upgrade...

 

Thank you!

[Joe L.]

Is there any kind of list anywhere of which packages (installed from unMENU) are compatable with 5.0-beta6a?

 

I am very keen to upgrade from 4.7 (to get AFP support), but have a bunch of packages installed which I'm worried about losing .  The install guide says to disable them before the upgrade...

 

Thank you!

I really have not heard of many that are not compatible.  What add-ons are you specifically interested in, as I do not run them all here on my newer 5.0beta6a server, but I could try them if I have the right hardware. (I don't have an iPhone, so I cannot try Airvideo, but as far as I know it works too)

 

I think the message to disable all the add-ons is to not complicate the debugging if there are any issues. 

 

Joe L.

[djdexter]

Is the download for 5.0ba still the same and in Announcements or is there a updated one?

[Joe L.]

Is the download for 5.0ba still the same and in Announcements or is there a updated one?

it is still 5.0beta6a.

[Dase]

Is there any kind of list anywhere of which packages (installed from unMENU) are compatable with 5.0-beta6a?

 

I had to stop unmenu from installing the PHP package for my 5.0 upgrade. The unraid web UI was all garbled with it active.

[BRiT]

Executing the following command after installing your own php package will likely fix the emhttp issue:

 

sed -i -e "s/^short_open_tag.*=.*Off/short_open_tag = On/" /etc/httpd/php.ini

 

obviously replacing /etc/httpd/php.ini with the location of your new php.ini file, which can be determined with the following command:

 

php --ini

 

[madburg]

Executing the following command after installing your own php package will likely fix the emhttp issue:

 

sed -i -e "s/^short_open_tag.*=.*Off/short_open_tag = On/" /etc/httpd/php.ini

 

obviously replacing /etc/httpd/php.ini with the location of your new php.ini file, which can be determined with the following command:

 

php --ini

 

 

I could use some help with this as well please. Is this happening to everyone on unRAID 5.0b6a?

 

php --ini output:

Configuration File (php.ini) Path: /etc/httpd

Loaded Configuration File:        /boot/custom/php/php.ini

Scan for additional .ini files in: /etc/php

Additional .ini files parsed:      (none)

 

Should i execute this very command "sed -i -e "s/^short_open_tag.*=.*Off/short_open_tag = On/" /etc/httpd/php.ini" ? I dont want to mess this up if I miss understood something.

[BRiT]

It looks like the php file it's using is from '/boot/custom/php/php.ini', so your command would be:

 

sed -i -e "s/^short_open_tag.*=.*Off/short_open_tag = On/"  /boot/custom/php/php.ini

 

What this does is look for a line beginning with "short_open_tag = Off" with no or any amount of whitespace between the 3 terms and replace it with "short_open_tag = On". The command can be run multiple times without any ill effects. If it does not find any matching lines it won't change anything.

 

You may have to restart any php-based processes for the changes to take effect for those processes.

 

[madburg]

It looks like the php file it's using is from '/boot/custom/php/php.ini', so your command would be:

 

sed -i -e "s/^short_open_tag.*=.*Off/short_open_tag = On/"  /boot/custom/php/php.ini

 

What this does is look for a line beginning with "short_open_tag = Off" with no or any amount of whitespace between the 3 terms and replace it with "short_open_tag = On". The command can be run multiple times without any ill effects. If it does not find any matching lines it won't change anything.

 

You may have to restart any php-based processes for the changes to take effect for those processes.

 

 

Many thanks!, so is mine normal for a lack of better words? to be looking at  '/boot/custom/php/php.ini'. I know I did not do a single thing, so assuming everyone on 5.06a with unraid/web menu is facing this?

[madburg]

It did not work for me or as far as I can see. What I did actually notice is just by going to \\tower (port80) is generates these PHP messages at the conole and does not let you type anything at the console until u actually hit Enter then you get the login propmt again. Screensnot attached.

[BRiT]

After making the change, did you restart emhttp to be able to see the webbrowser-based UI?

[madburg]

I rebooted after the change, is that ok?

 

Also i dont know if it is related, but in \\tower:89 "unMENU" "unRAID Web" when u select "User Scripts", Disk Performance" or "Network Performance", nothing comes up?

[PeterB]

\\tower:89 "unMENU"

 

What's this?  I don't understand what you mean?  unMENU is normally on tower:8080

[dgaschk]

89 is for unRAID Web

[madburg]

Yes sorry guys I am confused with those names and the fact that the web one 89 sits and executes what unmenu has... My question still holds with the port numbers being correct and what is not working. But as u can see the errors are generated when just browsing to the original unRaid product home page on port 80. So either there is a bug, or by adding unmenu/unraid web to 5.0b6a we start getting php warning / errors.

 

Did you guys even check if you are experiencing what we are seeing in the unRAID console, or am I just being picked on, becuase of my confusion with unMENU / unRAID Web. What is the default unRAID port 80 Web Management referred to then, for future reference so i dont confuse others.

[prostuff1]

Yes sorry guys I am confused with those names and the fact that the web one 89 sits and executes what unmenu has... My question still holds with the port numbers being correct and what is not working. But as u can see the errors are generated when just browsing to the original unRaid product home page on port 80. So either there is a bug, or by adding unmenu/unraid web to 5.0b6a we start getting php warning / errors.

 

Did you guys even check if you are experiencing what we are seeing in the unRAID console, or am I just being picked on, becuase of my confusion with unMENU / unRAID Web. What is the default unRAID port 80 Web Management referred to then, for future reference so i dont confuse others.

 

the unRAID webGUI is on port 80 by default

unMenu is on port 8080 by default

and unRAID Web is on port 89 be default.

 

I don't think you are being picked on... but you have to understand that most of us probably do not run the unRAID web addon.  I know I don't... and while installing it is fairly straight forward it does take some time.

 

Also, after you rebooted did you check the php file again to see if the short_open_tag setting was correct?

[madburg]

Thanks ProStuff1 for the clarification, I will use does names going forward.

 

How would I go about checking the php file for short_open_tag setting, so sorry new to linux and unRAID (I am a wintel guy, but enjoying learning linux as well.) But once I ramp up I will contribute  

 

I was hoping to see if everyone who looked at their console saw the same, many may not be looking at the console thus not even know. I am now thinking maybe its a unRAID Web addition, as I see it added PHP. So I will test on a different box with just unRAID 5.06a no plugins and where its reading the PHP.ini from. This should narrow it down. But if someone figured this out already please chime in. Is BubbaQ the overall owner of unRAID Web.

 

You also meantioned "most of us probably do not run the unRAID web addon" can you share why that is?

 

[prostuff1]

Thanks ProStuff1 for the clarification, I will use does names going forward.

 

How would I go about checking the php file for short_open_tag setting, so sorry new to linux and unRAID (I am a wintel guy, but enjoying learning linux as well.) But once I ramp up I will contribute  

Well, it is located at "/boot/custom/php/php.ini" which is on the flash drive.  There should be a folder on the flash drive called "custom" that should have the "php" folder and then the php.ini file. 

 

I was hoping to see if everyone who looked at their console saw the same, many may not be looking at the console thus not even know. I am now thinking maybe its a unRAID Web addition, as I see it added PHP. So I will test on a different box with just unRAID 5.06a no plugins and where its reading the PHP.ini from. This should narrow it down. But if someone figured this out already please chime in. Is BubbaQ the overall owner of unRAID Web.

unRAID web does add php and the php.ini file does not turn on short-tags, which the unRAID WebGUI uses, hence the conflict.  BubbaQ is the creator of the unRAID Web addon, though he has stated he will not be updating it until 5.0 is out of beta.  It is just to much of a moving target right now to want to develop towards (it is the main reason I have not tried to work with the "plugins" stuff that is available).

 

You also meantioned "most of us probably do not run the unRAID web addon" can you share why that is?

It has nothing in it at this time that I really need.  unMenu by itself works perfectly fine, and the unRAID WebGUI works for my needs also.  unRAID Web, while it is very cool and something I might want/use down the road, is not something I want to install on my production system right now.

[madburg]

Thank you very much ProStuff1, for taking the time out and explaining this all to me. I have a much clearer picture now. All the best.

[Kryspy]

Setting up a fresh 5.0 beta 6a with plec-cleared disks.  I assume if starting from scratch I do not need to be concernesd with the "permissions" utility?

 

Kryspy

[dgaschk]

You do not. It's only for upgrades.

[Joe L.]

You do not. It's only for upgrades.

Almost true... 

 

It is ALSO needed if you log in as "root" and move or copy any files between disks using native command line commands or "mc"

That is because they would end up owned by "root" and not visible to the LAN which is logging in as "nobody"

 

Joe L.