unRAID OS version 6.4.0-rc9f available

[itimpi 156]

2 hours ago, ideaman924 said:

Again, thought it was the monitor causing the issues (initial tests supported my suspicion)

 

But after further testing I found out the monitor doesn't matter. The keyboard does...

It is worth checking carefully whether there is a BIOS setting for allowing the system to boot with no keyboard attached.   I know on my motherboard there is and the default setting is for the boot process to stop ifno keyboard is detected. So that needs changing if you want to run headless.

[avluis 1]

8 hours ago, ideaman924 said:

But after further testing I found out the monitor doesn't matter. The keyboard does...

 

I know that on my SM mobo, I can have it halt the boot process if a keyboard is not detected.

If you cannot change this setting, have you considered getting a cheap logitech wireless mouse or keyboard that makes use of their Unifying dongle?

This will register as a USB mouse/keyboard and should allow you to boot without issue while in UEFI mode.

[HellDiverUK 51]

Ha ha, AsRock.  "Oh but AsRock is brilliant" they say.  Until they aren't...

 

Now where's my AsRock are shit thread till I add this comedy fault to it?  

[tstor 6]

If your motherboard accepts USB keyboards you can get cheap (~ USD 1) programmable USB dongles that can register as a keyboard, a dummy monitor plug is a few dollars.

[ideaman924 0]

I do have a Unify receiver lying around, but I'm going to first try the BIOS method mentioned by @itimpi, if it exists, of course.

 

If UEFI doesn't have any benefits I might just sod it and go legacy.

[jjslegacy 1]

twice with this latest build my machine hasn't been able to boot and ends up in a UEFI shell.

 

The USB drive has needed repaired on my windows box both times. 

 

Not really sure where to begin  - usb drive going bad?  bad luck?

[nexusmaniac 3]

system lockup again

 

2 images attached, I was able to access the system with keyboard/mouse (via IPMI) and cat the syslog. I was unable to do much else!

 

lsblks

ran fine and all of my disks were detected. I could also 

ls /boot/

and see everything in there.

 

However, as soon as I tried to run 

diagnostics

it just sits there for minutes doing nothing! So far I've given it about 8 mins to run but it's sat there doing nothing...

 

So before I reboot (I would like access to my system again!!) is there anything useful I can run? I've followed what JonP said over in his important diagnostic thread. And I've attached screenshots of my syslog output.

 

Cheers, hopefully we can get this resolved

 

 

[rowid_alex 1]

"Finally fixed reporting of temperature for NVMe devices (hopefully). "

 

This is not for my three SSDs, two for INTEL 730 SATA, one for INTEL 750 NVMe as well.

 

 

Any one else using INTEL SSD having similar issue or not?

 

Best Regards,

Alex

[bonienl 510]

Does it display temperatures after you do "Spin Up" all disks?

[rowid_alex 1]

1 hour ago, bonienl said:

Does it display temperatures after you do "Spin Up" all disks?

It doesn't matter. I am doing parity check now. Same as above.

[saarg 115]

3 hours ago, rowid_alex said:

It doesn't matter. I am doing parity check now. Same as above.

 

Parity check will not spin up your cache drives and unassigned devices drives. 

Edited October 11, 2017 by saarg

[johnnie.black 1302]

Any one else using INTEL SSD having similar issue or not?

 

I don't know about those specific models but all Intel SSDs I've used in the past didn't show temp on SMART, you can check with:

 

smartctl -A /dev/sdX

For the NVMe device try:

 

smartctl -A /dev/nvme0n1

or

smartctl -A /dev/nvme0

 

 

 

[rowid_alex 1]

22 hours ago, johnnie.black said:

 

I don't know about those specific models but all Intel SSDs I've used in the past didn't show temp on SMART, you can check with:

 

 

smartctl -A /dev/sdX

 

For the NVMe device try:

 

 

smartctl -A /dev/nvme0n1

 

or

 

smartctl -A /dev/nvme0

 

 

 

 

 

smartctl shows the temperature actually.

 

root@UNRAID:~# smartctl -A /dev/sdb
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.12.14-unRAID] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
190 Temperature_Case        0x0022   069   059   000    Old_age   Always       -       31 (Min/Max 30/35)

 

root@UNRAID:~# smartctl -A /dev/nvme0
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.12.14-unRAID] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Temperature:                        31 Celsius

 

 

[johnnie.black 1302]

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

190 Temperature_Case        0x0022   069   059   000    Old_age   Always       -       31 (Min/Max 30/35)

 

It's there but it's using a different attribute, I believe temp is usually taken from attribute 194 - Temperature celsius

 

smartctl -A /dev/nvme0

 

Does it also work with /dev/nvme0n1 ? If not it's possibly the same problem as my OCZ RD400, I believe LT is trying to make it work.

 

 

[rowid_alex 1]

36 minutes ago, johnnie.black said:

 

It's there but it's using a different attribute, I believe temp is usually taken from attribute 194 - Temperature celsius

 

 

Does it also work with /dev/nvme0n1 ? If not it's possible the same problem as my OCZ RD400, I believe LT is trying to make it work.

 

ok. then it's intel ssd's problem with smart. yes. I checked my HDDs, they are using id 194 for temperature.

 

no. it doesn't work with /dev/nvme0n1, even though in my "main" page, unRAID read the device as /dev/nvme0n1.

[bonienl 510]

42 minutes ago, johnnie.black said:

It's there but it's using a different attribute, I believe temp is usually taken from attribute 194 - Temperature celsius

 

Both attribute IDs 190 or 194 may be used to indicate temperature, I am not sure whether emhttp checks for attribute ID or attribute name to extract the temperature value.

That is a question for LT.

 

[Videodr0me 7]

Today I noticed this warning in the system log:

 

Oct 13 07:55:08 Tower php-fpm[10268]: [WARNING] [pool www] server reached max_children setting (10), consider raising it

 

any ideas?

[Interstellar 0]

Updated this morning, everything seems OK!

[Jerky_san 5]

So after experiencing the problem again with unclean shutdowns I said screw it and tried it on my Ryzen board/system. Still occurred after a few days. I know some have said its the drive but if it is the drive then why does it not occur until after about 7-8 days of uptime? Why does the plugin page signal the problem has arrived by updates not being check-able? It doesn't make any sense what so ever. When the updates are not check-able I cannot click the stop array but anymore either. It appears to have started when the new GUI speed enhancements were implemented.

[zoggy 10]

On 10/13/2017 at 1:34 AM, Videodr0me said:

Today I noticed this warning in the system log:

 

Oct 13 07:55:08 Tower php-fpm[10268]: [WARNING] [pool www] server reached max_children setting (10), consider raising it

 

any ideas?

 

I've seen this before as well,

 

It means that there are not enough PHP-FPM processes.

 

looking at what the settings unraid is using,

# cat /etc/php-fpm.d/www.conf | grep = | grep -v ^\;
user = root
group = root
listen = /var/run/php5-fpm.sock
listen.group = users
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s;
pm.max_requests = 100
chdir = /usr/local/emhttp
php_value[include_path] = ".:/usr/local/emhttp"

 

looking at how much ram a process is using, we see I only have one process and its taking up 12M (rss column)

# ps -ylC php-fpm --sort:rss
S   UID   PID  PPID  C PRI  NI   RSS    SZ WCHAN  TTY          TIME CMD
S     0  6997     1  0  80   0 12564 44808 ep_pol ?        00:00:29 php-fpm

I'm guessing that limeware just wants to keep the total ram usage php can do to a safe threshold for low memory boxes.

Since 10 children taking up 12M each.. would eat up 120 megs.. now if you only had 512mb ram on the box.. i can see the reason for being so conservative.

 

Anyways, I think I only saw this on startup when plugins/dockers/etc are starting up..  not really anything to worry about.

 

[Videodr0me 7]

Do you think we can safely set this to a higher value?

 

10 hours ago, zoggy said:

pm.max_children = 10

 

Where should we do this, so it persits a reboot?

[Darksurf 2]

I'm having strange issues when attempting to update my dockers. They download OK, but when they try to extract or update, sometimes I have to perform the update twice for it to actually take? Not sure whats happening here. I'll even see "command finished successfully" even though I just witnessed it hang up on extraction at 75% (percentage is random it seems). I can now no longer update my plex or unifi dockers.

 

 

Hmm, it seems having 11 dockers was actually my problem. I filled up the 10G docker img. I've noticed for a while now when updating my dockers it would complain of 97% disk usage, but I was thinking utilization as in I/O not disk is nearly full. Sorry for the confusion.

 

cold-rewind-diagnostics-20171016-2022.zip

Edited October 17, 2017 by Darksurf
Found the issue.

[hernandito 13]

Panicking here... I updated from 4.6 rc6 to rc9f and now I cannot get into the web gui.

 

in my go file I have:

/usr/local/sbin/emhttp -p 84

The reason for port 84, is that I have an Apache Docker w/ LetsEncrypt mapped to port 80.

 

All my Dockers seem to be functioning except the Apache LE one that is on port 80.

 

Please help. Thank you!

 

My entire go file looks like:

#!/bin/bash

#Setup the PXE Server - HR Added Jan/2014
installpkg /boot/config/custom/dnsmasq-2.75-x86_64-1.txz
cp /boot/config/custom/dnsmasq.conf /etc
chmod +x /etc/rc.d/rc.dnsmasq

sleep 10

# Start the Management Utility
        /usr/local/sbin/emhttp -p 84


# ================================================
# START This Section Stasts the PXP Server Bit
# ================================================
# determine if cache drive online, retry upto 7 times
        for i in 0 1 2 3 4 5 6 7
        do
                if [ ! -d /mnt/cache ]
                then
                  sleep 10
                fi
        done
/etc/rc.d/rc.dnsmasq start
echo " "
echo "Hernando see if dnsmasq installled right above"
# ================================================
# END - This Section Starts the PXP Server Bit
# ================================================


echo 'PATH=$PATH:/boot ; export PATH' >> /etc/profile

beep -f660 -l100ms -D 130ms
beep -f660 -l100ms -D 170ms
beep -f660 -l100ms -D 150ms
#beep -f510 -l100ms -D 80ms
#beep -f660 -l100ms -D 150ms
#beep -f770 -l100ms -D 275ms
#beep -f380 -l100ms -D 575ms
#beep -f660 -l100ms -D 130ms
#beep -f660 -l100ms -D 170ms
#beep -f660 -l100ms -D 150ms
#beep -f510 -l100ms -D 80ms
#beep -f660 -l100ms -D 150ms
beep -f770 -l100ms -D 275ms

 

 

[Helmonder 10]

2 hours ago, hernandito said:

Panicking here... I updated from 4.6 rc6 to rc9f and now I cannot get into the web gui.

 

in my go file I have:

/usr/local/sbin/emhttp -p 84

The reason for port 84, is that I have an Apache Docker w/ LetsEncrypt mapped to port 80.

 

All my Dockers seem to be functioning except the Apache LE one that is on port 80.

 

Please help. Thank you!

 

My entire go file looks like:

#!/bin/bash

#Setup the PXE Server - HR Added Jan/2014
installpkg /boot/config/custom/dnsmasq-2.75-x86_64-1.txz
cp /boot/config/custom/dnsmasq.conf /etc
chmod +x /etc/rc.d/rc.dnsmasq

sleep 10

# Start the Management Utility
        /usr/local/sbin/emhttp -p 84


# ================================================
# START This Section Stasts the PXP Server Bit
# ================================================
# determine if cache drive online, retry upto 7 times
        for i in 0 1 2 3 4 5 6 7
        do
                if [ ! -d /mnt/cache ]
                then
                  sleep 10
                fi
        done
/etc/rc.d/rc.dnsmasq start
echo " "
echo "Hernando see if dnsmasq installled right above"
# ================================================
# END - This Section Starts the PXP Server Bit
# ================================================


echo 'PATH=$PATH:/boot ; export PATH' >> /etc/profile

beep -f660 -l100ms -D 130ms
beep -f660 -l100ms -D 170ms
beep -f660 -l100ms -D 150ms
#beep -f510 -l100ms -D 80ms
#beep -f660 -l100ms -D 150ms
#beep -f770 -l100ms -D 275ms
#beep -f380 -l100ms -D 575ms
#beep -f660 -l100ms -D 130ms
#beep -f660 -l100ms -D 170ms
#beep -f660 -l100ms -D 150ms
#beep -f510 -l100ms -D 80ms
#beep -f660 -l100ms -D 150ms
beep -f770 -l100ms -D 275ms

 

 

 

Did you read the release notes prior to installing this non-final version?

 

Other notes (-rc8q):

• The /usr/local/sbin/emhttp line in your /boot/config/go file is no longer used to specify the ports where the webGui listens for connections.  Instead you must configure these on the Identification page.  Alternately if you need to set this up prior to server boot, you may add the port settings in /boot/config/ident.cfg.  Please refer to /usr/local/sbin/emhttp script for more information if you care about this.

[steve1977 2]

I have been updating form stable 6.3 to 6.4rc9 because it made it easier to create a MacOS VM.

 

Unfortunately, I am now facing quite some performance related issues, which I assume may be related to the rc9. Let me attach a log file.

 

Let me describe the easiest to replicate issue. I have two array disks mapped as network drives within the VM (Win10). This worked well under 6.3 and I could copy at solid speeds between the two disks. This does not work with 6.4.rc9. When coping files, the copy process is horribly slow and I am then eventually getting an error message within Win10 VM (some read/write error).

 

There are other issues, but they are harder to describe and most likely related to this.

 

I am also attaching the full diagnostic log.

tower-diagnostics-20171027-1024.zip