February 22, 201511 yr When i click Check for Updates at the bottom of my list of dockers the version changes to Not Available in red see screenshot When adding repo's i also get an error see screenshot
February 22, 201511 yr When i click Check for Updates at the buttom of my list of dockers the version changes to Not Available in red see screenshot When adding repo's i also get an error see screenshot Be sure you don't have any old docker manager plugins in the /boot/config/plugins directory. If there are any, delete them and reboot.
February 22, 201511 yr What do you have for the Settings->Disk Settings default format from the main menu? XFS
February 22, 201511 yr What do you have for the Settings->Disk Settings default format from the main menu? XFS Perhaps your flash is corrupt and it has been set to read-only.
February 22, 201511 yr Additional step needed. In addition to just disabling the cache drive(s), you need to actually change the number of available drives to "none", then start the array. Stop the array, come back and re-enable the cache drives and then the option to change the file system is available to select. HOWEVER!!!!! When you stop the array for some other reason and restart... BAM... back to BTRFS. What the heck is going on? After changing the file system, did you confirm formating of the drive (see Array Operations page) ? Yes. It reads as XFS. But when you stop the array it "reverts" to BTRFS. It should say there is a unformatted disk (name is listed), and ask you to do a format, this will take a couple of minutes to complete. You are saying that after this it all reverts back to BTRFS Correct. It goes through formatting, says XFS, then the next time the array starts it says BTRFS. ? Please post a defect report with your syslog. I think I know what might be going on here but would need to see your log to review and confirm.
February 22, 201511 yr Author Please see below. Array is stopped, but I can't change the file format. I've unassigned it, started the array, stopped the array, re-assigned and I still can't change it. How many "Slots" are assigned to "Cache"? If one and only one slot, you have a "Cache disk" - you can select any fs you want for it: btrfs, xfs, or reiserfs. If more than one, then you have a "Cache pool" - only btrfs supports a pool, hence file system type is always forced to 'btrfs' if more then one cache slot.
February 23, 201511 yr All, Here is a link to a guide I just posted on how to recreate your Docker image file / redownloading your apps. You will not lose your application settings as part of this process. Here's the post: http://lime-technology.com/forum/index.php?topic=38323.msg355667#msg355667 I updated the OP to reflect this as well.
February 23, 201511 yr Not sure if this has been mentioned yet but beta14 requires to manually /etc/rc.d/rc.libvirt start in order to start KVM. This wasn't necessary in beta13,
February 23, 201511 yr Any idea when 14a will be released ? Or have enough small bugs been found to jump to 15? I only ask because I want to minimize upgrades/restrarts. 13 is stable as a rock for me.
February 23, 201511 yr Any idea when 14a will be released? This made me chuckle. Thanks yeah, I felt a bit silly making the post but in my defence 14a has been announced. Right, sorry mea culpa. We will be releasing -beta14a patch release asap to fix this.
February 23, 201511 yr This update seems to have broken one of my unraid servers. After upgrading I got this message: ----[end kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) I restarted and got this message: floppy0: no floppy controllers found VFS: Insert root floppy and press ENTER I pressed enter and got the first message again. Here's a screenshot: I updated through the GUI and it went through the first time (same as my other server). I was on beta13 before the upgrade. Any ideas on why its saying this message? I copied the upgrade over manually using a windows computer and I get the same message.
February 23, 201511 yr This update seems to have broken one of my unraid servers. After upgrading I got this message: ----[end kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) I restarted and got this message: floppy0: no floppy controllers found VFS: Insert root floppy and press ENTER I pressed enter and got the first message again. Here's a screenshot: I updated through the GUI and it went through the first time (same as my other server). I was on beta13 before the upgrade. Any ideas on why its saying this message? I copied the upgrade over manually using a windows computer and I get the same message. I don't know if this is relevant to you, but it can't hurt to try it. http://lime-technology.com/forum/index.php?topic=20557.0
February 23, 201511 yr Not sure if this has been mentioned yet but beta14 requires to manually /etc/rc.d/rc.libvirt start in order to start KVM. This wasn't necessary in beta13, 1st boot on b14, neither Docker or KVM started. 2nd boot on b14, Docker started but KVM didn't. 3rd boot on b14 after seeing this to grab a syslog, Docker & KVM started. Have you booted a 3rd time yet?
February 23, 201511 yr Does the cache drive still need to be formatted btrfs for Docker ? I thought I read somewhere that this was no longer a requirement. Would consider using XFS like my other drives. You are correct -BTRFS format cache drive is no longer a requirement for docker. The main reason for sticking with BTRFS would be if you wanted a specific feature that requires BTRFS such as cache drive pooling. If you do not need something like that the XFS would now be the recommended format.
February 23, 201511 yr Updated to B14 (from 12) via webui, plugins first, then uR. Did the docker.img thing, reloaded Plex successfully. Going through all the various server settings now...
February 24, 201511 yr Upgraded to Beta 14. Rebuilt dockers. Parity speed about half of what it was with beta 12 for me. Ran about 50% of a parity check in 10 hours. With Beta 12, the whole parity check took about 12 hours. I stopped the check and rebooted. Now running parity again at about 44 MB/sec. With beta 12 ran at about 80 MB/sec. Anyone else having issues with parity speed with beta 14. Thanks System log attached. syslog_2.zip
February 24, 201511 yr I'm running a preclear on the 'production' b14 server now, so hopefully it'll be happy days. Thanks for the help, and sorry for the rant. Preclear Successful ... Total time 43:15:41 ... Pre-Read time 12:55:20 (85 MB/s) ... Zeroing time 8:41:21 (127 MB/s) ... Post-Read time 21:37:51 (51 MB/s) Yay!
February 24, 201511 yr Upgraded to Beta 14. Rebuilt dockers. Parity speed about half of what it was with beta 12 for me. Ran about 50% of a parity check in 10 hours. With Beta 12, the whole parity check took about 12 hours. I stopped the check and rebooted. Now running parity again at about 44 MB/sec. With beta 12 ran at about 80 MB/sec. Anyone else having issues with parity speed with beta 14. Thanks System log attached. I assume that you are watching the progress on the GUI. Have you adjusted the setting 'Page update frequency:' on the 'Display Settings' page of the 'Settings' tab? As I understand it, refreshing the web page results in disks reads which slow down disk access speeds with SOME hardware. Checking the 'disable page updates while parity operation is running' box should help if this is the case in your situation. Right now, mine is moving at 92.2MB/s.
February 24, 201511 yr Upgraded to Beta14: Everything seems to be working but I had a few concerns / issues pop up during the process. I am going to catagorize these by concern type. [suggestion] Had the same issue with upgrading via the plugin system where the first click just failed, the second click worked. During this process unRAID has to download quite a bit of data to update the system, upon the second click no status was given which makes it seem like the update process has hung-up which if you don't know any better might cause you to click to close the update and try again. A status saying downloading update (or if possible a progress %) would prevent the assumption that there was an issue. [Concern?] Because of the issue outlined in number 1, and because I thought the process wasn't working decided to try the old route to updating via the download provided in OP. Once "unRAIDServer-6.0-beta14-x86_64.zip" completed downloading Chrome warned me that "unRAIDServer-6.0-beta14-x86_64.zip" was not a commonly downloaded file and prompted me on if I want to download anyway. I said yes, it said "It might harm your computer, I said yes anyway..." Then because that was weird I scanned it with Bitdefender... and it came up with 14 infections in the .zip that it removed... I assume these are false positives, but I could see this as kind of alarming if you are a new user who doesn't yet trust lime-tech. (I ended up starting the plugin update process again and letting it do it's thing... when it eventually finished all was good.) [Concern] For some reason my Seagate 3tb drive did not spin down with the others (I think this was due to me accessing smart data while other disks were called to spindown) it then didn't spin down for another 1:30 min when spin down time is set to 15 min. It did spin down and stay down when I hit spin down all disks now... but I got concerned when I got a notice saying my array was "inactive" and zero disks were running. The language made me think this was an issue with the array not just the disks being spun down due to lack of use. What I noticed after this though was odd, my SSD cache disk was marked as spundown... which shouldn't and shouldn't have happend. Brining up the disk info "spun it up" and it was marked when I checked this morning. Shortend List: SSD marked as spundown (after hitting spin down all disks now?) Download in the OP prompted warnings by Chrome, and showed false positives (?) when scanned by bitdefender Lack of progress or status when hitting update plugin for the OS update might mislead people to think the process is hung when it's just downloading a lot in the background first If anything else shows up I'll let you know.
February 24, 201511 yr Upgraded to Beta14: Everything seems to be working but I had a few concerns / issues pop up during the process. I am going to catagorize these by concern type. [suggestion] Had the same issue with upgrading via the plugin system where the first click just failed, the second click worked. During this process unRAID has to download quite a bit of data to update the system, upon the second click no status was given which makes it seem like the update process has hung-up which if you don't know any better might cause you to click to close the update and try again. A status saying downloading update (or if possible a progress %) would prevent the assumption that there was an issue. This seems similar to what I noticed when rebuilding my docker containers. In b12 Chrome would open up a separate window that would show the download progress of the container(s) and metadata, whereas with b14 everything seems to happen in the main GUI page and it just "hangs" with the page working to refresh. Once the container was downloaded the page refreshed to show all that was downloaded and completed. It would be far better to show actual progress so that you know something is happening and it's being successful vs. having a window just sort of hang there until complete.
February 24, 201511 yr Upgraded to Beta14: Everything seems to be working but I had a few concerns / issues pop up during the process. I am going to catagorize these by concern type. [suggestion] Had the same issue with upgrading via the plugin system where the first click just failed, the second click worked. During this process unRAID has to download quite a bit of data to update the system, upon the second click no status was given which makes it seem like the update process has hung-up which if you don't know any better might cause you to click to close the update and try again. A status saying downloading update (or if possible a progress %) would prevent the assumption that there was an issue. This seems similar to what I noticed when rebuilding my docker containers. In b12 Chrome would open up a separate window that would show the download progress of the container(s) and metadata, whereas with b14 everything seems to happen in the main GUI page and it just "hangs" with the page working to refresh. Once the container was downloaded the page refreshed to show all that was downloaded and completed. It would be far better to show actual progress so that you know something is happening and it's being successful vs. having a window just sort of hang there until complete. I seem to recall that this issue has already been brought to the attention of Limetech and they said the issue would be addressed.
February 24, 201511 yr Upgraded to Beta14: Everything seems to be working but I had a few concerns / issues pop up during the process. I am going to catagorize these by concern type. [suggestion] Had the same issue with upgrading via the plugin system where the first click just failed, the second click worked. During this process unRAID has to download quite a bit of data to update the system, upon the second click no status was given which makes it seem like the update process has hung-up which if you don't know any better might cause you to click to close the update and try again. A status saying downloading update (or if possible a progress %) would prevent the assumption that there was an issue. This seems similar to what I noticed when rebuilding my docker containers. In b12 Chrome would open up a separate window that would show the download progress of the container(s) and metadata, whereas with b14 everything seems to happen in the main GUI page and it just "hangs" with the page working to refresh. Once the container was downloaded the page refreshed to show all that was downloaded and completed. It would be far better to show actual progress so that you know something is happening and it's being successful vs. having a window just sort of hang there until complete. I seem to recall that this issue has already been brought to the attention of Limetech and they said the issue would be addressed. Good to hear. I must have missed that.
Archived
This topic is now archived and is closed to further replies.