unRAID Server Release 6.1.7 Available


limetech

Recommended Posts

I can't update via the Plugins page. I get this:

 

plugin: updating: unRAIDServer.plg
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.zip ... done
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.md5 ... done
wrong md5
plugin: run failed: /bin/bash retval: 1

 

but I successfully downloaded the zip file using my web browser. I see I have the two files in my server's /tmp directory but they are both zero length. There's also a /tmp/unRAIDServer directory, but it's empty. Is there a way to update manually?

Link to comment
  • Replies 167
  • Created
  • Last Reply

Top Posters In This Topic

What is the default "Critical disk temperature threshold (°C):"?

 

Now with per disk settings in latest version I want to reset all disks back to default threshold and just tweak the Toshiba 5TB that runs hot during parity check (currently all set to 56).

 

The defaults are: Warning, 45°C; Critical, 55°C.

 

Link to comment

I can't update via the Plugins page. I get this:

 

plugin: updating: unRAIDServer.plg
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.zip ... done
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.md5 ... done
wrong md5
plugin: run failed: /bin/bash retval: 1

 

but I successfully downloaded the zip file using my web browser. I see I have the two files in my server's /tmp directory but they are both zero length. There's also a /tmp/unRAIDServer directory, but it's empty. Is there a way to update manually?

Is your flash device full?

Link to comment

I can't update via the Plugins page. I get this:

 

plugin: updating: unRAIDServer.plg
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.zip ... done
plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.md5 ... done
wrong md5
plugin: run failed: /bin/bash retval: 1

 

but I successfully downloaded the zip file using my web browser. I see I have the two files in my server's /tmp directory but they are both zero length. There's also a /tmp/unRAIDServer directory, but it's empty. Is there a way to update manually?

Is your flash device full?

No, it's at 3%. I was able to update a couple of user plugins that were also flagged as having update available.

 

Syslog snippet of two failed attempts, with a successful update of a user plugin in between:

 

Jan 16 20:16:59 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.zip - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.zip
Jan 16 20:17:00 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.md5 - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.md5
Jan 16 20:17:00 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.sh - from INLINE content
Jan 16 20:17:00 Lapulapu logger: plugin: running: /tmp/unRAIDServer.sh
Jan 16 20:39:46 Lapulapu emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall
Jan 16 20:40:11 Lapulapu emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update enhanced.log.plg
Jan 16 20:40:11 Lapulapu logger: plugin: running: anonymous
Jan 16 20:40:11 Lapulapu logger: plugin: creating: /boot/config/plugins/enhanced.log/enhanced.log-2016.01.16.tgz - downloading from URL https://github.com/dlandon/enhanced.log/raw/master/enhanced.log-2016.01.16.tgz
Jan 16 20:40:12 Lapulapu logger: plugin: checking: /boot/config/plugins/enhanced.log/enhanced.log-2016.01.16.tgz - MD5
Jan 16 20:40:12 Lapulapu logger: plugin: running: anonymous
Jan 16 20:40:12 Lapulapu logger: plugin: skipping: /boot/config/plugins/enhanced.log/enhanced.log.cfg already exists
Jan 16 20:40:12 Lapulapu logger: plugin: skipping: /boot/config/plugins/enhanced.log/custom_syslog.conf already exists
Jan 16 20:40:12 Lapulapu logger: plugin: running: anonymous
Jan 16 20:40:23 Lapulapu emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update unRAIDServer.plg
Jan 16 20:40:23 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.sh - from INLINE content
Jan 16 20:40:23 Lapulapu logger: plugin: running: /tmp/unRAIDServer.sh
Jan 16 20:40:23 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.zip - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.zip
Jan 16 20:40:25 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.md5 - downloading from URL https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.1.7-x86_64.md5
Jan 16 20:40:30 Lapulapu logger: plugin: creating: /tmp/unRAIDServer.sh - from INLINE content
Jan 16 20:40:30 Lapulapu logger: plugin: running: /tmp/unRAIDServer.sh

 

There is no unRAIDServer.sh file in my /tmp directory.

 

It's exactly the same on another unRAID server.

Link to comment

Hmm, that's odd. Well if you download the zip manually, you should only need to copy / overwrite the following files on your USB flash root directory:  bzroot, bzimage, and changes.txt.  once done, reboot your system and you'll be on 6.1.7. Still not quite sure why that didn't work for you.

Link to comment
EDIT:  I guess it used to default to PermitRootLogin to yes, and now it doesn't.  The stock unraid config has that setting set, but my file had it commented out so it must have been defaulting to no...  All fixed now...

 

Yes, indeed, this is a general change.  It bit me on my ArchLinux systems a few weeks ago - particularly a headless Raspberry Pi where I logged into root to do a 'pacman -Syu', rebooted and then couldn't log in again.

Link to comment

Ran a parity check last night to confirm all is okay with the latest version (wanted to confirm the performance issue from v6.1.3 didn't resurface).

 

Check ran fine -- HOWEVER, the results aren't displayed.    The main page now shows this:

 

Last checked on Sun 17 Jan 2016 05:09:38 AM CST (today), finding 0 errors.

Duration: unavailable (no parity-check entries logged) 

 

If I click the "History" button to the left of the display it shows the correct info [time, speed, etc.] ... but while it's nice to have the historical info file, the most recent data should still be displayed.

[Tried to just post a graphic of that section, but for some reason the "attachments" dialogue isn't showing up"]

Link to comment

Ran a parity check last night to confirm all is okay with the latest version (wanted to confirm the performance issue from v6.1.3 didn't resurface).

 

Check ran fine -- HOWEVER, the results aren't displayed.    The main page now shows this:

 

Last checked on Sun 17 Jan 2016 05:09:38 AM CST (today), finding 0 errors.

Duration: unavailable (no parity-check entries logged) 

 

If I click the "History" button to the left of the display it shows the correct info [time, speed, etc.] ... but while it's nice to have the historical info file, the most recent data should still be displayed.

[Tried to just post a graphic of that section, but for some reason the "attachments" dialogue isn't showing up"]

 

Delete the file /config/parity-checks.log from the flash device. It should re-populate in a minute or less and make the latest result visible (unless the system was rebooted in the meantime).

 

Link to comment

Delete the file /config/parity-checks.log from the flash device. It should re-populate in a minute or less and make the latest result visible (unless the system was rebooted in the meantime).

 

Did not do that -- made NO changes at all except loading the Dashboard (as I just noted) ... and suddenly the display was fine.    I had, however, tried closing the browser and then re-loading several times, and this did NOT show the results -- but once you switch to the Dashboard page everything's okay going forward.

 

Link to comment

Delete the file /config/parity-checks.log from the flash device. It should re-populate in a minute or less and make the latest result visible (unless the system was rebooted in the meantime).

 

Did not do that -- made NO changes at all except loading the Dashboard (as I just noted) ... and suddenly the display was fine.    I had, however, tried closing the browser and then re-loading several times, and this did NOT show the results -- but once you switch to the Dashboard page everything's okay going forward.

 

Due to the bug in the previous version, there might be some rogue entries in the parity log file, hence my suggestion.

 

Switching between Dashboard and Main forces a reread of the log file. Good to hear it is working now :)

 

Link to comment

... Good to hear it is working now :)

 

I wouldn't say it's "working now" => I suspect you always have to force it by switching to the Dashboard.    But that switch DOES resolve the display ... and it's a very minor thing, so I'd agree nothing needs to be done to it.  It's certainly simply enough after a parity check to just click on the Dashboard to force the status to be updated.

 

Link to comment

... Good to hear it is working now :)

 

I wouldn't say it's "working now" => I suspect you always have to force it by switching to the Dashboard.    But that switch DOES resolve the display ... and it's a very minor thing, so I'd agree nothing needs to be done to it.  It's certainly simply enough after a parity check to just click on the Dashboard to force the status to be updated.

 

But if you delete the file as I mentioned earlier, it will definitely work!

 

Link to comment

... But if you delete the file as I mentioned earlier, it will definitely work!

 

Done.  So the next time I do a parity check, I should see the duration on Main without the need to go to the Dashboard -- right?

 

It should show the latest parity check result as long as the system wasn't restarted before the file is deleted. Recheck the main menu after a minute (I presume system notifications are enabled, this causes the background monitor process to make updates).

 

Link to comment

Update:

 

... the display switched back to "Duration: unavailable (no parity-check entries logged)" => but as you noted, a minute later the correct time is shown, with no need to switch display pages (just refreshed Main).

 

I presume once this is done, it will be correctly updated in the future with no need to repeat the process -- right??

 

 

 

 

 

Link to comment

Update:

 

... the display switched back to "Duration: unavailable (no parity-check entries logged)" => but as you noted, a minute later the correct time is shown, with no need to switch display pages (just refreshed Main).

 

I presume once this is done, it will be correctly updated in the future with no need to repeat the process -- right??

 

Right!

Link to comment

Kicked off a copy of around 3 TB of files to a system with only half of that space available (didn't notice) and letting it run overnight. I woke up to find the system full, all the user shares gone, the user tab in the admin empty. A reboot brought the shares back but unfortunately I didn't think to copy the syslog off prior.

 

Trying to duplicate, no luck yet.

Link to comment

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.