Dont have temps showing on NVME unassigned. But it shows correctly as Unassigned vs last release

 

Updated fine. 

 

All these updates really ruin my uptime stats, only 2 months this time...

32 minutes ago, Lebowski said:

Dont have temps showing on NVME unassigned. But it shows correctly as Unassigned vs last release

 

 

Can you post the output of

smartctl -A /dev/nvme0

 

45 minutes ago, Lebowski said:

Dont have temps showing on NVME unassigned. But it shows correctly as Unassigned vs last release

 

Just noticed than my unassigned disks also not reporting temp on the dashboard. almost sure it was working on rc10, it works on the main page, does yours shown on main? Maybe not NVMe related this time.

 

 

 

 

18 minutes ago, johnnie.black said:

Maybe not NVMe related this time.

 

Right, a small regression error (wrong reference to disk) in Dashboard table.

 

Sorry for that, correction made.

17 hours ago, limetech said:

If using 'https' all 'http' is redirected to 'https'.  If not using 'https', all 'https' is redirected to 'http'.  The result of this is you can always enter servername in browser address bar to get to webGui, for example "Tower/" or "Tower.local" should always get you to the webGui.  In the case of SSL-enabled LE certificate, you will get redirected to the <hash>.unraid.net URL.

 

Hello,

 

those redirect rules can't be so strict as they are now! I see at least two problems with them. And some more were mentioned already in this thread.

 

1. In macOS world (and some linux flavours) the dns for unraid server would be `tower.local` (or `unraid.local` in my case) instead `tower`. So any redirect to http://unraid/ or https://unraid/ will fail. 

2. Personally I don't have DNS setup for my VPN connection. So when I'm away I connect to the unraid using its IP. 192.168.250.5 (or whatever). Nginx redirects as they are right now... redirect it to http(s)://unraid/ which doesn't work. 

 

I don't use LE certs. I use autogenerated during install self-signed cert. But still I tested things with both SSL ON and OFF. In both cases there were redirects which made my macOS machines and VPN connected clients not work.

 

For the time being I added appropriate server names to nginx config. In my case it would be modification to `server_name`

server_name unraid unraid.local *.unraid 192.168.250.5 127.0.0.1;

 in the `/etc/nginx/conf.demhttp-servers.conf` and nginx restart `nginx -s reload`. But it's far from ideal plus (I assume) I'd need to modify this config after each server restart.

 

Hope you can make those redirects less strict in future update. (I'd say it's pretty critical!)

Oskar Gargas

I am using the EFI boot and when applying this update the EFI files did not get updated

 

ls -l /boot/EFI/boot
total 656
-rwxrwxrwx 1 root root 199952 Oct 27 09:26 bootx64.efi*
-rwxrwxrwx 1 root root 139968 Oct 27 09:26 ldlinux.e64*
-rwxrwxrwx 1 root root 201680 Oct 27 09:26 libcom32.c32*
-rwxrwxrwx 1 root root  24480 Oct 27 09:26 libutil.c32*
-rwxrwxrwx 1 root root  12752 Oct 27 09:26 mboot.c32*
-rwxrwxrwx 1 root root  31760 Oct 27 09:26 menu.c32*
-rwxrwxrwx 1 root root     32 Oct 27 09:26 syslinux.cfg*

The files from the update all have a Nov 14 date on them. 

4 hours ago, bonienl said:

 

Right, a small regression error (wrong reference to disk) in Dashboard table.

 

Sorry for that, correction made.

Hopefully that also fixes the attributes for a UD disk from the dashboard.

 

URL: http://mediaserver/Dashboard/New?name=

1 hour ago, bcjenkins said:

I am using the EFI boot and when applying this update the EFI files did not get updated

 

ls -l /boot/EFI/boot
total 656
-rwxrwxrwx 1 root root 199952 Oct 27 09:26 bootx64.efi*
-rwxrwxrwx 1 root root 139968 Oct 27 09:26 ldlinux.e64*
-rwxrwxrwx 1 root root 201680 Oct 27 09:26 libcom32.c32*
-rwxrwxrwx 1 root root  24480 Oct 27 09:26 libutil.c32*
-rwxrwxrwx 1 root root  12752 Oct 27 09:26 mboot.c32*
-rwxrwxrwx 1 root root  31760 Oct 27 09:26 menu.c32*
-rwxrwxrwx 1 root root     32 Oct 27 09:26 syslinux.cfg*

The files from the update all have a Nov 14 date on them. 

I don't think they need to be updated.  Mine show a date of July.

does anyone know letsencrypt settings to make the webgui redirect from the outside using a proxy pass?

4 minutes ago, dlandon said:

Hopefully that also fixes the attributes for a UD disk from the dashboard.

 

Yes, reading attributes is affected by the same regression bug. Fix is done.

 

1 hour ago, bcjenkins said:

I am using the EFI boot and when applying this update the EFI files did not get updated

 

ls -l /boot/EFI/boot
total 656
-rwxrwxrwx 1 root root 199952 Oct 27 09:26 bootx64.efi*
-rwxrwxrwx 1 root root 139968 Oct 27 09:26 ldlinux.e64*
-rwxrwxrwx 1 root root 201680 Oct 27 09:26 libcom32.c32*
-rwxrwxrwx 1 root root  24480 Oct 27 09:26 libutil.c32*
-rwxrwxrwx 1 root root  12752 Oct 27 09:26 mboot.c32*
-rwxrwxrwx 1 root root  31760 Oct 27 09:26 menu.c32*
-rwxrwxrwx 1 root root     32 Oct 27 09:26 syslinux.cfg*

The files from the update all have a Nov 14 date on them. 

 

The files in rc11i have a newer date but haven't changed, hence your original files on the flash device are not overwritten.

 

I have a ssd with a relocated sector. 

on rc10 I could press acknowledge to get rid of the yellow triangle on the dashboard screen. Now this button does nothing.

 

 

Edited November 16, 20178 yr by Handl3vogn
addding picture

Did the docker settings change in this release?  After updating, my docker paths are now showing as invalid.

 

My docker paths point to an unassigned ssd drive that I've mounted and have been using for over a year specifically for docker. The docker.img and the appdata paths reside on this drive.

 

I've tried to reset the paths in the docker config to no avail.  I can select the docker image via the docker storage location field, but it still shows as invalid.  In the appdata storage location path, it won't allow me to choose the unassigned drive at all any more.

 

The ssd is functioning. I'm currently copying the docker data to a backup location.

 

I've included a screen shot of the error and the diagnostic files, should they be helpful

 

Thank you.

tower-diagnostics-20171116-0922.zip

44 minutes ago, Handl3vogn said:

on rc10 I culd press acknowledge to get red of the yellow triangle on the dashbord screen. Now this button does nothing

 

Right, you've found another regression error.

Accidentally a line deleted in the script code  Corrected.

 

1 hour ago, MisterWolfe said:

Did the docker settings change in this release?  After updating, my docker paths are now showing as invalid.

 

Docker settings have not changed.

 

The reason your path is invalid is because the mounting of the disk is not performed. This is in your syslog:

Tower unassigned.devices: Mounting 'Auto Mount' Devices...
Tower unassigned.devices: Disk with serial 'PLEXTOR_PX-128M5Pro_P02325101466', mountpoint 'PLEXTOR_PX-128M5Pro_P02325101466' is not set to auto mount and will not be mounted...
Tower unassigned.devices: Disk with serial 'ST9250315AS_5VC7XXWG', mountpoint 'binky' is not set to auto mount and will not be mounted...

 

 

4 minutes ago, bonienl said:

 

Docker settings have not changed.

 

The reason your path is invalid is because the mounting of the disk is not performed. This is in your syslog:

Tower unassigned.devices: Mounting 'Auto Mount' Devices...
Tower unassigned.devices: Disk with serial 'PLEXTOR_PX-128M5Pro_P02325101466', mountpoint 'PLEXTOR_PX-128M5Pro_P02325101466' is not set to auto mount and will not be mounted...
Tower unassigned.devices: Disk with serial 'ST9250315AS_5VC7XXWG', mountpoint 'binky' is not set to auto mount and will not be mounted...

 

 

I mounted the drive manually as part of my testing process and the drive was indeed mounted when I attempted to run docker.  See image below.

 

To confirm that not using auto mount may have been an issue, I restarted the array with auto mount enabled.

 

I still have the same issue.

 

As part of this, the default appdata used to let me go to the /mnt directory and choose which disk I wanted to put my appdata folder on. It now goes to the user/array folder and does not let me drill down further intro the tree.

 

My next testing step will be to copy the docker.img and appdata folders to a different drive and see if they are recognized.

 

13 hours ago, bonienl said:

 

Good to hear

This release allows correct monitoring of NVMe device temperature too. You can set warning and critical thresholds as needed.

 

Speaking of SMART temperatures. Is there any way to deal with drives that use an inverted scale? I have two Samsung 960 Enterprise SSD drives. The Samsung branded drive reports normal temperatures. The IBM branded one uses an inverted measurement of (100 - temp) so instead of reading 33 degrees it will display 67. 

Looks like it gets closer to release

34 minutes ago, ssb201 said:

The IBM branded one uses an inverted measurement of (100 - temp) so instead of reading 33 degrees it will display 67. 

 

You've got to be kidding!

4 minutes ago, limetech said:

 

You've got to be kidding!

I wish. I freaked out the first time I saw the temperature read. Immediately shut down the computer and felt it (cool to the touch). I then tried running it with an infrared thermometer and it definitely was not overheating. 

 

 

 

Edited November 16, 20178 yr by ssb201
typo

11 minutes ago, ssb201 said:

I wish. I freaked out the first time I saw the temperature read. Immediately shut down the computer and felt it (cool to the touch). I then tried running it with an infrared thermometer and it definitely was not overheating. 

 

 

 

 

Did you find this documented somewhere (that is reports 100-temp) or speculation?  If latter, maybe that particular device simply has a bad temp probe.

19 minutes ago, limetech said:

 

Did you find this documented somewhere (that is reports 100-temp) or speculation?  If latter, maybe that particular device simply has a bad temp probe.

 

I never bothered digging further because I could see it drop from 70 to 69 to 65 or lower as the computer warmed up and it should be getting warmer. Just did a dump and it looks like the application is just pulling the wrong field:

 

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
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       5963
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       19
100 Unknown_Attribute       0x0033   098   098   005    Pre-fail  Always       -       59
170 Unknown_Attribute       0x0033   100   100   010    Pre-fail  Always       -       100
173 Unknown_Attribute       0x0023   098   098   005    Pre-fail  Always       -       98
190 Airflow_Temperature_Cel 0x0023   069   060   026    Pre-fail  Always       -       69
194 Temperature_Celsius     0x0022   069   060   000    Old_age   Always       -       31
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
231 Temperature_Celsius     0x002a   098   098   000    Old_age   Always       -       98
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       123411751992
242 Total_LBAs_Read         0x0032   099   099   000    Old_age   Always       -       41899321451
 

The UI is reporting the #190 Airflow Temp in Celsius (which is 100 - case temp per spec docs) rather than #194 device temperature.

 

 

Edited November 16, 20178 yr by ssb201

4 minutes ago, ssb201 said:

The UI is reporting the #190 Airflow Temp in Celsius (which is 100 - case temp per spec docs) rather than #194 device temperature.

 

Thanks for looking into this: that's a bug (should prefer 194 over 190 if both are present).

15 hours ago, bonienl said:

 

Good to hear

This release allows correct monitoring of NVMe device temperature too. You can set warning and critical thresholds as needed.

I can't see where to set NVMe temps, or is this not for UD?