February 20, 201511 yr Hi Guys, I upgraded to B13 and my docker was working earlier today. I powered down my server to perform some other "fun" work and got everything back up but now docker will not start. I see nothing in syslog to indicate problems. my docker.img file sits on a cache drive formatted BTFRS. I've read a little through the thread and saw most were issues with unformatted cache drive. My cache drive appears to be working fine. Any ideas on how to diagnose and possibly fix this? Thanks, Mike Try deleting the .gz files in /boot/config/plugins/dockerMan/ and then rebooting. (Assuming of course that your cache drive is NOT showing unformatted)
February 20, 201511 yr Sorry if this isnt a constructive post but I'd just like to quickly say thanks to Tom & Jon for all their hard work. It's a small team delivering a big product and I just don't think they deserve the criticism at all. As stated, this is a beta and should be treated as such. LT normally has amazingly stable beta's and they shouldn't be abused for a slip in an unfinished product. Keep up the good work guys.
February 20, 201511 yr Hi Guys, I upgraded to B13 and my docker was working earlier today. I powered down my server to perform some other "fun" work and got everything back up but now docker will not start. I see nothing in syslog to indicate problems. my docker.img file sits on a cache drive formatted BTFRS. I've read a little through the thread and saw most were issues with unformatted cache drive. My cache drive appears to be working fine. Any ideas on how to diagnose and possibly fix this? Thanks, Mike Try deleting the .gz files in /boot/config/plugins/dockerMan/ and then rebooting. (Assuming of course that your cache drive is NOT showing unformatted) Very strange, but that did the trick. Thanks again to Squid!!
February 20, 201511 yr Very strange, but that did the trick. Thanks again to Squid!! It's remnants of an old version of DockerManager sitting around on the flash drive
February 20, 201511 yr As a followup I was able to resolve the 'unformatted' problem of my second cache drive with a program called Test disk after reverting back to beta12. http://www.cgsecurity.org/wiki/TestDisk It detected the partition and let me repair the partition table by setting the partition to the proper type. I haven't noticed any data loss yet, so I think it's good.
February 20, 201511 yr As a followup I was able to resolve the 'unformatted' problem of my second cache drive with a program called Test disk after reverting back to beta12. http://www.cgsecurity.org/wiki/TestDisk It detected the partition and let me repair the partition table by setting the partition to the proper type. I haven't noticed any data loss yet, so I think it's good. Thanks for the info! I was able to do the same thing!
February 20, 201511 yr As a followup I was able to resolve the 'unformatted' problem of my second cache drive with a program called Test disk after reverting back to beta12. http://www.cgsecurity.org/wiki/TestDisk It detected the partition and let me repair the partition table by setting the partition to the proper type. I haven't noticed any data loss yet, so I think it's good. Did you install TestDisk on you unRAID server or did you pull the cache drive out and put it into another system? If installed on unRAID server how is that done? I am a Windows user, so this is all still new to me.
February 20, 201511 yr Did you install TestDisk on you unRAID server or did you pull the cache drive out and put it into another system? If installed on unRAID server how is that done? I am a Windows user, so this is all still new to me. I ran it from the unRAID server. Here are my steps. Follow these steps at your own risk! The steps I followed, yours steps may vary. Restored backup files from /boot/v6.0-beta12/ Reboot UI should show beta12 as the version when it's done restarting. Make sure your array is shut down. connect via ssh or login to the machine directly mkdir /boot/testdisk cd /boot/testdisk wget http://www.cgsecurity.org/testdisk-7.0-WIP.linux26-x86_64.tar.bz2 tar -Bxvf testdisk-7.0-WIP.linux26-x86_64.tar.bz2 cd testdisk-7.0-WIP ./testdisk_static Write log Figure out which disk you need to fix by looking at the Web UI and determine which cache /dev/sd? is blue. This was changing between reboots for me, so make sure to check the UI before selecting the drive. Intel -> Analyse -> Quick Search -> Use arrows to set type (I chose logical first to match what the other drive had, but that didn't work after a reboot) I ended up selecting P for primary, and that worked for me. Yours may be differt. -> Continue -> Choose Write Exit program, and reboot from the UI. When it came back up my cache drives were both green, so I started the array and everything came up as expected. All my Dockers are working as they were before the beta13 upgrade. If the drives aren't green in the UI, repeat the steps within the ./testdisk_static program and try another partition type option. -Eric/Heuristic
February 20, 201511 yr i still have an issue with my Realtek NIC not waking from sleep intermittently http://lime-technology.com/forum/index.php?topic=37598.0 other then this issue latest Beta is excellent if this issue persists should i just buy an Intel NIC?
February 20, 201511 yr Did you install TestDisk on you unRAID server or did you pull the cache drive out and put it into another system? If installed on unRAID server how is that done? I am a Windows user, so this is all still new to me. I ran it from the unRAID server. Here are my steps. Follow these steps at your own risk! The steps I followed, yours steps may vary. Restored backup files from /boot/v6.0-beta12/ Reboot UI should show beta12 as the version when it's done restarting. Make sure your array is shut down. connect via ssh or login to the machine directly mkdir /boot/testdisk cd /boot/testdisk wget http://www.cgsecurity.org/testdisk-7.0-WIP.linux26-x86_64.tar.bz2 tar -Bxvf testdisk-7.0-WIP.linux26-x86_64.tar.bz2 cd testdisk-7.0-WIP ./testdisk_static Write log Figure out which disk you need to fix by looking at the Web UI and determine which cache /dev/sd? is blue. This was changing between reboots for me, so make sure to check the UI before selecting the drive. Intel -> Analyse -> Quick Search -> Use arrows to set type (I chose logical first to match what the other drive had, but that didn't work after a reboot) I ended up selecting P for primary, and that worked for me. Yours may be differt. -> Continue -> Choose Write Exit program, and reboot from the UI. When it came back up my cache drives were both green, so I started the array and everything came up as expected. All my Dockers are working as they were before the beta13 upgrade. If the drives aren't green in the UI, repeat the steps within the ./testdisk_static program and try another partition type option. -Eric/Heuristic Eric, I'm sure there are quite a few users who appreciate your help! Thank you, John
February 20, 201511 yr Thanks, Eric. I was not able to recover anything. So I decided to start over and scrap the cache pool and go back to a single cache drive. Which is what I have been wanting to do for a while now. How do I take a backup of my docker images just in case this happens again?
February 21, 201511 yr Author How do I take a backup of my docker images just in case this happens again? Stop docker and then copy the docker image file to another device.
February 21, 201511 yr How do I take a backup of my docker images just in case this happens again? Stop docker and then copy the docker image file to another device. Along with the app folder where I put the containers? - in my case /mnt/cache/appdata folder
February 21, 201511 yr How do I take a backup of my docker images just in case this happens again? Stop docker and then copy the docker image file to another device. Along with the app folder where I put the containers? - in my case /mnt/cache/appdata folder Sure! The image and the appdata folder are separate entities. The image doesn't contain user data (or at least it shouldn't if you're using Docker properly). If your docker image file got corrupted, the worst you should have to go through is redownloading the application images themselves, but the metadata for the apps should still be intact. The /mnt/cache/appdata folder is the one worth protecting as it stores things like Plex's library data and application configuration settings. If you lose that data, it's not exactly the end of the world like losing a movie file or personal data, but it's certainly a bigger deal than losing the docker image which contains no actual user data inside of it. make sense?
February 21, 201511 yr That makes sense, are you guys planning on implementing any sort of built in backup system to copy the appdata folder to the array?
Archived
This topic is now archived and is closed to further replies.