Unraid OS version 6.8 available


limetech

Recommended Posts

I've just updated to 6.8 but I cannot access my GUI.

 

The server is definitely working as my pfsense VM is working, otherwise I wouldn't have internet. 

 

Am I missing something with this release? I usually access my server via ip address - also tried <servername>.local - but that's not working either.

 

 

EDIT: I now have access to my unraid server, but only after I deleted the static ip address assignment I had for it in pfsense and rebooted server.

 

Is there an issue with static ipaddress assignment and 6.8?

 

 

Edited by Munce31
issue resolved
Link to comment
48 minutes ago, m8ty said:

Hello,

 

What are the instructions to do a manual upgrade from the last stable version—Version 6.7.2?

Tools - Update OS is the recommended way of doing an upgrade.  If you really want to do a manual upgrade, you download the 6.8 zip file from LT's website, then overwrite all the bz* files in the root of the flash drive with the ones contained in the archive

Link to comment
30 minutes ago, Squid said:

Update OS is the recommended way of doing an upgrade

@m8ty the underlying script to do the upgrade does several checks and necessary updates, which are not available when doing a manual update. This may lead to some inconsistency (all depends on your situation before upgrading).

 

Any reason to do a manual upgrade?

Link to comment
1 hour ago, bonienl said:

@m8ty the underlying script to do the upgrade does several checks and necessary updates, which are not available when doing a manual update. This may lead to some inconsistency (all depends on your situation before upgrading).

 

Any reason to do a manual upgrade?

Thank you.

 

Simply curious.  I had a problem with unraid not booting after upgrading earlier this year 

I was not sure if the upgrade process was the issue.

Link to comment

I am getting this error on 

 

Warning: session_write_close(): write failed: No space left on device (28) in /usr/local/emhttp/login.php on line 33

Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php) in /usr/local/emhttp/login.php on line 33

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/emhttp/login.php:33) in /usr/local/emhttp/login.php on line 35

 

never mind, just did a reboot and works fine now

Edited by HarryRosen
Link to comment
10 minutes ago, HarryRosen said:

I am getting this error on 

 

Warning: session_write_close(): write failed: No space left on device (28) in /usr/local/emhttp/login.php on line 33

Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php) in /usr/local/emhttp/login.php on line 33

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/emhttp/login.php:33) in /usr/local/emhttp/login.php on line 35

 

never mind, just did a reboot and works fine now

You should have given us your diagnostics. I doubt the problem you were having is actually related to this release, but it may be a problem with your configuration that may return. My guess is you had somehow filled up rootfs.

Link to comment

Is there an active bug posted around the slow Parity-Sync/Data-Rebuild for wide arrays mentioned being looked at in the errata?

I can't find it in the bug forums.

I'm definitely seeing this problem with my 23 data and 2 parity drive array.  I've replaced both a data drive and one of the parity drives in the same rebuild session so that may be a contributing factor.  I wanted to see if there's any data I can gather that would help in your investigation on the issue and see if there were any stop-gap solutions in the meantime but like I said, I can't find an active bug post for this.

 

Here's my rebuild's current progress:

 

slow parity.png

holocron-diagnostics-20191215-0604.zip

Edited by jedimstr
Link to comment
2 hours ago, bwnautilus said:

I've notice performance problems with SMB shares from Windows 10 clients.  Directory scanning takes about twice as long.

I rolled back to 6.7.2 and the problems went away.

I noticed there's an updated SMB protocol in the release notes for 6.8.0.

Are there any SMB settings I can tweak in 6.8.0?

What are your current SMB settings?  I suggest you turn off NetBIOS and enable WSD.  This turns off SMB1 though, so any older devices might not work.

Link to comment

Upgraded from 6.7.2 without issues. Thanks for the solid work everyone who worked on the OS and all the additional plugins and dockers to make this a fine product.

 

 

I just noticed a minor issue from long ago, and now have it resolved.  The system was trying to enable "eth1" when I thought everything was set to only use "eth0".  It was because network.cfg had SYSNICS="2" from a time when I did have multiple NICs enabled. Editing the file to have SYSNICS="1" and rebooting took care of it.

 

Network.cfg, from before the edit:


# Generated settings:
IFNAME[0]="br0"
BRNAME[0]="br0"
BRSTP[0]="no"
BRFD[0]="0"
BRNICS[0]="eth0"
PROTOCOL[0]="ipv4+ipv6"
USE_DHCP[0]="yes"
DHCP_KEEPRESOLV="no"
USE_DHCP6[0]="yes"
DHCP6_KEEPRESOLV="no"
SYSNICS="2"

 

Snippet of Syslog showing it's trying to do something on eth1 from before the edit:


Dec 15 15:11:00 REAVER rc.inet1: ip -4 addr flush dev eth1
Dec 15 15:11:00 REAVER rc.inet1: ip link set eth1 up
Dec 15 15:11:00 REAVER kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Dec 15 15:11:00 REAVER kernel: 8021q: adding VLAN 0 to HW filter on device eth1

 

Screenshot of Network Settings where Eth2 is shutdown, but Eth1 shows different than Eth2 from before the edit:

image.png.4fc4c81d9e573147d0ec660141ea6e24.png

 

 

  • Thanks 2
Link to comment

 

All went well except my Sven Co-op (half life 1 mod) server is now failing to start with this error:

Quote

 

_stat on file /serverdata/serverfiles/svencoop/liblist.gam which appeared to exist failed!!!

I can't seem to figure out why this update is causing this error. I created a sven co-op docker container and it is erroring inside of that:
https://github.com/skylord123/docker-svencoop-server

Link to comment

Since upgrading from version 6.6.6 (~110Mbps) to 6.7.2(~80Mbps) and now to 6.8.0(~20Mbps) the write speeds on transfers between internal drives have really gone to the gutter.

Even after removing my parity drives the results are same. One file transfer halts the complete system and everything from UI to Dockers is unresponsive to the extent that I have to leave it for the transfer to complete. Plex stops streaming and starts screaming.

 

I have no Idea, if someone has any clue please HELP!

 

Also, same is true for transfers between my PC to Server over Gigabit LAN.

 

No Shares have Cache enabled, there is no parity drives while I am struggling with this. Rest of the build is in my signature below.

 

Thanks in Advance!

-SS

Edited by Shomil Saini
Better Wording
Link to comment
  • jonp unpinned this topic

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.