unRAID OS version 6.5.3 available


121 posts in this topic Last Reply

Recommended Posts

On 6/25/2018 at 9:14 PM, Rich said:

 

Thanks for the heads up ryoko. I gave the three commands a shot and it did sort out the syslog flooding, but sadly didn't solve the single thread at 100% or allow the VM to boot, so looks like i'll be continuing with UEFI disabled for the moment.

That's too bad. Not sure what might be causing the other issue you are running into, sorry bout that

Link to post
  • Replies 120
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Yep.

To upgrade: If you are running any 6.4/6.5 stable release or any 6.4-rc/6.5-rc release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click

Make a copy of the config folder from flash. Prepare flash as for a new install. Copy config folder back.

Posted Images

I've been running this version (6.5.3) for a little over a week and I'm happy to report I have not had one of these error messages show up in the log:

Tower root: error: /JNAP/: missing csrf_token

 

The error showed up quite frequently on my production system, but not on my testing system. It was reported to be mainly tied to leaving a browser window open through a restart of unRAID. But, this scenario didn't seem to fit in my case (stale login credentials, maybe). I thought I was just going to have to live with it but since the update it's gone. Oh Happy Day!

 

Nothing in my external network--hosts--configuration has changed, so I believe the 'fix' was in the update itself. BTW, I was previously running 6.5.2.

 

Cheers!

Edited by doorunrun
Link to post

As far as I know that error message can ONLY come from a browser window (or equivalent) left open across a reboot of the unRAID server.   Having said that it would be nice if Limetech could find a way to invalidate such browser sessions so that the message does not keep spamming the syslog.

Link to post

Server is running great and no issues with performance, or anything else.  However I did notice a few log entries that I don't recall seeing the past.  They may have nothing to do with 6.5.3.

 

Server has been up for about 2 days and 9 hours, and I see 3 entries in my syslog:

 

Jun 29 03:41:13 Tower nginx: 2018/06/29 03:41:13 [error] 10391#10391: *296946 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main"
Jun 29 03:41:13 Tower php-fpm[10365]: [WARNING] [pool www] child 21260 exited on signal 7 (SIGBUS) after 264.591907 seconds from start


Jun 29 20:40:49 Tower nginx: 2018/06/29 20:40:49 [error] 10391#10391: *457950 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main"
Jun 29 20:40:49 Tower php-fpm[10365]: [WARNING] [pool www] child 9358 exited on signal 7 (SIGBUS) after 337.768022 seconds from start


Jun 30 16:16:14 Tower nginx: 2018/06/30 16:16:14 [error] 10391#10391: *618350 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main"
Jun 30 16:16:14 Tower php-fpm[10365]: [WARNING] [pool www] child 17068 exited on signal 7 (SIGBUS) after 289.569545 seconds from start
 

I also see the following warnings in my log:

 

Jun 28 07:46:17 Tower kernel: ACPI: Early table checksum verification disabled


Jun 28 07:46:17 Tower kernel: spurious 8259A interrupt: IRQ7.


Jun 28 07:46:17 Tower kernel: random: 7 urandom warning(s) missed due to ratelimiting


Jun 28 07:46:18 Tower rpc.statd[1769]: Failed to read /var/lib/nfs/state: Success
Jun 28 07:46:18 Tower rpc.statd[1769]: Initializing NSM state
Jun 28 07:46:18 Tower sshd[1787]: Server listening on 0.0.0.0 port 22.
Jun 28 07:46:18 Tower sshd[1787]: Server listening on :: port 22.


Jun 28 07:46:39 Tower sshd[1787]: Received signal 15; terminating.
Jun 28 07:46:39 Tower acpid: client connected from 10225[0:0]
Jun 28 07:46:39 Tower acpid: 1 client rule loaded
Jun 28 07:46:40 Tower sshd[10242]: Server listening on 0.0.0.0 port 22.
Jun 28 07:46:40 Tower sshd[10242]: Server listening on :: port 22.


Jun 28 07:46:41 Tower avahi-daemon[10335]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!

 

Other than these few warnings / errors, my log is clean.

 

Do any of these look serious or important?

 

Thanks!

 

Update:  Given nobody responded, I will assume these errors are not related to the new release.  I'll post in the General Support area.

 

 

Edited by Switchblade
Link to post

i cannot find hyper v in 6.5.3 stable, 

This host does not support Intel VT-x.

This host does not support "Intel EPT" hardware assisted MMU virtualization.

Module 'CPUIDEarly' power on failed.

Failed to start the virtual machine.

Edited by ren88
Link to post
9 hours ago, ren88 said:

i cannot find hyper v in 6.5.3 stable, 

 

It's there when you add or edit a VM

 

9 hours ago, ren88 said:

This host does not support Intel VT-x.

This host does not support "Intel EPT" hardware assisted MMU virtualization.

Module 'CPUIDEarly' power on failed.

Failed to start the virtual machine.

Some context for what you're talking about would be nice.  And the diagnostics / screenshots

Link to post

Anyone else noticed an issue with the performance of VM when parity check running. When VM becomes unresponsive CPU on both cores allocated is 100%. VM is Win10 with graphics card passthru.

 

Diags attached, but i cannot see any issues logged in syslog etc. I do also have Plex running in Docker with DVR recording also.

 

I dont recall seeing same symptoms on 6.5.2, currently Parity Check is at 86%

unraid-diagnostics-20180701-1705.zip

Link to post

Upgraded to 6.5.3 is and my Windows 10 VM would start but there was no display.

Tried rolling back to 6.5.2 and I get the same issue.

Changing the display to VNC instead of GPU passthrough I now get a green screen windows error with an INACCESSIBLE BOOT DEVICE error.

Tried switching disk from VirtIO to SATA and the VM booted with and without GPU passthrough

 

Anyone know how to make this work with VirtIO bus?

 

(Moving this to VM section for visibility)

2018-07-06 16:43:39.896+0000: starting up libvirt version: 4.0.0, qemu version: 2.11.1, hostname: Tower
LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name guest=windows10pro,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-windows10pro/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu host -m 16384 -realtime mlock=off -smp 6,sockets=1,cores=3,threads=2 -uuid d2f62486-79d7-1d78-145a-70e63187f893 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-windows10pro/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 -device pcie,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:76:56:bd,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-windows10pro/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device vfio-pci,host=01:00.0,id=hostdev0,x-vga=on,bus=pci.4,addr=0x0 -device vfio-pci,host=01:00.1,id=hostdev1,bus=pci.5,addr=0x0 -device usb-host,hostbus=3,hostaddr=3,id=hostdev2,bus=usb.0,port=1 -device usb-host,hostbus=3,hostaddr=2,id=hostdev3,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.6,addr=0x0 -msg timestamp=on
2018-07-06 16:43:39.897+0000: Domain id=1 is tainted: high-privileges
2018-07-06 16:43:39.897+0000: Domain id=1 is tainted: host-cpu
2018-07-06T16:43:39.945022Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)

 

Edited by johnsanc
Link to post
On 7/1/2018 at 6:17 PM, SimonF said:

Anyone else noticed an issue with the performance of VM when parity check running. When VM becomes unresponsive CPU on both cores allocated is 100%. VM is Win10 with graphics card passthru.

 

Diags attached, but i cannot see any issues logged in syslog etc. I do also have Plex running in Docker with DVR recording also.

 

I dont recall seeing same symptoms on 6.5.2, currently Parity Check is at 86%

unraid-diagnostics-20180701-1705.zip

 

I have similar problems when another VM or unraid is doing something heavy, VMs and unraid does not respond well, I think qemu is not well implemented because on proxmox everything is rock solid no matter what load it has

Link to post

I get this kind to errors in logs.

 

I understand it's not important and I am not sure if it's a problem of my configuration or a bug.

If you need diagnostics please let me know.

 

Jul 13 04:01:59 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 13 04:01:59 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte11h - assumed 'byte11h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte10h - assumed 'byte10h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte9h - assumed 'byte9h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte8h - assumed 'byte8h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte15h - assumed 'byte15h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte14h - assumed 'byte14h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte13h - assumed 'byte13h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663
Jul 13 04:02:00 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant byte12h - assumed 'byte12h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663

 

Edited by karateo
Link to post
3 hours ago, karateo said:

I get this kind to errors in logs.

 

Same type of problem but mine look like this:

 

Jul 10 17:56:48 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info.
Jul 10 17:56:48 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 10 17:56:48 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 10 17:56:51 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info.
Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 10 17:56:51 Rose rc.diskinfo[8325]: SIGHUP received, forcing refresh of disks info.
Jul 10 17:56:53 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470
Jul 10 17:56:53 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470

 

Link to post
7 hours ago, karateo said:

Jul 13 04:01:59 TOWER rc.diskinfo[30696]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470

 

4 hours ago, Frank1940 said:

Jul 10 17:56:51 Rose rc.diskinfo[8325]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470

The preclear plugin has not been updated AFAIK to remove those errors.  Possibly it's fixed on the 2018.07.09 update though.  You can also silence the errors by Tips & Tweaks plugin and disable Show PHP errors (you've enabled that).  That option is really only for developers anyways and is only used to find those errors listed above.  (Which are simply warnings at the moment, and do not affect anything at all)

Link to post

I installed a samsung 860 evo ssd drive a few weeks ago (working good) and then had a notification from the Fix Common problems that I need to enable Trim, so I did.  I set it to run monthly on the 15th, so it tried to run last night.

 

Today I see this error in my log:

 

Jul 15 00:02:01 Tower kernel: sd 1:0:8:0: [sdj] tag#27 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Jul 15 00:02:01 Tower kernel: sd 1:0:8:0: [sdj] tag#27 Sense Key : 0x5 [current] 
Jul 15 00:02:01 Tower kernel: sd 1:0:8:0: [sdj] tag#27 ASC=0x21 ASCQ=0x0 
Jul 15 00:02:01 Tower kernel: sd 1:0:8:0: [sdj] tag#27 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00
Jul 15 00:02:01 Tower kernel: print_req_error: critical target error, dev sdj, sector 1953277921
Jul 15 00:02:01 Tower root: /var/lib/docker: 34.9 GiB (37411815424 bytes) trimmed

 

Given the word Critical is there, looks important.

 

I have no SMART errors on any of my drives, webgui shows 0 errors for all drives and I ran Scrub and it had zero errors.

 

Is this related to the latest release? 

 

Edited by Switchblade
Link to post
1 hour ago, Switchblade said:

Is this related to the latest release? 

 

Doubtful

 

1 hour ago, Switchblade said:

Given the word Critical is there, looks important.

  

I have no SMART errors on any of my drives, webgui shows 0 errors for all drives and I ran Scrub and it had zero errors.

You should post your diagnostics

Link to post
  • 2 weeks later...

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.