February 21, 201511 yr Found an oddity with this update in regards to webui, dockers in particular. details here. http://lime-technology.com/forum/index.php?topic=38301.0
February 21, 201511 yr Well right now the gui is recreating my docker img file. It is 50gigs and seems to be taking its time. If you require any more info let me know. Well so long as your system didn't crash, that's a good sign! Keep us posted. Well, it looks like the process is hung up as it shouldn't take this long to create a 50gb file on a ssd. root 8937 0.0 0.0 9336 2212 ? S 07:27 0:00 sh -c cd /usr/local/emhttp; /usr/bin/php /usr/local/src/wrap_post.php update.php '' '%23file=%2Fboot%2Fconfig%2Fdocker.cfg&%23command=%2Fetc%2Frc.d%2Frc.docker+start&DOCKER_ENABLED=yes&DOCKER_IMAGE_SIZE=50&DOCKER_IMAGE_FILE=%2Fmnt%2Fcache%2Fdocker%2Fdocker.img' root 8938 0.0 0.1 120684 16420 ? S 07:27 0:00 /usr/bin/php /usr/local/src/wrap_post.php update.php %23file=%2Fboot%2Fconfig%2Fdocker.cfg&%23command=%2Fetc%2Frc.d%2Frc.docker+start&DOCKER_ENABLED=yes&DOCKER_IMAGE_SIZE=50&DOCKER_IMAGE_FILE=%2Fmnt%2Fcache%2Fdocker%2Fdocker.img root 8939 0.0 0.0 9436 2476 ? S 07:27 0:00 /bin/sh /etc/rc.d/rc.docker start root 8943 0.0 0.0 8640 768 ? D 07:27 0:00 touch /mnt/cache/docker/docker.img Please post a full syslog in a defect report so we can troubleshoot.
February 21, 201511 yr Well right now the gui is recreating my docker img file. It is 50gigs and seems to be taking its time. If you require any more info let me know. Well so long as your system didn't crash, that's a good sign! Keep us posted. Well, it looks like the process is hung up as it shouldn't take this long to create a 50gb file on a ssd. root 8937 0.0 0.0 9336 2212 ? S 07:27 0:00 sh -c cd /usr/local/emhttp; /usr/bin/php /usr/local/src/wrap_post.php update.php '' '%23file=%2Fboot%2Fconfig%2Fdocker.cfg&%23command=%2Fetc%2Frc.d%2Frc.docker+start&DOCKER_ENABLED=yes&DOCKER_IMAGE_SIZE=50&DOCKER_IMAGE_FILE=%2Fmnt%2Fcache%2Fdocker%2Fdocker.img' root 8938 0.0 0.1 120684 16420 ? S 07:27 0:00 /usr/bin/php /usr/local/src/wrap_post.php update.php %23file=%2Fboot%2Fconfig%2Fdocker.cfg&%23command=%2Fetc%2Frc.d%2Frc.docker+start&DOCKER_ENABLED=yes&DOCKER_IMAGE_SIZE=50&DOCKER_IMAGE_FILE=%2Fmnt%2Fcache%2Fdocker%2Fdocker.img root 8939 0.0 0.0 9436 2476 ? S 07:27 0:00 /bin/sh /etc/rc.d/rc.docker start root 8943 0.0 0.0 8640 768 ? D 07:27 0:00 touch /mnt/cache/docker/docker.img Please post a full syslog in a defect report so we can troubleshoot. Sorry, rebooted the machine. Everything seems to be in order now.
February 21, 201511 yr The one other feature we wanted to get in is block-level encryption. That may have to wait for 6.1. Please put this on the roadmap for 6.1 or later. I realize it's an important feature, but adding this now is only going to delay the release further. unRAID Server Release 6.0-beta1-x86_64 was released on January 22, 2014. - emhttp: change term "Unformatted" to "Unmountable" With this change, how close is it to the roadmap item Modify handling of "Unformatted" status where you protect the customer's data from an accidental format. I.E. Modify handling of "Unformatted" status http://lime-technology.com/forum/index.php?topic=34766.0 In addition we have the user share copy bug which recently claimed another victim. (Which doesn't appear on the Roadmap anywhere).
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. syslog_beta_14.zip
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. How many drives do you have (and what are they being used for)? I wonder if there is a bug around the maximum number of drives supported (you seem to be at the limit of 25 as far as I can see), or alternatively beta 12 was not enforcing a limit and beta 14 is?
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. Hmm, this is an odd one. I found this line in your logs: Feb 22 06:38:19 Tower emhttp: too many devices to add ../../devices/pci0000:00/0000:00:1c.0/0000:03:00.0/host7/port-7:4/end_device-7:4/target7:0:4/7:0:4:0/block/sdz And you have 25 total disks in your system, right? Just wanted to confirm. Will need to have Tom investigate why this error is occurring.
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. How many drives do you have (and what are they being used for)? I wonder if there is a bug around the maximum number of drives supported, or alternatively beta 12 was not enforcing a limit and beta 14 is? 25 drives total. Parity + 23 data + cache.
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. Hmm, this is an odd one. I found this line in your logs: Feb 22 06:38:19 Tower emhttp: too many devices to add ../../devices/pci0000:00/0000:00:1c.0/0000:03:00.0/host7/port-7:4/end_device-7:4/target7:0:4/7:0:4:0/block/sdz And you have 25 total disks in your system, right? Just wanted to confirm. Will need to have Tom investigate why this error is occurring. Yes 25 drives total. Parity + 23 data + cache. That line is about the only thing that stands out for me.
February 21, 201511 yr How many drives do you have (and what are they being used for)? I wonder if there i a bug around the maximum number of drives supported, or alternatively beta 12 was not enforcing a limit and beta 14 is? 25 drives total. Parity + 23 data + cache. Since that is the absolute maximum allowed it makes one suspect that a bug has been introduced when one gets to the upper limit of the license. I am guessing, but it seems likely to me that there have been underlying changes in this area as part of introducing the new Trial/Basic licenses and I wonder if this upset some logic around the Pro license.
February 21, 201511 yr How many drives do you have (and what are they being used for)? I wonder if there i a bug around the maximum number of drives supported, or alternatively beta 12 was not enforcing a limit and beta 14 is? 25 drives total. Parity + 23 data + cache. Since that is the absolute maximum allowed it makes one suspect that a bug has been introduced when one gets to the upper limit of the license. I am guessing, but it seems likely to me that there have been underlying changes in this area as part of introducing the new Trial/Basic licenses and I wonder if this upset some logic around the Pro license. The Trial/Basic changes shouldn't impact anything with Pro, but clearly there is a bug that is making emhttp think there are too many devices present. We'll get it figured out.
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. Hmm, this is an odd one. I found this line in your logs: Feb 22 06:38:19 Tower emhttp: too many devices to add ../../devices/pci0000:00/0000:00:1c.0/0000:03:00.0/host7/port-7:4/end_device-7:4/target7:0:4/7:0:4:0/block/sdz And you have 25 total disks in your system, right? Just wanted to confirm. Will need to have Tom investigate why this error is occurring. Yes 25 drives total. Parity + 23 data + cache. That line is about the only thing that stands out for me. 26 drives.....Parity + 23 data + cache + USB thumbdrive
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. Hmm, this is an odd one. I found this line in your logs: Feb 22 06:38:19 Tower emhttp: too many devices to add ../../devices/pci0000:00/0000:00:1c.0/0000:03:00.0/host7/port-7:4/end_device-7:4/target7:0:4/7:0:4:0/block/sdz And you have 25 total disks in your system, right? Just wanted to confirm. Will need to have Tom investigate why this error is occurring. Yes 25 drives total. Parity + 23 data + cache. That line is about the only thing that stands out for me. 26 drives.....Parity + 23 data + cache + USB thumbdrive Quite true. 26 drives but only 25 disks.
February 21, 201511 yr Since we are telling everyone to recreate their docker image we really should provide a procedure how to do so in the least amount of steps whilst preserving container settings etc. Is this as simple as "updating" the docker, or do we need to delete the current image, then re-install it fresh?
February 21, 201511 yr Upgrade went perfect for me (from b13 to b14). And as a note, if you do have a UPS make sure that you enable the daemon. Otherwise your syslog will get filled with line after line of USB reconnection messages. (First noticed this with b13)
February 21, 201511 yr After upgrade to beta 14 from beta 12 I'm getting a missing disk after every reboot. The same thing happened with beta 13. The syslog seems (it's all Swahili to me) to indicate that when booting the max disk limit is getting reached before the last disk is mounted. If I move the original missing disk to a different SATA port then that disk will be found and a different disk will be missing (disks detected in different sequence/order?). Changing back to beta 12 brings the missing disk back immediately. Syslog attached. Hmm, this is an odd one. I found this line in your logs: Feb 22 06:38:19 Tower emhttp: too many devices to add ../../devices/pci0000:00/0000:00:1c.0/0000:03:00.0/host7/port-7:4/end_device-7:4/target7:0:4/7:0:4:0/block/sdz And you have 25 total disks in your system, right? Just wanted to confirm. Will need to have Tom investigate why this error is occurring. Yes 25 drives total. Parity + 23 data + cache. That line is about the only thing that stands out for me. 26 drives.....Parity + 23 data + cache + USB thumbdrive I was just going to chime in about that, as usb drives are also exposed via the /dev/sd# nomenclature.
February 21, 201511 yr Just updated to this and with Jonp's help it is running sweet as a nut. Need to do this COW bug fix but not planning on filling my SSD any time soon.
February 21, 201511 yr Just reporting this issue, have not seen it before. I am going to move my image to another ssd (xfs) outside of the array anyway. Brought up the system on beta14, deleted my current docker.img using the new 'delete image' feature in the gui (on a brrfs pool - cache drive). I then attempted to recreate it from the gui and it just hangs on the docker screen. I checked syslog and saw this: Feb 21 14:30:58 Iron php: Creating new image file for Docker: /mnt/cache/docker/docker.img size: 32G Feb 21 14:30:59 Iron php: Btrfs v3.18.2#012See http://btrfs.wiki.kernel.org for more information.#012#012Turning ON incompat feature 'extref': increased hardlink limit per file to 65536#012Turning ON incompat feature 'skinny-metadata': reduced-size metadata extent refs#012fs created label (null) on /mnt/cache/docker/docker.img#012#011nodesize 16384 leafsize 16384 sectorsize 4096 size 32.00GiB Feb 21 14:30:59 Iron kernel: BTRFS: device fsid 4cff6c9a-f60b-4ea8-8507-8c21376ef7b5 devid 1 transid 4 /dev/loop2 Feb 21 14:30:59 Iron kernel: BTRFS info (device loop2): disk space caching is enabled Feb 21 14:30:59 Iron kernel: BTRFS: has skinny extents Feb 21 14:30:59 Iron kernel: BTRFS: flagging fs with big metadata feature Feb 21 14:30:59 Iron kernel: BTRFS: creating UUID tree Feb 21 14:30:59 Iron php: Resize '/var/lib/docker' of 'max' Feb 21 14:30:59 Iron php: starting docker ... Feb 21 14:30:59 Iron kernel: BTRFS: new size for /dev/loop2 is 34359738368 Feb 21 14:30:59 Iron kernel: ip_tables: © 2000-2006 Netfilter Core Team Docker did not come alive in the GUI. I am going to remove it and try again on an XFS SSD outside of the array.
February 21, 201511 yr just updated to Beta14 through the GUI. I now have no Dockers running, nor the docker service. The attached image is not clear, when i go into Docker settings, enable docker is set to no syslog_2.zip
February 21, 201511 yr just updated to Beta14 through the GUI. I now have no Dockers running, nor the docker service. The attached image is not clear, when i go into Docker settings, enable docker is set to no Look on your flash drive /config/plugins/dockerMan and see if there are any *.gz files. Delete them and reboot. Its a remnant of old versions of docker manager and messes up b13 / b14
February 21, 201511 yr already checked, no *.gz files laying about setting enable docker to Yes and clicking apply does nothing. thought ok, i'll see if it lets me delete the docker.img file, that worked a treat lol still unable to set enable to yes and start docker Checked with IE11 & Chrome in Windows, Cleared browser cache Checked on Nexus 7 for good measure as well
February 21, 201511 yr It is possible the Flash drive has some corruption and is being set to read-only so that changes do not get saved. Posting a syslog would allow us to confirm if that is the case. Alternatively put the USB drive into a windows PC and see if offers to repair the file system - if so say yes.
Archived
This topic is now archived and is closed to further replies.