unRAID Server Release 6.0-rc4-x86_64 Available


Recommended Posts

i've waivered my POV regarding a centralised repo a few times though.

 

i'd be more in favour of a few from the community having super user rights to the various gits and if the need arises due to a developer absence, take it over.

 

Nice idea.

Link to comment
  • Replies 270
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

i'd be more in favour of a few from the community having super user rights to the various gits and if the need arises due to a developer absence, take it over.

And 2 years down the line there are dozens (if not more) of forks of the same application from users both past present uninitiated unskilled ignorant or devious.

While it may or may not reassure people, there currently is a user who has control over much of the unofficial docker system.  Myself.  I maintain the popular repositories thread, I maintain the lists that populate CA and CR.  If a developer did go off the deep end and started publishing malware, etc then rest assured that the repo would be removed promptly.

 

And the opposite would also be true.  If I ever went off the deep end (I am married, you know), and deliberately trashed thread or repo lists, I'm quite positive someone would fork my project, change a single line and everything would be back to normal.

 

I maintain a completely unbiased rule towards the repositories however.  If its published its added.  Period.  I don't care if the containers work properly or not (hence why I've encouraged the use of the <beta> flag and beta repositories).  If I ever heard about malware, that would be a different story however. 

 

I (and no one else around here including LT) is in a position to vet every application

 

 

Link to comment

i'd be more in favour of a few from the community having super user rights to the various gits and if the need arises due to a developer absence, take it over.

And 2 years down the line there are dozens (if not more) of forks of the same application from users both past present uninitiated unskilled ignorant or devious.

While it may or may not reassure people, there currently is a user who has control over much of the unofficial docker system.  Myself.  I maintain the popular repositories thread, I maintain the lists that populate CA and CR.  If a developer did go off the deep end and started publishing malware, etc then rest assured that the repo would be removed promptly.

 

And the opposite would also be true.  If I ever went off the deep end (I am married, you know), and deliberately trashed thread or repo lists, I'm quite positive someone would fork my project, change a single line and everything would be back to normal.

 

I maintain a completely unbiased rule towards the repositories however.  If its published its added.  Period.  I don't care if the containers work properly or not (hence why I've encouraged the use of the <beta> flag and beta repositories).  If I ever heard about malware, that would be a different story however. 

 

I (and no one else around here including LT) is in a position to vet every application

 

 

you could up and decide to go invade the USA or something, if one of your hockey teams loses.

Link to comment

i'd be more in favour of a few from the community having super user rights to the various gits and if the need arises due to a developer absence, take it over.

And 2 years down the line there are dozens (if not more) of forks of the same application from users both past present uninitiated unskilled ignorant or devious.

While it may or may not reassure people, there currently is a user who has control over much of the unofficial docker system.  Myself.  I maintain the popular repositories thread, I maintain the lists that populate CA and CR.  If a developer did go off the deep end and started publishing malware, etc then rest assured that the repo would be removed promptly.

 

And the opposite would also be true.  If I ever went off the deep end (I am married, you know), and deliberately trashed thread or repo lists, I'm quite positive someone would fork my project, change a single line and everything would be back to normal.

 

I maintain a completely unbiased rule towards the repositories however.  If its published its added.  Period.  I don't care if the containers work properly or not (hence why I've encouraged the use of the <beta> flag and beta repositories).  If I ever heard about malware, that would be a different story however. 

 

I (and no one else around here including LT) is in a position to vet every application

 

 

you could up and decide to go invade the USA or something, if one of your hockey teams loses.

Not likely to happen...  Our teams never lose
Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

I don't know the inner workings well enough to be able to give you a definitive answer, but I would think that if you had it set to "CACHE-ONLY" then no it shouldn't have spun up the drive.

 

If you have it set to use cache, then the system may have also created the share on one of your data drives.

 

Did the file in question get written directly to the cache drive?  (You can check from your windows box by going to your network, selecting your server and then looking at the contents of cache - if you exported the share)

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

I don't know the inner workings well enough to be able to give you a definitive answer, but I would think that if you had it set to "CACHE-ONLY" then no it shouldn't have spun up the drive.

 

If you have it set to use cache, then the system may have also created the share on one of your data drives.

 

Did the file in question get written directly to the cache drive?  (You can check from your windows box by going to your network, selecting your server and then looking at the contents of cache - if you exported the share)

 

Yes, the file being written is being save on the cache drive. That is why I do not understand why it would have called for parity to spin up. Is that not the point of cache drive?

Link to comment

To use Apple as an example. All thier community coded software has to be vetted and approved. Has that stifled development!?

 

The moment unRAID requires applications to have their approval before it can be installed or used is the exact moment unRAID sees itself forked and completely opensourced by some in the community.

 

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

I don't know the inner workings well enough to be able to give you a definitive answer, but I would think that if you had it set to "CACHE-ONLY" then no it shouldn't have spun up the drive.

 

If you have it set to use cache, then the system may have also created the share on one of your data drives.

 

Did the file in question get written directly to the cache drive?  (You can check from your windows box by going to your network, selecting your server and then looking at the contents of cache - if you exported the share)

 

 

Yes, the file being written is being save on the cache drive. That is why I do not understand why it would have called for parity to spin up. Is that not the point of cache drive?

 

I checked disk1 which the file will be placed on and the drive does not contain the file. So it looks like for whatever reason parity is just spinning up, not actually doing anything unless it is protecting the cache drive lol.

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

I don't know the inner workings well enough to be able to give you a definitive answer, but I would think that if you had it set to "CACHE-ONLY" then no it shouldn't have spun up the drive.

 

If you have it set to use cache, then the system may have also created the share on one of your data drives.

 

Did the file in question get written directly to the cache drive?  (You can check from your windows box by going to your network, selecting your server and then looking at the contents of cache - if you exported the share)

 

Yes, the file being written is being save on the cache drive. That is why I do not understand why it would have called for parity to spin up. Is that not the point of cache drive?

Something (windows?) could have modified a thumbnail or something stored on your data disk.  If this is the case, modifications to already existing files are written directly to the array.  (disk 1 should also be spun up)
Link to comment

To use Apple as an example. All thier community coded software has to be vetted and approved. Has that stifled development!?

 

The moment unRAID requires applications to have their approval before it can be installed or used is the exact moment unRAID sees itself forked and completely opensourced by some in the community.

 

 

Yep.

 

Maybe LT could offer a "tested and approved" repository for those who do not want to trust the community or make their own. Charge a small monthly fee to those who want to use it to cover the cost of checking each docker. I'm sure some wouldn't mind paying a little extra for peace of mind and time saved.

 

But no matter what, DO NOT take the choice away from me. One of the reasons I went with unraid is because it is a Linux base and you can do whatever the heck you want to it to make it suit your needs.

Link to comment

To use Apple as an example. All thier community coded software has to be vetted and approved. Has that stifled development!?

 

The moment unRAID requires applications to have their approval before it can be installed or used is the exact moment unRAID sees itself forked and completely opensourced by some in the community.

Talk (threats?) of forking may have been a factor in some of the new features in v6.
Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

I don't know the inner workings well enough to be able to give you a definitive answer, but I would think that if you had it set to "CACHE-ONLY" then no it shouldn't have spun up the drive.

 

If you have it set to use cache, then the system may have also created the share on one of your data drives.

 

Did the file in question get written directly to the cache drive?  (You can check from your windows box by going to your network, selecting your server and then looking at the contents of cache - if you exported the share)

 

Yes, the file being written is being save on the cache drive. That is why I do not understand why it would have called for parity to spin up. Is that not the point of cache drive?

Something (windows?) could have modified a thumbnail or something stored on your data disk.  If this is the case, modifications to already existing files are written directly to the array.  (disk 1 should also be spun up)

 

The file being written is a movie I am transcoding using Sparkyballs handbrake docker. I am in the process of slowly compressing all my makemkv rips for size reduction. I am also using Ubuntu on a laptop so no Windows environment accessing unRaid.

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

I don't know the inner workings well enough to be able to give you a definitive answer, but I would think that if you had it set to "CACHE-ONLY" then no it shouldn't have spun up the drive.

 

If you have it set to use cache, then the system may have also created the share on one of your data drives.

 

Did the file in question get written directly to the cache drive?  (You can check from your windows box by going to your network, selecting your server and then looking at the contents of cache - if you exported the share)

 

Yes, the file being written is being save on the cache drive. That is why I do not understand why it would have called for parity to spin up. Is that not the point of cache drive?

Something (windows?) could have modified a thumbnail or something stored on your data disk.  If this is the case, modifications to already existing files are written directly to the array.  (disk 1 should also be spun up)

 

The file being written is a movie I am transcoding using Sparkyballs handbrake docker. I am in the process of slowly compressing all my makemkv rips for size reduction. I am also using Ubuntu on a laptop so no Windows environment accessing unRaid.

I used windows as an example.  If disk 1 is also spun up then more than likely something somewhere modified a file currently stored.  Plex or another container could have done it
Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

Do you see the share in

ls -lah /mnt/user0

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

Do you see the share in

ls -lah /mnt/user0

 

Yes, all of my shares show in that directory minus my vm cache only share.

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

Do you see the share in

ls -lah /mnt/user0

 

Yes, all of my shares show in that directory minus my vm cache only share.

If you are seeing a share in /mnt/user0 then it exists on drives other than cache.
Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

Depends.  There are several reasons a new file being created on a cache-yes share would in fact get created on an array disk, which would cause parity to be accessed as well.

Link to comment

I have a share set to use cache yes. When I add files to the share the dashboard and main page indicate the parity drive is spun up? Is this a bug? Diagnostics file is attached while writing is in progress to the share.

Do you see the share in

ls -lah /mnt/user0

 

Yes, all of my shares show in that directory minus my vm cache only share.

If you are seeing a share in /mnt/user0 then it exists on drives other than cache.

 

Thanks, Squid and Trurl for taking a look. As Limetech stated this must be a known feature of unRaid and not RC4 specific. Just something I noticed when writing to a share set with cache yes and parity spins up. No big deal.

Link to comment

I checked disk1 which the file will be placed on and the drive does not contain the file. So it looks like for whatever reason parity is just spinning up, not actually doing anything unless it is protecting the cache drive lol.

Because of the way that mover works, if a file is going to be written to the cache disk then unRAID ensures that the same folder structure corresponding to that file exists on the data disks in the user share.    You could therefore get a data disk and the parity disk spun up because a new folder was being created that will eventually hold the file when it is moved off the cache disk.
Link to comment

Because of the way that mover works, if a file is going to be written to the cache disk then unRAID ensures that the same folder structure corresponding to that file exists on the data disks in the user share.    You could therefore get a data disk and the parity disk spun up because a new folder was being created that will eventually hold the file when it is moved off the cache disk.

 

The folder structure is set up by the 'rsync' command invoked by mover at time mover runs, not when file is created on cache.

Link to comment

Upgrading from 5.0.6 to 6.0-rc4.

 

Many small issues...

 

First, "failed to load COM32 file menu.c32 when I first attempted to boot my flash drive.

To get it to boot I had to copy menu.c32 from the syslinux folder on the flash drive to the root of the flash drive.

 

Then, once that was resolved, it booted and allowed me to see the disk assignment page by invoking //tower

 

after assigning each of the data drives, I get:

URL: tower/undefined

404 File Not Found

 

hitting the back button and then refreshing the browser, I see the assigned disk, but at the bottom of the main disk assignment page is:

Fatal error: Call-time pass-by-reference has been removed in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(278) : eval()'d code on line 56

 

After assigning all the disks as they were previously, I'm stuck...

I cannot start the array now that I've assigned my drives because of this error, as there are no buttons present to start the array.

 

Help is requested.  This is my first attempt to boot on 6.X and I'm not impressed so far with the experience.  I can click around on the various tabs in the interface and can get to all the pages...  Apparently, it is just the main disk assignment page with the error so far.

 

It appears to me as if going straight from 5.0.6 to 6-rc4 is going to be an issue for some. 

 

(I should add I did not completely re-format the flash drive..  I did disable all the packages/add-ons, etc in the config/go script, re-named the packages folder to packages_v5, etc.    There was a older menu.c32 in the root directory of the flash drive... perhaps it was confusing syslinux.  I did run the make_bootable.bat script from within Windows Vista using "run as administrator" on it before my first attempt to boot 6-rc4.)

 

Joe L.

Link to comment
Guest
This topic is now closed to further replies.