unRAID Server Release 6.2.0-beta19 Available


Recommended Posts

I've had this issue on b18 + b19, I've also seen it mentioned a couple of times in each of the beta threads :)

 

The whole "waiting for /dev/disk/by-label/UNRAID (will check for 30 sec)..."

 

I'm running 6.1.9, tried updating via the plugin update and saw this! (attached screenshot)

That's what happened as soon as I tried to update the plugin

That suggests that the USB stick is not mounted at /boot as it should be!    Are you sure it has a label of 'UNRAID' (all in capitals) as the first messages you mention suggests it is not being found.

 

What happens if you login on the console and use the command

ls -l /boot
ls -l /boot/syslinux

These should show the files on the USB stick - I suspect they will not.  In particular the second one will not show the contents of the syslinux folder as the error message implies it is not there.

Link to comment
  • Replies 194
  • Created
  • Last Reply

Top Posters In This Topic

I've had this issue on b18 + b19, I've also seen it mentioned a couple of times in each of the beta threads :)

 

The whole "waiting for /dev/disk/by-label/UNRAID (will check for 30 sec)..."

 

I'm running 6.1.9, tried updating via the plugin update and saw this! (attached screenshot)

That's what happened as soon as I tried to update the plugin

That suggests that the USB stick is not mounted at /boot as it should be!    Are you sure it has a label of 'UNRAID' (all in capitals) as the first messages you mention suggests it is not being found.

 

What happens if you login on the console and use the command

ls -l /boot
ls -l /boot/syslinux

These should show the files on the USB stick - I suspect they will not.  In particular the second one will not show the contents of the syslinux folder as the error message implies it is not there.

 

Hi,

 

10000% sure that it's labelled UNRAID :)

Well this is fun lol - I've already reverted to my 6.1.9 backup and for some reason it started a parity check - So I'll leave it to get on with that, upgrade to b19 again and get the results of those commands - Pretty sure its' gonna return nothing at all (which makes very little sense to me... It boots so far into unRAID anyway... I can sign in as root to tower when I get past the waiting (but there's none of my settings, no web GUI access - Only SSH and local access))

Link to comment

Well this is fun lol - I've already reverted to my 6.1.9 backup and for some reason it started a parity check - So I'll leave it to get on with that, upgrade to b19 again and get the results of those commands - Pretty sure its' gonna return nothing at all (which makes very little sense to me... It boots so far into unRAID anyway... I can sign in as root to tower when I get past the waiting (but there's none of my settings, no web GUI access - Only SSH and local access))

The basic unRAID comes from the bzimage and bzroot files that are loaded at boot time and those can load even with the USB stick either mislabelled or in the wrong format and get you to the point of logging in on the console.  It is only at the later stage the USB stick is mounted as /boot to find all the users configurable information and to launch the web GUI.  The problem is going to be determining why this might be happening on your system as it seems the obvious candidates do not seem to apply in your case.

 

In terms of the parity check when you reverted to 6.1.9, did you make sure that it was taken with array stopped?  If not that would explain why the parity check was run as unRAID thinks an unclean shutdown was done.

Link to comment

Is there anything in particular I need to do to manually boot in GUI mode?

I selected GUI with the keyboard, then it trys to start UNRAID but it throws me back to the selection menu again.

I had the same issue in b18, but it works for me without having to do anything other than you described in b19.

Link to comment

Is there anything in particular I need to do to manually boot in GUI mode?

I selected GUI with the keyboard, then it trys to start UNRAID but it throws me back to the selection menu again.

You should not need to do anything else. 

 

It might be worth checking that there is a bzroot-gui file on the flash.  Some people have found that the upgrade was not copying it on so were having to add it manually from the ZIP download version of unRAID.

Link to comment

You should not need to do anything else. 

It might be worth checking that there is a bzroot-gui file on the flash.  Some people have found that the upgrade was not copying it on so were having to add it manually from the ZIP download version of unRAID.

 

When browsing the Flash drive in UNRAID I can see bzroot-gui (60MB), should I try overwriting it with a fresh one from the zip?

 

I am on Beta 19 (same thing happened on Beta 18)

 

It seem it tries to unpack then sends me back to the selection menu.

Link to comment

Nice! That was a great update for the disk spindown problem. And array is auto starting with "sleep 20" in go file.

 

All disks but one is working now, the last one is an old HP enterprise drive, probably not many using that one.

 

The dot next to disk is grey, but showing temp. If i check disk with  smartctl -i -n standby /dev/sdc I get power mode IDLE. If i force the disk to standby with hdparm -Y /dev/sdc the disk first goes to standby, but the i get error in log, and disk is same as before.

 

Mar 19 15:02:28 Tower kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6

Mar 19 15:02:28 Tower kernel: ata2.00: waking up from sleep

Mar 19 15:02:28 Tower kernel: ata2: hard resetting link

Mar 19 15:02:28 Tower kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 19 15:02:28 Tower kernel: ata2.00: failed to enable AA (error_mask=0x1)

Mar 19 15:02:28 Tower kernel: ata2.00: failed to enable AA (error_mask=0x1)

Mar 19 15:02:28 Tower kernel: ata2.00: configured for UDMA/133

Mar 19 15:02:28 Tower kernel: ata2: EH complete

 

Attaching diagnostics.

tower-diagnostics-20160319-1511.zip

Link to comment

Thanks for the great work on UnRaid. I especially love the new GUI.

 

I have an issue with Sonarr plugin/docker (I've tried both). I am sorry if this is wrong spot to post but problem only started after 6.2 beta updates.

 

The issue is that Sonarr can't access my TV share and gives : "Missing root folder: /mnt/user/Media/TV Shows" even though that share IS accessible. I've tried several different things to get Sonarr to see the share properly but no dice. Anyone have any ideas? I have linked my diagnostics incase that helps.

 

Thanks in advance.

 

https://onedrive.live.com/redir?resid=FBB84E2687FBC6A7!208927&authkey=!AGc0is7XdSVDUEk&ithint=file%2czip

 

EDIT: My apologies, I have sorted this issue by deleting my appdata for Sonarr and starting fresh. Thanks for looking everyone. Keep up the good work.

Link to comment

Nice! That was a great update for the disk spindown problem. And array is auto starting with "sleep 20" in go file.

 

All disks but one is working now, the last one is an old HP enterprise drive, probably not many using that one.

 

The dot next to disk is grey, but showing temp. If i check disk with  smartctl -i -n standby /dev/sdc I get power mode IDLE. If i force the disk to standby with hdparm -Y /dev/sdc the disk first goes to standby, but the i get error in log, and disk is same as before.

 

Mar 19 15:02:28 Tower kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6

Mar 19 15:02:28 Tower kernel: ata2.00: waking up from sleep

Mar 19 15:02:28 Tower kernel: ata2: hard resetting link

Mar 19 15:02:28 Tower kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 19 15:02:28 Tower kernel: ata2.00: failed to enable AA (error_mask=0x1)

Mar 19 15:02:28 Tower kernel: ata2.00: failed to enable AA (error_mask=0x1)

Mar 19 15:02:28 Tower kernel: ata2.00: configured for UDMA/133

Mar 19 15:02:28 Tower kernel: ata2: EH complete

 

Attaching diagnostics.

 

I STRONGLY recommend never using hdparm -Y, only use hdparm -y.  In my experience with older drives, the -Y option would put the drive into a sleep so deep it could only be awakened by powering off then on, a HUGE pain.  I don't know if that's still true with modern drives, but would have to be tested.  I've been too afraid to try since.  The hdparm -y command is all that unRAID uses.

Link to comment

You should not need to do anything else. 

It might be worth checking that there is a bzroot-gui file on the flash.  Some people have found that the upgrade was not copying it on so were having to add it manually from the ZIP download version of unRAID.

 

When browsing the Flash drive in UNRAID I can see bzroot-gui (60MB), should I try overwriting it with a fresh one from the zip?

 

I am on Beta 19 (same thing happened on Beta 18)

 

It seem it tries to unpack then sends me back to the selection menu.

It could not do any harm.  While you are at it overwrite the bzroot and bzimage files as well in case one of them is the problem.
Link to comment

When the number of "slots" in the array is set larger than the actual number of data disks present, it will bring the array online with those none-existing disks as empty in the corresponding array variable. This is different behaviour from previous versions, where the array variable would only hold any data disks actually present. Is this intended new behaviour?

 

Attached diagnostics to show the array with 10 actual data disks (1-10), and 4 empty ones (11-14).

vesta-diagnostics-20160319-1837.zip

Link to comment

When the number of "slots" in the array is set larger than the actual number of data disks present, it will bring the array online with those none-existing disks as empty in the corresponding array variable. This is different behaviour from previous versions, where the array variable would only hold any data disks actually present. Is this intended new behaviour?

 

Attached diagnostics to show the array with 10 actual data disks (1-10), and 4 empty ones (11-14).

How are skipped slots being handled? Maybe the behavior is changed to better cope with situations where there are empty slots between occupied slots.
Link to comment

When the number of "slots" in the array is set larger than the actual number of data disks present, it will bring the array online with those none-existing disks as empty in the corresponding array variable. This is different behaviour from previous versions, where the array variable would only hold any data disks actually present. Is this intended new behaviour?

 

Attached diagnostics to show the array with 10 actual data disks (1-10), and 4 empty ones (11-14).

How are skipped slots being handled? Maybe the behavior is changed to better cope with situations where there are empty slots between occupied slots.

 

Intermediate empty slots are still handled the same way as before, they are suppressed in the GUI eventhough present in the array. The difference is in the empty slots AFTER the last data disk.

 

Btw as an end-user you won't notice the difference, it is more applicable for those making plugins and reading the internal array variable.

 

 

Link to comment

I STRONGLY recommend never using hdparm -Y, only use hdparm -y.  In my experience with older drives, the -Y option would put the drive into a sleep so deep it could only be awakened by powering off then on, a HUGE pain.  I don't know if that's still true with modern drives, but would have to be tested.  I've been too afraid to try since.  The hdparm -y command is all that unRAID uses.

 

Ok, thanks for the heads up! With hdparm -y i get the drive to standby without the errors in the log, but the drive still doesn't stay in standby, gray dot in main tab, and still showing temperature. And smartctl shows the drive as idle.

Link to comment

I STRONGLY recommend never using hdparm -Y, only use hdparm -y.  In my experience with older drives, the -Y option would put the drive into a sleep so deep it could only be awakened by powering off then on, a HUGE pain.  I don't know if that's still true with modern drives, but would have to be tested.  I've been too afraid to try since.  The hdparm -y command is all that unRAID uses.

 

Ok, thanks for the heads up! With hdparm -y i get the drive to standby without the errors in the log, but the drive still doesn't stay in standby, gray dot in main tab, and still showing temperature. And smartctl shows the drive as idle.

 

Setting a disk manually in idle mode using hdparm, will not immediately update the GUI display. It depends on the setting of "Tunable (poll_attributes)" how soon/fast a disk status is scanned (default is 30 minutes).

 

Link to comment

 

Setting a disk manually in idle mode using hdparm, will not immediately update the GUI display. It depends on the setting of "Tunable (poll_attributes)" how soon/fast a disk status is scanned (default is 30 minutes).

 

Yes i know that, but the disk is not in standby when i check witcj smartctl, not just the webgui.

 

 

Link to comment

Just wanted to report that upgraded my four largest servers to v6.2 with dual parity, two were upgraded last week with b18 and just finished two more with b19, and all are working great!

 

I know this is beta and there are some risks, but in my view and after some testing on my test server, and at least for large servers, the risk is considerably less then running them with single parity.

 

Dual parity was by far my #1 missing feature on unRAID, good job LT  :D8)

Link to comment

Running 6.2 Beta 19 and everything seems to run great, apart from a few niggly issues

 

Cant get my array to auto-start on boot, even with a sleep 30 or 60 in the go file, Have also set the auto-start to no, rebooted, and set to yes and rebooted, no dice.

 

Found I could stop the WebUI forcing me to the licence/registration page on login by removing my Trial.key file from the /boot/config folder (My install is an upgraded trial to plus)

 

Also, Having trouble with net-booted OpenELEC instances as NFS appears to keep throwing a wobbly often:

[95422.731794] ------------[ cut here ]------------
[95422.731807] WARNING: CPU: 2 PID: 3080 at fs/nfsd/nfsproc.c:804 nfserrno+0x43/0x4a()
[95422.731808] nfsd: non-standard errno: -38
[95422.731809] Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net vhost macvtap macvlan tun xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod si2165 a8293 tda10071 tea5767 tuner cx23885 altera_ci tda18271 altera_stapl videobuf2_dvb mxm_wmi m88ds3103 i2c_mux snd_pcm snd_timer snd soundcore tveeprom cx2341x videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core dvb_core kvm_amd kvm regmap_i2c rc_core v4l2_common ftdi_sio videodev r8169 input_leds led_class mii usbserial k10temp media i2c_piix4 ahci libahci wmi acpi_cpufreq [last unloaded: md_mod]
[95422.731860] CPU: 2 PID: 3080 Comm: nfsd Tainted: G        W       4.4.5-unRAID #1
[95422.731862] Hardware name: Gigabyte Technology Co., Ltd. GA-990FXA-UD3/GA-990FXA-UD3, BIOS F9 10/22/2012
[95422.731864]  0000000000000000 ffff8804164a3cc8 ffffffff81368cfe ffff8804164a3d10
[95422.731868]  0000000000000324 ffff8804164a3d00 ffffffff8104a28a ffffffff811ef20d
[95422.731871]  ffff8800a3dd9008 ffff8803b3d37180 000000000000c000 ffff8800a3ddc958
[95422.731874] Call Trace:
[95422.731881]  [<ffffffff81368cfe>] dump_stack+0x61/0x7e
[95422.731886]  [<ffffffff8104a28a>] warn_slowpath_common+0x8f/0xa8
[95422.731889]  [<ffffffff811ef20d>] ? nfserrno+0x43/0x4a
[95422.731892]  [<ffffffff8104a2e6>] warn_slowpath_fmt+0x43/0x4b
[95422.731898]  [<ffffffff81228b0b>] ? create_new_entry.constprop.12+0x15d/0x177
[95422.731901]  [<ffffffff811ef20d>] nfserrno+0x43/0x4a
[95422.731904]  [<ffffffff811f2a9e>] nfsd_create+0x34a/0x375
[95422.731909]  [<ffffffff811f714a>] nfsd3_proc_mknod+0xe9/0x14c
[95422.731912]  [<ffffffff811edf07>] nfsd_dispatch+0x8d/0x145
[95422.731916]  [<ffffffff815fd046>] svc_process+0x3bb/0x632
[95422.731918]  [<ffffffff811edab1>] nfsd+0x102/0x154
[95422.731921]  [<ffffffff811ed9af>] ? nfsd_destroy+0x69/0x69
[95422.731924]  [<ffffffff8105f870>] kthread+0xcd/0xd5
[95422.731926]  [<ffffffff8105f7a3>] ? kthread_worker_fn+0x137/0x137
[95422.731929]  [<ffffffff8161d0bf>] ret_from_fork+0x3f/0x70
[95422.731931]  [<ffffffff8105f7a3>] ? kthread_worker_fn+0x137/0x137
[95422.731948] ---[ end trace 13bc6c268a331ec5 ]---

 

This error doesnt always happen. But i do receive alot of stale file handles on the OpenELEC machines, if they are running for any length of time (Watching something or not) they seem to get a stale file handle and stop working:

RyanHTPC:~ # ls -lah
ls: .: Stale file handle

 

Diagnostics attached

uss-enterprise-diagnostics-20160321-0021.zip

Link to comment
Known Issues 6.2 beta18

 

GPU Pass Through CPU Overhead

 

Some users are reporting an overly high amount of CPU usage when running Windows guest VMs with GPU pass through and opening applications that engage 3D graphics, video, or audio.  The usage doesn't appear to actually affect the performance of the guest, but the utilization reported on the host definitely doesn't appear to match the guest.

 

We are actively investigating this issue, but know that it shouldn't affect functionality of your system or usability, just how much your CPU reports to utilize on the host.

 

Still an active issue on my end.

The attached diagnostic was collected, while a video was running and the host showed 99% on all cores, that are attached to the vm.

Guest load was around 4-10% on any core...

 

Your wording makes it almost sound, as if you may suspecrt an issue with the "reported load".

According to my cpu-temps  (see chart) and powerusage measured on the wall, the Host-Load is accurate.

 

During the 10 minute playback, cpu-temp was at 50°C.

At around 5 minutes into the test, I startet a cpu stresstest. Guest CPU went to 90%+ but temp stayed at ~50°C.

50°C is around max, because I removed all overclocking and the cpu is watercooled.

 

And powerusage goes from ~100watts to ~150watts.

 

I'll stay on 6.2 for this week, if you need additional info or if I should try anything, feel free to ask.

Rolling back to 6.1 is a pita, because I am testing the nvme support for cache drives... Rolling back means a lot of files beeing moved.

unraid-diagnostics-20160320-1145.zip

chart.png.d1e7662ca515657e872a04979d7d1779.png

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