unRAID Server Release 6.0-beta4-x86_64 Available

[eroz]

just installed B4 today, any reason the plg files dont auto start in the directory /boot/config/plugins/

are they 64 bit plg's?

[pyrater]

snap-x86_64.plg

[PeterB]

just installed B4 today, any reason the plg files dont auto start in the directory /boot/config/plugins/

 

Assuming that the answer to Eroz's question is 'yes', then it may be that you're suffering with the problem of .plg files loading before the network is up.  Try installing your plugins with the installplg command - after that they should auto-start at boot time.

[pyrater]

just installed B4 today, any reason the plg files dont auto start in the directory /boot/config/plugins/

 

Assuming that the answer to Eroz's question is 'yes', then it may be that you're suffering with the problem of .plg files loading before the network is up.  Try installing your plugins with the installplg command - after that they should auto-start at boot time.

 

I do each time which worked for VFS_recycle but snap does not want to auto load...

[trurl]

snap-x86_64.plg

See here

[Auggie]

I came across a horrible defect when I installed a drive (3TB) larger than the parity drive (2TB) for the sole purpose of manually copying it's entire contents (1.5TB) onto an empty drive (2TB) within the array.  I had just completed this process for two other 2TB HFS+ drives successfully, which were now incorporated into the array.

 

I initiated all the commands via the console and unRAID kept aborting with numerous I/O errors.  At first I thought it may have been due to non-printing characters in the file names because the error output always had a solid square character appended to all the file names listed with I/O errors (e.g. "This File NameBLOCKCHARACTERHERE").  I renamed all the files listed but the errors persisted.  There were also OS X specific "invisible" files listed, so I cleaned those off the drive to no avail, even though I had no problems copying those types of files with the previous 2TB drive copies.  I tried copying individual folders but kept getting errors, but all of a sudden the target drive in the array started showing I/O errors, and then the parity drive too.  I was getting really alarmed at this point.

 

I started a brand new config without the suspect target drive, rebuilt parity, expanded the array to include the suspect target drive, cleared and formatted it, then ran a parity check.  Everything completely with zero errors.  Cautiously, I started the manual copy but started getting errors on the parity drive again.

 

I changed different ports, HBA cards (all out of another unRAID box with 3/4TB drives attached to them), and breakout SAS-SATA cables but the parity errors persisted.  I again rebuilt parity and parity check and they completed successfully.

 

I then performed directory and disk checks on the 3TB source drive but those came up clean.  I then ran a SMART check and saw that there were numerous "pending bad blocks" on what previously was scanned as a healthy drive with no bad blocks.  So I believed the source drive was going bad.

 

I had another 3TB drive that I wanted data copied over so I decided to work on that instead.  Before installing it, I did a directory, disk, and SMART check and it came out clean (no bad blocks whatsoever), but installed in the unRAID box and attempts to initiate the copy again came up with I/O errors on the parity drive.  I then began to suspect it had something to do with the fact that it was a larger drive than the parity.  I also rechecked the source 3TB drive integrity and to my dismay saw that it now had several new "bad sectors pending".

 

To verify my suspicions, I copied all the contents (1.5TB) of the first 3TB drive onto a 2TB drive (not a single hiccup in the OS X box) and put that in the unRAID box: I was able to copy all contents to the array with zero errors.

 

After almost a week of this process, my conclusions are that unRAID somehow attempts to do some sort of parity syncing with any drive from which files are being transferred from, even though that drive is not incorporated into the array itself, and if that drive is larger than the parity drive, it errors out and may mark the parity drive, target drive, and/or source drive as problematic, and perhaps lead to the drive incorrectly relating the I/O errors to bad sectors on the drive and reassigning them to spare blocks.

 

This Atom system was previously my Media Server that had a mix of 2, 3, and 4TB drives so all of its components had worked flawlessly before as I only moved the hard drives to the new server.

 

In the past, I've performed many manual file transfers via the console successfully under version 5, but the source drives were never larger than the parity drive; this is the first time I attempted file transfers with a larger data drive so I'm not sure if this bug has been existence prior to version 6.  But the end result is that I have two 3TB drives that are now showing up on SMART utilities as potentially failing due to having reassigned or pending bad blacks that I suspect was incorrectly marked, directly or indirectly, due to this bug.

[BRiT]

After almost a week of this process, my conclusions are that unRAID somehow attempts to do some sort of parity syncing with any drive from which files are being transferred from, even though that drive is not incorporated into the array itself, and if that drive is larger than the parity drive, it errors out and may mark the parity drive, target drive, and/or source drive as problematic, and perhaps lead to the drive incorrectly relating the I/O errors to bad sectors on the drive and reassigning them to spare blocks.

 

That is not possible, and can be verified by looking at the unRAID MD driver code.

 

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports. Also, posting solid information such as system logs and full system specifications is the first step in helping others to help you.

[Auggie]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

[eroz]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

 

There you go.....You can not have a data drive that is larger than the parity drive.

[Auggie]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

 

There you go.....You can not have a data drive that is larger than the parity drive.

 

I concur, though someone else does not.

 

Well to clarify, I concur that you cannot perform file transfer operations to the array if the source drive is larger than the parity drive and the source drive is NOT part of the array (so technically, not a "data" drive within the array).  Just want to be clear on the terminology used.

[BRiT]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

 

There you go.....You can not have a data drive that is larger than the parity drive.

 

NO. He did not move the larger drive INTO the array. He merely has it available as a non-array drive.

 

Once again Auggie. In order for others to hellp you, you need to post full system specs and a system log.

[eroz]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

 

There you go.....You can not have a data drive that is larger than the parity drive.

 

NO. He did not move the larger drive INTO the array. He merely has it available as a non-array drive.

 

Once again Auggie. In order for others to hellp you, you need to post full system specs and a system log.

 

Are you sure he attached it as a non-array drive?  No where does he say he did that.  He does say he has another unraid tower.  He could have just attached a drive from his other tower, at least that is what I am understanding.  But what do I know.  He really isn't clear on what exactly he did and how he did it.

[dgaschk]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

 

There you go.....You can not have a data drive that is larger than the parity drive.

 

NO. He did not move the larger drive INTO the array. He merely has it available as a non-array drive.

 

Once again Auggie. In order for others to hellp you, you need to post full system specs and a system log.

 

Are you sure he attached it as a non-array drive?  No where does he say he did that.  He does say he has another unraid tower.  He could have just attached a drive from his other tower, at least that is what I am understanding.  But what do I know.  He really isn't clear on what exactly he did and how he did it.

 

Yes, I am sure. Auggie is quite clear.

 

 

Well to clarify, I concur that you cannot perform file transfer operations to the array if the source drive is larger than the parity drive and the source drive is NOT part of the array (so technically, not a "data" drive within the array).  Just want to be clear on the terminology used.

[Auggie]

Once again Auggie. In order for others to hellp you, you need to post full system specs and a system log.

 

Spec already posted, but forgot to include the SM AOC-SASLP-MV8.

 

Syslog no-go, but when I was reviewing it under unMENU, all the "red" errors were basically listed as I/O errors of the various files that unRAID coughed up on (no other descriptive errors were present); first on the source drive, then on the target drive, and culminating and concentrating solely on the parity drive during the later phases of my testing with generic I/O errors listed but no errors posted on either the source or target drives.

[dgaschk]

After almost a week of this process, my conclusions are that unRAID somehow attempts to do some sort of parity syncing with any drive from which files are being transferred from, even though that drive is not incorporated into the array itself, and if that drive is larger than the parity drive, it errors out and may mark the parity drive, target drive, and/or source drive as problematic, and perhaps lead to the drive incorrectly relating the I/O errors to bad sectors on the drive and reassigning them to spare blocks.

 

That is not possible, and can be verified by looking at the unRAID MD driver code.

 

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports. Also, posting solid information such as system logs and full system specifications is the first step in helping others to help you.

 

I concur with BRIT. There is no way to advise further without a syslog.

[eroz]

I suspect you have other issues, likely borderline components such as the power supply, cabling, or sata ports.

 

As I mentioned, I replaced the HBA card and cables both but the issue remains whenever there is a 3TB drive on the system with a 2TB parity drive.

 

I haven't check the PSU, but it worked just fine powering 14 drives with 3 4TB, 6 3TB, and 5 2TB.  The system had 7 2TB drives in the array plus the 3TB source drive when the errors occurred (and involved two different 3TB drives).  It now has 8 2TB drives and another 2TB source drive being copied over as I write this.

 

All drives are WD Greens on SuperMicro X7SPA-HF mobo, 4GB G.Skill RAM, Cooler Master Silent Pro Gold M800.

 

There you go.....You can not have a data drive that is larger than the parity drive.

 

NO. He did not move the larger drive INTO the array. He merely has it available as a non-array drive.

 

Once again Auggie. In order for others to hellp you, you need to post full system specs and a system log.

 

Are you sure he attached it as a non-array drive?  No where does he say he did that.  He does say he has another unraid tower.  He could have just attached a drive from his other tower, at least that is what I am understanding.  But what do I know.  He really isn't clear on what exactly he did and how he did it.

 

Yes, I am sure. Auggie is quite clear.

 

 

Well to clarify, I concur that you cannot perform file transfer operations to the array if the source drive is larger than the parity drive and the source drive is NOT part of the array (so technically, not a "data" drive within the array).  Just want to be clear on the terminology used.

 

 

I missed that.    Sorry!

 

*edit*

No wonder I missed that.  It was added afterwards.

[Auggie]

I concur with BRIT. There is no way to advise further without a syslog.

 

I still have one of the 3TB drives to copy over, untouched.  I was about to copy its contents to a 2TB drive after the current file transfer concludes, but am willing to plug the 3TB back into the unRAID box for the sole purpose of recreating the errors in a syslog for public review.

 

Right now the server is at 9 drives and humming along, so I don't presently believe the issue is with the hardware because the same parity and data drives that initially threw errors have been up and running with a file transfer underway for the past day or so, and as I said, the first 3TB drive I was able to copy over its contents to another drive just fine inside my OS X box with subsequent disk checks always clean (except the notice of those initial bad blocks pending/reassigned).  During my last test, the system would always vomit errors within a few moments after initiating a "cp -pR" operation on the parity drive, no matter what I did to the hardware.

[itimpi]

I have encountered no issue copying files from a 4TB drive mounted outside the array to the array data disks where the largest array drive is 3TB.  This seems an analogous situation.  I would strongly suspect that the issue described relates to either cabling issues, or the power supply getting near its capacity limit (I think this is the most likely to give the symptoms described).

[calxspe]

Are any of you using wireless keyboards at the console level by chance? I've had a couple of run instances where all headless access to my server went down so I wanted to have a last resort keyboard on hand to get at the console. I'm using a Logitech wireless w/ unifying receiver. The keyboard works at post in the BIOS, but once Unraid/Xen (running 6b4) loads and I get to the login prompt it is unresponsive. I've tried using my usb2.0 and 3.0 ports, no dice.

 

Thanks.

[PeterB]

Are any of you using wireless keyboards at the console level by chance? I've had a couple of run instances where all headless access to my server went down...

 

I wonder whether this is the same issue as I reported in reply 166 above?  In my case, IPMI allowed me some console access.

[thebigslicksuitd]

Peter, that's actually me - I had forgotten about that account and didn't realize my laptop was signed in under that account. So ya, nothing new there.

 

 

Sent from my iPhone using Tapatalk

[heffe2001]

Are any of you using wireless keyboards at the console level by chance? I've had a couple of run instances where all headless access to my server went down so I wanted to have a last resort keyboard on hand to get at the console. I'm using a Logitech wireless w/ unifying receiver. The keyboard works at post in the BIOS, but once Unraid/Xen (running 6b4) loads and I get to the login prompt it is unresponsive. I've tried using my usb2.0 and 3.0 ports, no dice.

 

Thanks.

 

I'm using one of Logitech's all-in-one mini keyboards with the trackpad built in, and it works fine with my setup. 

[BobPhoenix]

Are we not able to use the following command on 6b4 to execute mc any more:

sudo -u nobody mc

 

When I tried I got this error:

root@Media3:/boot# sudo -u nobody mc


(mc:13496): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot create /.cache/mc directory


(mc:13496): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot create /.local/share/mc directory
Failed to run:
Cannot create /.config/mc directory

I use "mc" that way so that when I move files they maintain the same permissions as if I wrote them across the network.  Or is that not necessary any more?

[heffe2001]

I use MC quite a bit, and don't recall every having any issues with using it directly without the sudo to nobody (and that's from 4.x something to today's 6b4).

 

Are we not able to use the following command on 6b4 to execute mc any more:

sudo -u nobody mc

 

When I tried I got this error:

root@Media3:/boot# sudo -u nobody mc


(mc:13496): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot create /.cache/mc directory


(mc:13496): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot create /.local/share/mc directory
Failed to run:
Cannot create /.config/mc directory

I use "mc" that way so that when I move files they maintain the same permissions as if I wrote them across the network.  Or is that not necessary any more?

[BobPhoenix]

I use MC quite a bit, and don't recall every having any issues with using it directly without the sudo to nobody (and that's from 4.x something to today's 6b4).

 

Are we not able to use the following command on 6b4 to execute mc any more:

sudo -u nobody mc

 

When I tried I got this error:

root@Media3:/boot# sudo -u nobody mc


(mc:13496): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot create /.cache/mc directory


(mc:13496): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot create /.local/share/mc directory
Failed to run:
Cannot create /.config/mc directory

I use "mc" that way so that when I move files they maintain the same permissions as if I wrote them across the network.  Or is that not necessary any more?

Unfortunately I did have some problems and had to run new permissions on the files.  It's been long enough ago that I don't remember exactly the problem but I believe I wasn't able to see/move/delete files.  But since I've been using "sudo" command I've had no problem.  It works with all 5.0 versions up to 5.0 original release.  Can't say about 5.0.5 as I have not installed it yet.  I'm not planing on installing 5.0.5 on my ESXi servers either as I'm hoping to go to 6.0 and eliminate ESXi completely.  But if 6B4 doesn't require it (for me) then I won't use it.