limetech Posted June 12, 2015 Share Posted June 12, 2015 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
MyKroFt Posted June 12, 2015 Share Posted June 12, 2015 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
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 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
garycase Posted June 12, 2015 Share Posted June 12, 2015 ... 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
PeterB Posted June 12, 2015 Share Posted June 12, 2015 Am getting the following when stopping the array: ... I am getting the same error in my logfile, Looking back at previous logs, it was also occuring in rc4. syslog.zip Link to comment
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 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
garycase Posted June 12, 2015 Share Posted June 12, 2015 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
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 Am getting the following when stopping the array: ... I am getting the same error in my logfile, Looking back at previous logs, it was also occuring in rc4. It's harmless and a patch is in 4.0.5 kernel (we're still on 4.0.4): https://bugzilla.kernel.org/show_bug.cgi?id=99271 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aad653a Link to comment
garycase Posted June 12, 2015 Share Posted June 12, 2015 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
Dimtar Posted June 12, 2015 Share Posted June 12, 2015 Just upgraded, from what I can see so far it hasn't fixed my Docker issues. NZBGet running bridge mode can't resolve anything. Link to comment
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 Just upgraded, from what I can see so far it hasn't fixed my Docker issues. NZBGet running bridge mode can't resolve anything. Does /etc/resolv.conf in the container match /etc/resolv.conf of the server? Link to comment
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 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
Dimtar Posted June 12, 2015 Share Posted June 12, 2015 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
sparklyballs Posted June 12, 2015 Share Posted June 12, 2015 give me about 2 or 3 minutes and i'll let you know what's happening regarding dns issues when my server has rebooted. Link to comment
sparklyballs Posted June 12, 2015 Share Posted June 12, 2015 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
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 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 Link to comment
sparklyballs Posted June 12, 2015 Share Posted June 12, 2015 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
sparklyballs Posted June 12, 2015 Share Posted June 12, 2015 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
sparklyballs Posted June 12, 2015 Share Posted June 12, 2015 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
Dimtar Posted June 12, 2015 Share Posted June 12, 2015 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
sparklyballs Posted June 12, 2015 Share Posted June 12, 2015 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
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 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
jimbobulator Posted June 12, 2015 Share Posted June 12, 2015 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
limetech Posted June 12, 2015 Author Share Posted June 12, 2015 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
Recommended Posts
Archived
This topic is now archived and is closed to further replies.