Upgraded from 6.6.5. Everything appears in order. I love the "new" GUI!

13 hours ago, trott said:

I think I just wait for the 5.9-rc1, I'm on ryzen, I need 5.4 kernel to test ECC

You meant 6.9 instead of 5.9

Three days of solid stability. Everything looks as expected. Nice work.

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 December 14, 20196 yr by Munce31
issue resolved

5 hours ago, Munce31 said:

Is there an issue with static ipaddress assignment and 6.8?

Unlikely. Are you sure something else on your network didn't grab that IP?

Upgraded two servers with no issues.  Thanks for all the hard work!

 

-srengr

7 hours ago, Munce31 said:

Is there an issue with static ipaddress assignment and 6.8?

I have three servers running with a static IP assignment...

Hello,

 

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

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

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?

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.

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 December 15, 20196 yr by HarryRosen

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.

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:

 

holocron-diagnostics-20191215-0604.zip

Edited December 15, 20196 yr by jedimstr

2 minutes ago, jedimstr said:

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

It's here, but that's way too slow, you should start a thread in the general support forum and please attach the diagnostics.

3 minutes ago, johnnie.black said:

It's here, but that's way too slow, you should start a thread in the general support forum and please attach the diagnostics.

Thanks I'll post in general support.  My results definitely seem much slower by an order of magnitude than the slowdowns mentioned in the bug post.

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?

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.

No issues.  One thing I will mention, if you are running Pi Hole manually which is how I have it setup and always forget that.  Without it started the docker page was not loading, once I started it everything worked perfectly.  Thanks again

Edited December 15, 20196 yr by squirrellydw

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:

 

 

9 hours ago, dlandon said:

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.

I'm afraid I still need SMB1 as there are some legacy devices on my network.

 

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

Upgraded from 6.7.2 without issues.
Love the WireGuard feature!

Alright, my test-server survived the upgrade no sweat... Gonna try upgrading main-server in a few days...

 

Any chance of getting DVB drivers and firmwares into mainstream kernel in the future?

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 December 16, 20196 yr by Shomil Saini
Better Wording