unRAID Server Release 6.0-rc6-x86_64 Available


Recommended Posts

Download

 

Clicking 'Check for Updates' on the Plugins page is the preferred way to upgrade.

 

Primary change here is to fix the 'docker containers dns failure' issue. Please read this post for vital information:

http://lime-technology.com/forum/index.php?topic=40584.msg383138#msg383138

 

Another significant change has to do with dhcp.  Now when dhcp is used to obtain an IP address the startup sequence will "pause" for up to 60 seconds, waiting for a lease to be obtained.  Normally this only takes a few seconds, but in the event no dhcp server is present, or no carrier on the ethernet port(s), e.g., cable  unplugged, dhcpcd will give up after 60 seconds and fork to background permitting startup sequence to resume.

 

Changes
=======

Version 6.0-rc6
---------------
- dhcpcd: update to 6.8.1
- dhcpcd: put dhcpcd in background if no carrier and/or no IP address after 60 seconds
- docker: trigger docker inotify watch on /etc/resolve.conf
- emhttp: fix cache devices getting unassigned when array slot count decreased
- slack: create informative /etc/issue file
- slack: maintain /etc/hostname file
- slack: added 'inet' command to /root - just a symlink to /etc/rc.d/rc.inet1
- webGui: Info page memory display corrections; other misc. changes
- webGui: other misc changes (see github)

 

Thanks to Eric who spent a considerable amount of time chasing down the docker issue, which we believe is really a docker bug.

Link to comment
  • Replies 195
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Am getting the following when stopping the array:

 

Jun 12 00:40:28 Tower kernel: mdcmd (313): stop 
Jun 12 00:40:28 Tower kernel: md1: stopping
Jun 12 00:40:28 Tower kernel: ------------[ cut here ]------------
Jun 12 00:40:28 Tower kernel: WARNING: CPU: 1 PID: 11312 at mm/backing-dev.c:372 bdi_unregister+0x28/0x3a()
Jun 12 00:40:28 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables tun veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat w83627ehf md_mod ipmi_devintf nct6775 hwmon_vid coretemp e1000e mvsas ptp libsas ahci i2c_i801 libahci scsi_transport_sas pps_core ipmi_si [last unloaded: kvm]
Jun 12 00:40:28 Tower kernel: CPU: 1 PID: 11312 Comm: emhttp Not tainted 4.0.4-unRAID #4
Jun 12 00:40:28 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.2 02/20/2015
Jun 12 00:40:28 Tower kernel: 0000000000000009 ffff8800c930fbd8 ffffffff815ff789 0000000000000000
Jun 12 00:40:28 Tower kernel: 0000000000000000 ffff8800c930fc18 ffffffff810443a3 0000000000000000
Jun 12 00:40:28 Tower kernel: ffffffff810c0fe5 ffff8800c901b000 0000000000000000 ffff8800c901b000
Jun 12 00:40:28 Tower kernel: Call Trace:
Jun 12 00:40:28 Tower kernel: [] dump_stack+0x4c/0x6e
Jun 12 00:40:28 Tower kernel: [] warn_slowpath_common+0x97/0xb1
Jun 12 00:40:28 Tower kernel: [] ? bdi_unregister+0x28/0x3a
Jun 12 00:40:28 Tower kernel: [] warn_slowpath_null+0x15/0x17
Jun 12 00:40:28 Tower kernel: [] bdi_unregister+0x28/0x3a
Jun 12 00:40:28 Tower kernel: [] del_gendisk+0xf0/0x1b5
Jun 12 00:40:28 Tower kernel: [] do_stop+0x6b/0xd7 [md_mod]
Jun 12 00:40:28 Tower kernel: [] stop_array.constprop.21+0x85/0xad [md_mod]
Jun 12 00:40:28 Tower kernel: [] md_proc_write+0x11a2/0x153c [md_mod]
Jun 12 00:40:28 Tower kernel: [] ? mntput+0x28/0x2a
Jun 12 00:40:28 Tower kernel: [] ? path_put+0x1a/0x1e
Jun 12 00:40:28 Tower kernel: [] ? path_cleanup+0x20/0x3b
Jun 12 00:40:28 Tower kernel: [] ? path_openat+0x31a/0x514
Jun 12 00:40:28 Tower kernel: [] ? handle_mm_fault+0x104f/0x114b
Jun 12 00:40:28 Tower kernel: [] ? do_filp_open+0x35/0x85
Jun 12 00:40:28 Tower kernel: [] ? __sb_start_write+0x99/0xcd
Jun 12 00:40:28 Tower kernel: [] proc_reg_write+0x47/0x69
Jun 12 00:40:28 Tower kernel: [] vfs_write+0xb7/0x18f
Jun 12 00:40:28 Tower kernel: [] SyS_write+0x42/0x86
Jun 12 00:40:28 Tower kernel: [] system_call_fastpath+0x12/0x17
Jun 12 00:40:28 Tower kernel: ---[ end trace 28cce51c68bf412c ]---
Jun 12 00:40:28 Tower kernel: md2: stopping
Jun 12 00:40:28 Tower kernel: md3: stopping
Jun 12 00:40:28 Tower kernel: md4: stopping

 

it continues stopping, i an shutdown/reboot just fine - it comes back up just fine - but getting their weird error

 

Myk

Link to comment

Am getting the following when stopping the array:

 

Jun 12 00:40:28 Tower kernel: mdcmd (313): stop 
Jun 12 00:40:28 Tower kernel: md1: stopping
Jun 12 00:40:28 Tower kernel: ------------[ cut here ]------------
Jun 12 00:40:28 Tower kernel: WARNING: CPU: 1 PID: 11312 at mm/backing-dev.c:372 bdi_unregister+0x28/0x3a()
Jun 12 00:40:28 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables tun veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat w83627ehf md_mod ipmi_devintf nct6775 hwmon_vid coretemp e1000e mvsas ptp libsas ahci i2c_i801 libahci scsi_transport_sas pps_core ipmi_si [last unloaded: kvm]
Jun 12 00:40:28 Tower kernel: CPU: 1 PID: 11312 Comm: emhttp Not tainted 4.0.4-unRAID #4
Jun 12 00:40:28 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.2 02/20/2015
Jun 12 00:40:28 Tower kernel: 0000000000000009 ffff8800c930fbd8 ffffffff815ff789 0000000000000000
Jun 12 00:40:28 Tower kernel: 0000000000000000 ffff8800c930fc18 ffffffff810443a3 0000000000000000
Jun 12 00:40:28 Tower kernel: ffffffff810c0fe5 ffff8800c901b000 0000000000000000 ffff8800c901b000
Jun 12 00:40:28 Tower kernel: Call Trace:
Jun 12 00:40:28 Tower kernel: [] dump_stack+0x4c/0x6e
Jun 12 00:40:28 Tower kernel: [] warn_slowpath_common+0x97/0xb1
Jun 12 00:40:28 Tower kernel: [] ? bdi_unregister+0x28/0x3a
Jun 12 00:40:28 Tower kernel: [] warn_slowpath_null+0x15/0x17
Jun 12 00:40:28 Tower kernel: [] bdi_unregister+0x28/0x3a
Jun 12 00:40:28 Tower kernel: [] del_gendisk+0xf0/0x1b5
Jun 12 00:40:28 Tower kernel: [] do_stop+0x6b/0xd7 [md_mod]
Jun 12 00:40:28 Tower kernel: [] stop_array.constprop.21+0x85/0xad [md_mod]
Jun 12 00:40:28 Tower kernel: [] md_proc_write+0x11a2/0x153c [md_mod]
Jun 12 00:40:28 Tower kernel: [] ? mntput+0x28/0x2a
Jun 12 00:40:28 Tower kernel: [] ? path_put+0x1a/0x1e
Jun 12 00:40:28 Tower kernel: [] ? path_cleanup+0x20/0x3b
Jun 12 00:40:28 Tower kernel: [] ? path_openat+0x31a/0x514
Jun 12 00:40:28 Tower kernel: [] ? handle_mm_fault+0x104f/0x114b
Jun 12 00:40:28 Tower kernel: [] ? do_filp_open+0x35/0x85
Jun 12 00:40:28 Tower kernel: [] ? __sb_start_write+0x99/0xcd
Jun 12 00:40:28 Tower kernel: [] proc_reg_write+0x47/0x69
Jun 12 00:40:28 Tower kernel: [] vfs_write+0xb7/0x18f
Jun 12 00:40:28 Tower kernel: [] SyS_write+0x42/0x86
Jun 12 00:40:28 Tower kernel: [] system_call_fastpath+0x12/0x17
Jun 12 00:40:28 Tower kernel: ---[ end trace 28cce51c68bf412c ]---
Jun 12 00:40:28 Tower kernel: md2: stopping
Jun 12 00:40:28 Tower kernel: md3: stopping
Jun 12 00:40:28 Tower kernel: md4: stopping

 

it continues stopping, i an shutdown/reboot just fine - it comes back up just fine - but getting their weird error

 

Myk

 

Please post complete syslog or email to me: [email protected] - nothing changed in that area - strange.

 

Edit: nevermind, it's harmless, see a couple posts below.

Link to comment

... Another significant change has to do with dhcp.  Now when dhcp is used to obtain an IP address the startup sequence will "pause" for up to 60 seconds, waiting for a lease to be obtained.  Normally this only takes a few seconds, but in the event no dhcp server is present, or no carrier on the ethernet port(s), e.g., cable  unplugged, dhcpcd will give up after 60 seconds and fork to background permitting startup sequence to resume.

 

Is this really the behavior you want?    It seems that if you can't get an IP, you can't access the server ... at least not from a web client  => and many folks run their server's headless.

 

Not sure what's "better" => but it seems continuing to startup and running without network access makes it very likely the user will just power it off and result in an "unclean" shutdown.  I assume a single push of the power switch (NOT holding it) will still do a "clean" shutdown ... but I know quite a few folks who either hold the power button; or simply kill the power via the toggle switch or UPS, either of which would be "unclean."

 

Perhaps there could be a "fallback" static IP that's automatically used in this case [something generally "out of the way" ... e.g. 192.168.77.222] which should at least allow access as long as it's well publicized that this is what it does.

 

My preference would be to send a console message that says "No DHCP server available ... no network access to UnRAID.  Continue Booting?"  and default to NO after perhaps 30 seconds => simply shutting down.    At least those with a console could see that and choose to boot if they wanted.

 

 

Link to comment

Gary it's no different than it is now, other than it will now just sit there for up to 60 sec before proceeding, instead of proceeding immediately.  If/when after 60 sec you remember, "hey I forgot to plug in my cable", you can go plug it in and dhcp will get the IP address because it's in the background.

Link to comment

Gary it's no different than it is now, other than it will now just sit there for up to 60 sec before proceeding, instead of proceeding immediately.  If/when after 60 sec you remember, "hey I forgot to plug in my cable", you can go plug it in and dhcp will get the IP address because it's in the background.

 

I guess I thought "... Another significant change has to do with dhcp ..." meant it was notably different, but all you're doing is introducing a 60 second wait time -- right?    I've never attempted a boot w/out a network connection, so have never experienced that, but it does beg the question of whether the consequences I noted are in fact correct.    Does the power button do a "clean" shutdown in the event the system has booted up and still doesn't have a connection?

 

Link to comment

By the way, between notes I just did the upgrade => second time I've now done it directly from the GUI with the "Update" button.    That is SO much nicer than the downloading/extracting/copying to the flash drive process => and certainly a lot more "user friendly" for typical users.

 

Booted up just fine ... now running a parity check just to confirm nothing's changed [my test system gets checked every time you release a new build  :) ].

 

Link to comment

Just upgraded, from what I can see so far it hasn't fixed my Docker issues. NZBGet running bridge mode can't resolve anything.

 

Also if  your container was created in -beta14 or earlier you need to recreate it because of a change in docker 1.5.0 which introduced in -beta15.

Link to comment

Just upgraded, from what I can see so far it hasn't fixed my Docker issues. NZBGet running bridge mode can't resolve anything.

 

Also if  your container was created in -beta14 or earlier you need to recreate it because of a change in docker 1.5.0 which introduced in -beta15.

 

I only came back to unRaid recently, since the RC releases. I have no idea how to check what you asked but hopefully I can figure it out. I'll reboot shortly and see if it happens again then see what I can find.

Link to comment

Sickbeard hasn't connected, can't resolve github.

 

Linux 4.0.4-unRAID.
root@Unraid-Nas:~# cat /etc/resolv.conf
# Generated by dhcpcd from br0.dhcp
# /etc/resolv.conf.head can replace this line
domain sparklyballs.home
nameserver 192.168.1.30
# /etc/resolv.conf.tail can replace this line
#root@Unraid-Nas:~# cat /etc/hosts
# Generated
127.0.0.1	Unraid-Nas localhost
root@Unraid-Nas:~# hostname
Unraid-Nas
root@Unraid-Nas:~#

 

root@Unraid-Nas:~# docker exec Sickbeard cat /etc/resolv.conf
# Generated by dhcpcd from br0.dhcp
# /etc/resolv.conf.head can replace this line
domain sparklyballs.home
nameserver 192.168.1.30
# /etc/resolv.conf.tail can replace this line
#root@Unraid-Nas:~# docker exec Sickbeard cat /etc/hosts
172.17.0.8	e31d2a46e691
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
root@Unraid-Nas:~# docker exec Sickbeard cat /etc/hostname
e31d2a46e691

Link to comment

Headphones also not connecting

 

root@Unraid-Nas:~# docker exec Headphones cat /etc/resolv.conf
# Generated by dhcpcd from br0.dhcp
# /etc/resolv.conf.head can replace this line
domain sparklyballs.home
nameserver 192.168.1.30
# /etc/resolv.conf.tail can replace this line
#root@Unraid-Nas:~#docker exec Headphones cat /etc/hosts
172.17.0.7	f3791798de84
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
root@Unraid-Nas:~# docker exec Headphones cat /etc/hostname
f3791798de84

Link to comment

Can you ping your name server from within the container?

 

docker exec Sickbeard ping 192.168.1.30

 

how about pinging google?

 

docker exec Sickbeard ping google.com

 

root@Unraid-Nas:~# docker exec Sickbeard ping -c 3 192.168.1.30
PING 192.168.1.30 (192.168.1.30) 56(84) bytes of data.
64 bytes from 192.168.1.30: icmp_seq=1 ttl=63 time=0.337 ms
64 bytes from 192.168.1.30: icmp_seq=2 ttl=63 time=0.438 ms
64 bytes from 192.168.1.30: icmp_seq=3 ttl=63 time=0.475 ms

--- 192.168.1.30 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.337/0.416/0.475/0.062 ms

Link to comment
root@Unraid-Nas:~# docker exec Sickbeard ping -c 3 google.com
PING google.com (173.194.44.4) 56(84) bytes of data.
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=1 ttl=45 time=30.9 ms
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=2 ttl=45 time=31.0 ms
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=3 ttl=45 time=31.5 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 30.986/31.195/31.598/0.350 ms

Link to comment

Just rebooted. Any docker running in bridge mode seems to be stuffed.

 

root@DAMONSTER:~# docker exec binhex-nzbget ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=0.173 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=0.185 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=0.222 ms
^Croot@DAMONSTER:~# docker exec binhex-nzbget ping google.com
PING google.com (216.58.220.110) 56(84) bytes of data.
64 bytes from syd10s01-in-f110.1e100.net (216.58.220.110): icmp_seq=1 ttl=57 tim                                                                                                                                                             e=21.0 ms
64 bytes from syd10s01-in-f110.1e100.net (216.58.220.110): icmp_seq=2 ttl=57 tim                                                                                                                                                             e=20.9 ms
64 bytes from syd10s01-in-f110.1e100.net (216.58.220.110): icmp_seq=3 ttl=57 tim                                                                                                                                                             e=20.9 ms
64 bytes from syd10s01-in-f110.1e100.net (216.58.220.110): icmp_seq=4 ttl=57 tim                                                                                                                                                             e=20.8 ms
root@DAMONSTER:~#

Link to comment

root@Unraid-Nas:~# docker exec Sickbeard ping -c 3 google.com
PING google.com (173.194.44.4) 56(84) bytes of data.
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=1 ttl=45 time=30.9 ms
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=2 ttl=45 time=31.0 ms
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=3 ttl=45 time=31.5 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 30.986/31.195/31.598/0.350 ms

 

 

ip6 address ????

Link to comment

root@Unraid-Nas:~# docker exec Sickbeard ping -c 3 google.com
PING google.com (173.194.44.4) 56(84) bytes of data.
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=1 ttl=45 time=30.9 ms
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=2 ttl=45 time=31.0 ms
64 bytes from muc03s07-in-f4.1e100.net (173.194.44.4): icmp_seq=3 ttl=45 time=31.5 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 30.986/31.195/31.598/0.350 ms

 

This proves dns is working right?  stumped

Link to comment

 

Also if  your container was created in -beta14 or earlier you need to recreate it because of a change in docker 1.5.0 which introduced in -beta15.

 

Can you clarify what you mean by this?  I assume we need to explicitly delete the container and recreate it from the image and template?  Should we delete the image and re-download that as well?

Link to comment

 

Also if  your container was created in -beta14 or earlier you need to recreate it because of a change in docker 1.5.0 which introduced in -beta15.

 

Can you clarify what you mean by this?  I assume we need to explicitly delete the container and recreate it from the image and template?  Should we delete the image and re-download that as well?

 

You shouldn't have to delete the entire image, just the container.  This can be achieved by stopping container, go to edit page, and just click 'save' - any user data INSIDE the container will be lost of course - but I think all unraid specific containers are set up to map 'appdata' outside the container.

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