unRAID Server Release 6.2.0-beta23 Available


Recommended Posts

A pretty trivial observation regarding the Dashboard page of the webGUI, but there doesn't seem to be much else to complain about in this release ;) The two rightmost columns in the Load Statistics pane are unbalanced in width, giving odd-numbered CPUs a much longer Per CPU Load scale than even-numbered ones. Also affected is the flash : log : docker percentage used display.

 

Looks like something wrong with your stylesheets. Have you tried to clear the browser's cache?

 

Picture as it should look like...

dashboard-stats.png.105f1146cd18d0050cdc0e18337747b2.png

Link to comment
  • Replies 229
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I upgraded a few days ago from 6.1.8

It happily rebooted after the upgrade.

No problems at all. Had all my dockers running again.

 

Today it was unresponsive, I could telnet in and tried to shutdown but it never went down.

When I manually shut it down it wouldn't boot up again. It comes back to the command line and I took a diagnostic, but it seems to have some problems with the cache disk.

I didn't open the server and physically change anything.

 

 

I am lost in the log files, any help would be greatly appreciated.

 

Jun 21 20:36:11 Tower kernel: XFS (sdd1): _xfs_buf_find: Block out of range: block 0x7fffffff8, EOFS 0xdf94b70

Jun 21 20:36:11 Tower kernel: ------------[ cut here ]------------

Jun 21 20:36:11 Tower kernel: WARNING: CPU: 0 PID: 12409 at fs/xfs/xfs_buf.c:472 _xfs_buf_find+0x7f/0x28c()

Jun 21 20:36:11 Tower kernel: Modules linked in: md_mod x86_pkg_temp_thermal coretemp kvm_intel ahci kvm libahci i2c_i801 e1000e ptp pps_core wmi

Jun 21 20:36:11 Tower kernel: CPU: 0 PID: 12409 Comm: mount Not tainted 4.4.13-unRAID #1

Jun 21 20:36:11 Tower kernel: Hardware name: ASUS All Series/H87I-PLUS, BIOS 2003 11/05/2014

Jun 21 20:36:11 Tower kernel: 0000000000000000 ffff880214e67950 ffffffff81369dde 0000000000000000

Jun 21 20:36:11 Tower kernel: 00000000000001d8 ffff880214e67988 ffffffff8104a32d ffffffff81272bd3

Jun 21 20:36:11 Tower kernel: ffff8802150d1000 ffff8802139096c0 ffff8802139096c0 0000000000000000

Jun 21 20:36:11 Tower kernel: Call Trace:

 

or here :

 

Jun 21 20:36:11 Tower kernel: ---[ end trace 4c31217c691c5138 ]---
Jun 21 20:36:11 Tower emhttp: shcmd: shcmd (33): exit status: -119
Jun 21 20:36:11 Tower emhttp: mount error: No file system (-119)
Jun 21 20:36:11 Tower emhttp: shcmd (34): umount /mnt/cache |& logger
Jun 21 20:36:11 Tower root: umount: /mnt/cache: not mounted
Jun 21 20:36:11 Tower emhttp: shcmd (35): rmdir /mnt/cache
Jun 21 20:36:11 Tower emhttp: shcmd (36): sync

 

full diagnostics attached.

tower-diagnostics-20160621-2050.zip

Link to comment

I upgraded a few days ago from 6.1.8

It happily rebooted after the upgrade.

No problems at all. Had all my dockers running again.

 

Today it was unresponsive, I could telnet in and tried to shutdown but it never went down.

When I manually shut it down it wouldn't boot up again. It comes back to the command line and I took a diagnostic, but it seems to have some problems with the cache disk.

I didn't open the server and physically change anything.

 

 

I am lost in the log files, any help would be greatly appreciated.

 

Jun 21 20:36:11 Tower kernel: XFS (sdd1): _xfs_buf_find: Block out of range: block 0x7fffffff8, EOFS 0xdf94b70

Jun 21 20:36:11 Tower kernel: ------------[ cut here ]------------

Jun 21 20:36:11 Tower kernel: WARNING: CPU: 0 PID: 12409 at fs/xfs/xfs_buf.c:472 _xfs_buf_find+0x7f/0x28c()

Jun 21 20:36:11 Tower kernel: Modules linked in: md_mod x86_pkg_temp_thermal coretemp kvm_intel ahci kvm libahci i2c_i801 e1000e ptp pps_core wmi

Jun 21 20:36:11 Tower kernel: CPU: 0 PID: 12409 Comm: mount Not tainted 4.4.13-unRAID #1

Jun 21 20:36:11 Tower kernel: Hardware name: ASUS All Series/H87I-PLUS, BIOS 2003 11/05/2014

Jun 21 20:36:11 Tower kernel: 0000000000000000 ffff880214e67950 ffffffff81369dde 0000000000000000

Jun 21 20:36:11 Tower kernel: 00000000000001d8 ffff880214e67988 ffffffff8104a32d ffffffff81272bd3

Jun 21 20:36:11 Tower kernel: ffff8802150d1000 ffff8802139096c0 ffff8802139096c0 0000000000000000

Jun 21 20:36:11 Tower kernel: Call Trace:

 

Well, the good news is your system is fine, except for corruption in the XFS file system on your Cache drive.  The bad news is that even XFS is not as mature as we would like, capable of crashing instead of detecting and handling the corruption.  It's rare at least, but all 3 of our file systems are capable of crashing due to corruption in a file system.

 

You can use the Check Disk File systems wiki page to attempt repairs, but since it's the Cache drive, you may wish to just reformat.  At the moment it can't be mounted, fails as soon as you try.  xfs_repair *may* be able to repair it enough to mount, and attempt recovery of files.  You will probably need some of the extra options, see the xfs_repair section.

Link to comment

A pretty trivial observation regarding the Dashboard page of the webGUI, but there doesn't seem to be much else to complain about in this release ;) The two rightmost columns in the Load Statistics pane are unbalanced in width, giving odd-numbered CPUs a much longer Per CPU Load scale than even-numbered ones. Also affected is the flash : log : docker percentage used display.

 

Looks like something wrong with your stylesheets. Have you tried to clear the browser's cache?

 

Picture as it should look like...

 

I have the same issue. Clearing cache does not help. I'm using Safari as browser.

 

The fan speeds are not reported when i check the webui. Do I have to install something?

Link to comment

A pretty trivial observation regarding the Dashboard page of the webGUI, but there doesn't seem to be much else to complain about in this release ;) The two rightmost columns in the Load Statistics pane are unbalanced in width, giving odd-numbered CPUs a much longer Per CPU Load scale than even-numbered ones. Also affected is the flash : log : docker percentage used display.

 

Looks like something wrong with your stylesheets. Have you tried to clear the browser's cache?

 

Picture as it should look like...

 

I have the same issue. Clearing cache does not help. I'm using Safari as browser.

 

The fan speeds are not reported when i check the webui. Do I have to install something?

 

There is nothing to install. Have you tried to update Safari or use another browser?

 

Link to comment

Load statistics are fine when using Chrome. So it's a Safari issue. I suspect that John M is also using Safari.

 

My second point regarding the fan RPM statics they not show up in the webui in my case.., any idea what's the problem?

Link to comment

Well, the good news is your system is fine, except for corruption in the XFS file system on your Cache drive.  The bad news is that even XFS is not as mature as we would like, capable of crashing instead of detecting and handling the corruption.  It's rare at least, but all 3 of our file systems are capable of crashing due to corruption in a file system.

 

You can use the Check Disk File systems wiki page to attempt repairs, but since it's the Cache drive, you may wish to just reformat.  At the moment it can't be mounted, fails as soon as you try.  xfs_repair *may* be able to repair it enough to mount, and attempt recovery of files.  You will probably need some of the extra options, see the xfs_repair section.

Thanks RobJ, so nothing to do with beta23.

I will attempt a Check Disk tonight or maybe use this as a good excuse to upgrade the cache disk  :)

Thanks!

Link to comment

I see that support for 'dual-device "swap/disable" function' was introduced in beta22. Has anyone tried this and worked out a procedure?

 

Procedure is the same as before, it only works with parity, not with parity2.

 

Edit to add: Only one disk can be disable, even with dual parity.

Link to comment

I see that support for 'dual-device "swap/disable" function' was introduced in beta22. Has anyone tried this and worked out a procedure?

 

Procedure is the same as before, it only works with parity, not with parity2.

 

Edit to add: Only one disk can be disable, even with dual parity.

 

OK. Thanks, johnnie. So it gets you out of the situation where you need to replace a failed data disk but the only spare you have is larger than your existing parity disk, but you would then probably want to do a normal replacement/rebuild of parity2 in order to bring it up to the same size.

Link to comment

Someone knows when final build of 6.2 will come online ?

Round about ?

We are not even into release candidate rounds, so a FINAL won't be any time Soon.

 

My estimate is 2017.

 

IMO because of the current development status, a RC should be in the corner within the next few days....

Link to comment

I am hoping that we get to final before the end of July.  I have a license of win7 pro that I want to upgrade to win10 for free.  I have been holding off as unraid 6.2 switched to ovmf and my current win7 VM is seabios.  I usually don't install betas.... but as the free upgrade date gets closer....maybe I'll change my mind.  Just trying to avoid activation issues with Microsoft.

Link to comment

 

I am hoping that we get to final before the end of July.  I have a license of win7 pro that I want to upgrade to win10 for free.  I have been holding off as unraid 6.2 switched to ovmf and my current win7 VM is seabios.  I usually don't install betas.... but as the free upgrade date gets closer....maybe I'll change my mind.  Just trying to avoid activation issues with Microsoft.

 

Never say never so I'll give you a less than 1% chance that 6.2 final will be out by the end of July.

Link to comment

I am hoping that we get to final before the end of July.  I have a license of win7 pro that I want to upgrade to win10 for free.  I have been holding off as unraid 6.2 switched to ovmf and my current win7 VM is seabios.  I usually don't install betas.... but as the free upgrade date gets closer....maybe I'll change my mind.  Just trying to avoid activation issues with Microsoft.

 

Considering we don't even have a RC out yet I'd say that's highly unlikely.

Link to comment

I'm having trouble getting the server into S3 (using the S3.sh script available in the forum). worked properly before, but it seems that after beta 23 the behavior is the parity disk seems to be spin down, although there's still temperature reading.

 

root@LITTLEMAMBA:~# hdparm -C /dev/sdb
/dev/sdb: drive state is:  active/idle
root@LITTLEMAMBA:~# hdparm -C /dev/sdc
/dev/sdc: drive state is:  standby

 

Can anyone please advise?

 

Cheers,

anthonws.

 

dashboard_disks_spin_down_parity_temperature_reading.PNG.1a4fac7dfcd244d95e7fa6f92a4b06f9.PNG

Link to comment
Guest
This topic is now closed to further replies.