unRAID Server Release 6.2.0-beta18 Available


Recommended Posts

  • Replies 421
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

spinning up an opensuse VM from the template, i had to change

 

OS Install CDRom Bus:

 

to virtio from ide or it error out about unsupported controller.

 

Can you try 'SATA' for the OS Install CDRom Bus for a opensuse VM?  Also, which version of opensuse are you using?

Link to comment

spinning up an opensuse VM from the template, i had to change

 

OS Install CDRom Bus:

 

to virtio from ide or it error out about unsupported controller.

 

Can you try 'SATA' for the OS Install CDRom Bus for a opensuse VM?  Also, which version of opensuse are you using?

 

opensuse leap 42.1

 

i'll give sata setting a go

Link to comment

is this telling me that ipv6 is enabled ?

 

Mar 12 22:32:01 Unraid-Nas dnsmasq[7520]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify

 

No IPv6 in unRAID, yet ;) ... that stock dnsmasq package we use was compiled by a slackware developer who had IPv6 support on their build machine.

Link to comment

Hey guys :)

Just had a scary moment! (Thank god for UNRAID/previous)!!

 

Upgraded to 6.2 Beta via the manual plugin update - Booted fine, got past a bunch of bootup stuff... Then, I got to "searching for /dev/...... label UNRAID (Looking for 30 seconds)

over and over again

 

Until it fails, unable to find label = UNRAID

 

Then it says tower login:

 

root / no pass works

But I can't get to the IP of the server - I can SSH in and I can access it locally / IPMI

 

But I've thankfully rolled back to 6.1.9 :D By copying the contents of /previous - on the USB - back into the root directory of the USB and booting it back up :)

Link to comment

Hey guys :)

Just had a scary moment! (Thank god for UNRAID/previous)!!

 

Upgraded to 6.2 Beta via the manual plugin update - Booted fine, got past a bunch of bootup stuff... Then, I got to "searching for /dev/...... label UNRAID (Looking for 30 seconds)

over and over again

 

Until it fails, unable to find label = UNRAID

 

Then it says tower login:

 

root / no pass works

But I can't get to the IP of the server - I can SSH in and I can access it locally / IPMI

 

But I've thankfully rolled back to 6.1.9 :D By copying the contents of /previous - on the USB - back into the root directory of the USB and booting it back up :)

Bin there... I suspected the flash drive but after reformatting it started to work again.

Link to comment
I also think this is a bad move, my internet connection can be flaky...

 

Don't talk to me about flaky Internet (or power, or water, or phone .....)

 

For -beta and -rc releases, of all key types, the server must validate at boot time.

 

I have been keen to test betas/rcs in the past but, unless there is some leeway on this license check, I'm going to have to wait for final releases from now on (and I've just finished preparing a drive for the second parity device).  With an average of two power cuts a day, and the phone/adsl exchange going off on a different schedule, dependence on Internet connection is simply inconceivable.

 

The reason is that this lets us "invalidate" a beta release.  That is, if a beta gets out there with a major snafu we can prevent it being run by new users who stumble upon the release zip file.  For example, if there is a bug in P+Q handling.  Remember the reiserfs snafu last year?  We want to minimize that.

 

I can understand your reasoning.

 

For stable releases, Basic/Plus/Pro keys do not validate at boot time, that is, works the same as it always has.

 

Well, that at least, is a great relief!

 

Starting with 6.2, Trials will require validation with key server.  This is in preparation for making the Trial experience easier.

 

Again, if that is strictly, and immediately, implemented on every boot, running a Trial will be very difficult for anyone in a similar situation to me.

 

I know that it would involve some extra work, but would it be possible to allow a few hours leeway after a boot.  Indeed, as others have pointed out, many lucky people can keep their machines up for several months without interruption, so in order to provide real protection against broken betas, you would need to implement a regular 'phone home' even without a reboot.  Perhaps, phone home every 24 hours, but allow for retries for up to six hours before stopping?

Link to comment

 

So, does dual parity allow single bit error detection and correction?

 

Ohhh, good question.

 

I think the question(s) has to be even further expanded.  Does it provide for single bit error detection as to the true location of the fault (i.e., the disk with the failure on it) and provide for correction of said error?  In case of two failures, does it allow the ability to rebuilt both failures and what is the level of error identify?  What is the rebuilt procedure in the case of two devices failing? (Replace one disk at a time with two rebuilds or replace both disks with a single rebuild?)

 

Remember that the more failures there are in an array (thinking of disks here), figuring out which ones are bad is going to be much more difficult.

 

Curious as well. That was one of the things Btrfs brought to the table that I was hoping would eventually be implemented, along with deduplication

Link to comment

I will do a reboot after parity check .....but right now this is in my syslog on so many rows....

Will report after reboot tomorrow.

 


Mar 12 17:44:01 Tower emhttp: shcmd (2589): /etc/rc.d/rc.nfsd start |& logger
Mar 12 17:45:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 12 17:45:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 12 17:45:01 Tower emhttp: shcmd (2601): /etc/rc.d/rc.nfsd start |& logger
Mar 12 17:46:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 12 17:46:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 12 17:46:01 Tower emhttp: shcmd (2613): /etc/rc.d/rc.nfsd start |& logger
Mar 12 17:47:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 12 17:47:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 12 17:47:01 Tower emhttp: shcmd (2625): /etc/rc.d/rc.nfsd start |& logger

 

 

 

 

 

 

15:34:49 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set

Mar 12 15:34:49 Tower kernel: DMAR: DMAR:[DMA Read] Request device [02:00.0] fault addr fc02b7000

Mar 12 15:34:49 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set

Mar 12 15:34:49 Tower kernel: DMAR: DMAR:[DMA Read] Request device [02:00.0] fault addr fc02b9000

Mar 12 15:34:49 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set

Mar 12 15:34:49 Tower kernel: DMAR: DMAR:[DMA Read] Request device [02:00.0] fault addr fc02b9000

 

@ LT I ahve sent you mail about my missing shares

 

This dont looks good :-( I was also tested to add a new share called Test_share

 

Mar 13 07:53:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:54:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:54:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:54:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:55:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:55:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:55:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:55:30 Tower emhttp: shcmd (333): /usr/sbin/hdparm -y /dev/sdk &> /dev/null
Mar 13 07:56:02 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:56:02 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:56:02 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:56:06 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:56:06 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:56:06 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:56:09 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:56:09 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:56:09 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:57:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:57:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:57:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:58:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:58:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:58:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 07:59:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 07:59:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 07:59:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 08:00:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 08:00:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 08:00:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 08:01:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 08:01:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 08:01:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 08:02:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 08:02:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 08:02:01 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 08:02:23 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 08:02:23 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 08:02:23 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported
Mar 13 08:02:25 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Movie Operation not supported
Mar 13 08:02:25 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Music Operation not supported
Mar 13 08:02:25 Tower emhttp: get_filesystem_status: getxattr: /mnt/user/Test_share Operation not supported

Link to comment

Found a couple of things different to 6.1.9

 

1) I have an update available on nerdpack plugin (shown under settings) however the update button doesnt do anything. (lshw-B.02.17-x86_64-1_SBo_LT.txz)

 

2) I have some lines in my go script to install a python program:

- it needs to install PIP, for which I use https://pip.pypa.io/en/stable/installing

- That program gives an error "ImportError: cannot import name HTTPSHandler"

 

* I have seen reference to Python needing openssl here: http://stackoverflow.com/questions/32054580/httpshandler-error-while-installing-pip-with-python-2-7-9

 

 

 

 

 

Link to comment

 

So, does dual parity allow single bit error detection and correction?

 

Ohhh, good question.

 

I think the question(s) has to be even further expanded.  Does it provide for single bit error detection as to the true location of the fault (i.e., the disk with the failure on it) and provide for correction of said error?  In case of two failures, does it allow the ability to rebuilt both failures and what is the level of error identify?  What is the rebuilt procedure in the case of two devices failing? (Replace one disk at a time with two rebuilds or replace both disks with a single rebuild?)

 

Remember that the more failures there are in an array (thinking of disks here), figuring out which ones are bad is going to be much more difficult.

 

Curious as well. That was one of the things Btrfs brought to the table that I was hoping would eventually be implemented, along with deduplication

 

 

From what I can see, and I’m sure LT will correct me if I’m wrong, it doesn’t identify the disk with the error, you can however know if a sync error is on the disk or parity, sync errors are detected as P(parity), Q(parity2), or PQ(both), so if on a parity check the log indicates PQ sync error it’s the disk, if P or Q sync error it’s that specific parity.

 

For rebuilds/upgrades you just multiply by 2 what you could do before:

 

-rebuild 2 disable disks at the same time

-upgrade 2 disks at the same time (including one or both paritys)

 

You can also:

 

-rebuild one disk and upgrade another one at the same time

-rebuild one disk and upgrade one parity

-any another combination you can think of

 

Naturally, if you have two disable disks and only have spare, you can rebuild just one.

 

 

 

Also did some more dual parity write speed tests, for those with less powerful CPUs, these were done using a Celeron D430 (single core @ 1.8Ghz):

 

Single parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 166.883 s, 61.4 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 167.153 s, 61.3 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 167.271 s, 61.2 MB/s

 

Dual parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 168.343 s, 60.8 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 169.23 s, 60.5 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 169.292 s, 60.5 MB/s

 

 

So even on an entry level nine year old CPU the write speed penalty with dual parity is insignificant, and on an entry level more modern CPU (e.g., Pentium G2030 DC @ 3.0Ghz), there’s zero speed penalty:

 

Single parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 165.042 s, 62.0 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 165.133 s, 62.0 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 164.827 s, 62.1 MB/s

 

Dual parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 164.821 s, 62.1 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 164.862 s, 62.1 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 164.524 s, 62.2 MB/s

 

Link to comment

In the GUI when i try to enable Docker i get

Warning: file_put_contents(/boot/config/docker.cfg): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php on line 48

 

And when i try to enable VMs

Warning: file_put_contents(/boot/config/domain.cfg): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix.vm.manager/classes/libvirt_helpers.php on line 375

 

Fresh install and clear discs.

 

EDIT: Reboot helped, VMs seems to work, but Docker is showing "stopped"

Link to comment

...Also did some more dual parity write speed tests, for those with less powerful CPUs, these were done using a Celeron D430 (single core @ 1.8Ghz):

 

Single parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 166.883 s, 61.4 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 167.153 s, 61.3 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 167.271 s, 61.2 MB/s

 

Dual parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 168.343 s, 60.8 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 169.23 s, 60.5 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 169.292 s, 60.5 MB/s

 

 

So even on an entry level nine year old CPU the write speed penalty with dual parity is insignificant, and on an entry level more modern CPU (e.g., Pentium G2030 DC @ 3.0Ghz), there’s zero speed penalty:

 

Single parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 165.042 s, 62.0 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 165.133 s, 62.0 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 164.827 s, 62.1 MB/s

 

Dual parity

10240000000 bytes (10 GB, 9.5 GiB) copied, 164.821 s, 62.1 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 164.862 s, 62.1 MB/s
10240000000 bytes (10 GB, 9.5 GiB) copied, 164.524 s, 62.2 MB/s

 

Thanks for testing and sharing the results.

 

Link to comment

The check license at start-up is a poorly thought through implementation IMO. Being unraid runs a hypervisor i think it is a fairly safe assumption to think that some people, not all, but some will run virtualised firewalls on the system. Obviously the inability to start libvert without the array doesn't exist yet so there is no way for people like myself to satisfy the license check.

 

I know it's only being implemented for RC and beta, but i think more thought needs to go into this. 

Link to comment

Since 6.2 is available to all,  would it not be sensible to add a 6.2 verified child board to the plugins sub forum ?

That might lead to unnecessary fragmentation in the forum.  The view so far seems to be that plugins that are compatible with 6.1 either work unchanged with 6.2 or the change to make it compatible with both is small.  Maybe we need to wait a bit longer to see if there is going to be fragmentation of plugins between 6.1 and 6.2.
Link to comment

Not sure if these messages mean anything or not.  I noticed them in my syslog:

 

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster kernel: mdcmd (43): spindown 0

Mar 13 08:40:03 Dumpster kernel: mdcmd (44): spindown 1

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster kernel: mdcmd (45): spindown 2

Mar 13 08:40:03 Dumpster kernel: mdcmd (46): spindown 3

Mar 13 08:40:03 Dumpster kernel: mdcmd (47): spindown 4

Mar 13 08:40:03 Dumpster kernel: mdcmd (48): spindown 5

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster emhttp: mdcmd: write: No such device or address

Mar 13 08:40:03 Dumpster kernel: mdcmd (49): spindown 6

Link to comment

So got errors with the reg-key (i'm on trial), and when i tried to re-enter the trial key it came up with error 1 - what ever that is.

Also, docker dosen't work, no mather how many fresh installs i tried at the end it came up with "image missing in /mnt/user/system/docker".

 

So going back to the stable 6.19 to test my trial period, 6.2 looks promising so can't wait for it to go stable.

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