rara1234

Ok so I figured it out - despite buying an M1015 the vendor actually sent me an M5015. I didnt notice at first, but exploring with megarec -adplist it showed the type as 2108v - which is clearly not an m1015. I reflashed it with the m5015 firmware and sbm and all was fine. Now to get a refund from eBay…

Then I downloaded the original IBM ROM from the IBM website ftp://download2.boulder.ibm.com/ecc/sar/CMA/XSA/ibm_fw_sraidmr_1000-20.11.1-0184_windows_32-64.exe, and extracted M1000FW.ROM. Using megarec -cleanflash 0 M1000FW.ROM I get: MegaRAID HWR Controller Recovery tool. Version 01.01-004 February 05, 2010 Copyright (c) 2006-2008 LSI Corp. Supports 1079 controller and its Successors Erasing Flash Chip (8MB).... Completed: 100% Flashing Image. Please wait... Currently flashing component = BIOS Programming Flash.... Completed: 100% Verifying the Flashed Data... Currently flashing component = HIIM Programming Flash.... Completed: 100% Verifying the Flashed Data... Currently flashing component = APP Error in downloading the image. Error code = 64 Failed to flash the image. Please retry recovery grr!!

I have an HP Gen8 microserver. I disabled the onboard storage controller in the bios, and installed my M1015 card. I downloaded LSI MegaRAID to SAS2008(P11).zip - 5.87 MB from here: https://lime-technology.com/forum/index.php?topic=12767.0 and followed the instructions exactly, although (my fault) I didn't complete step 1 (as the ID is on the label) or step 2 (as I'm a dumbass). Step 3 went as expected but step 4 just reports "No LSI SAS adapters found! Limited Command Set Available" and fails. Has anyone else had any success flashing this card in a Gen8 microserver? Was there anything specific you needed to do? Failing that - would anyone like to earn a bit of money flashing the card for me?

there's a better fix: this post: https://github.com/docker/distribution/issues/1439#issuecomment-237999672 has the fix which worked perfectly for me without having to reinstall everything...

Just got home from work, and wanted to try something simpler before I killed my docker.img and reinstalled all dockers. Clicked on the app remove also remove image yes delete it reinstalled in CA works perfect now. Hopefully they do edit the second post on the announcement and list the issues and simple fixes that we are having. thanks again for pointing me to that. I missed that in the FAQ when I had a quick look over it last night this post: https://github.com/docker/distribution/issues/1439#issuecomment-237999672 has the fix which worked perfectly for me without having to reinstall everything... you can just log in using SSH and clear the cache (details below):

this post: https://github.com/docker/distribution/issues/1439#issuecomment-237999672 has the fix which worked perfectly for me without having to reinstall everything...

I've created a new container which has CUPS, GCP and AirPrint: https://hub.docker.com/r/mnbf9rca/cups-google-print/ I'll try and create a "template" once i figure out how. But it's working fine for me. Doesn't do full cloud print yet, just local network.

OK, so I have CUPS working to share the printer, that's working fine. It's just the Google Cloud Print part I'm struggling with. yeah, i have the same issue - i think it's because the script uses an outdated way to authenticate to Google. I raised a defect on the github repo: https://github.com/gfjardim/docker-containers/issues/56

I have Emby (emby/embyserver:latest) running in one container, and Sonarr (linuxserver/sonarr:latest) is also installed. When i try to configure a "connection" between the two so that Sonarr notifies Emby of a new episode, i can't get it to save - it just reports " Unable to send test message: The request timed out " - however, when i look in Emby's notification centre, i see " Test from Sonarr 7 minutes ago Success! MediaBrowser has been successfully configured! ". I tried entering the Sonarr container and made a request using CURL (" curl -X POST -H "Content-Type: application/json" -d '{}' "http://192.168.1.5:8096/emby/emby/Library/Series/Updated?api_key=<key> ") and it works. I was able to add a "webhook" type connection without a problem though - and that does trigger an update to the library.

hi rara1234, thanks for the volunteered help on this, its appreciated!. couple of questions for you:- 1. where does the webui store its configuration information?, can this be configured or would it have to be symlinked in some manner? 2. can you pre-configure some of the options in the webui, or again is this going to have to be done only using the webui?. whilst the way i currently have it running is a little low tech, it generally works quite well, so i want to make sure if i do move to using the webui that its just as solid. right im going to have a play with this now, i may come back with more questions :-). oh and btw this is a quite old thread, best to keep any future posts in my new snagly docker support thread here:- http://lime-technology.com/forum/index.php?topic=38055.0 1. The web app simply automates the use of the PVR functionality: https://github.com/get-iplayer/get_iplayer/wiki/documentation#pvr-usage So if you were to map that folder (~/.get_iplayer/pvr/) the searches would persist between refreshes. 2. Not sure what options you'd want to configure? or do you mean about searching, download options etc.? I kinda lost track of this conversation here - to me, it makes no sense to have 1 thread per publisher, wouldnt 1 thread per image be better?? - anyway, i created my own docker which implements what i needed - basically, it's get_iplayer pulled ppa:jon-hedgerows/get-iplayer and with apache running the web pvr. You can find it here: https://hub.docker.com/r/mnbf9rca/getiplayer I've made it so that the list of already recorded files and the PVR searches are stored outside the container for persistence. The programme cache is updated every hour, and you can add radio, tv and podcasts. The PVR runs every 6 hours. Map the folders listed in teh dockerfile: # /output = location of downloaded files # /tmp for transcoding? not sure # /var/www/get_iplayer/.get_iplayer --> profile directory, including PVR searches and cache # /etc/get_iplayer --> options file stored here

Yes but it also violates a key "rule": https://docs.docker.com/engine/articles/dockerfile_best-practices/#containers-should-be-ephemeral Which makes it harder for users to safely consume - a user might be hesitant to update if they think they have some config to do, and for something like a web server or ssl certificate that could be an important issue…

How did your family get along before docker? If I needed to I could go back to that approach while I tried to troubleshoot individual dockers on my unRAID. I know what you mean - but I suspect the world might fall apart without Thomas and friends, pepper pig and regular updates on the comings and going a of the kardashians Previously I had a separate machine running all of these apps. I don't have it any more. I could set these up on a vm but I suppose, but again, I'm sure there is some way to identify where the allocated storage has gone, we just don't know it yet. If I get time over Christmas I will try to rebuild the docker image one at a time. The problem is that it works fine for months then I get 30-50% growth (on a 10gb image) in a day or two, completely at random.

i'd be happy to concede that if i could show it - but not using functionality which is important to my family on a daily basis for months at a time isn't a viable approach. Without this, how can i figure out which one it is? I mean, there must be some better way (i.e. some systematic/analytical approach using e.g. logs, tools to interrogate the system etc.) which can be used to narrow it down to the container(s) which are causing this?

sorry - i updated my answer after you'd replied to add that: 1. I dont know how to figure out which container is causing it without disabling them one by one for 3 months at a time (the average time it takes for it to be noticeable in my case), and 2.I would have expected that a badly configured app within a container shouldn't be able to permanently consume image storage i.e. the container should be reallocating storage before consuming and then not releasing more image storage.

thank for the helpful reply. I have transcoding disabled in emby. I guess the issue is that I simply don't know how to narrow down the issue e.g. how to work out which container is causing the issue without disabling them one by one and waiting 3 months - but that's clearly not an option! And as far as i can tell, when storage is released within a container it should be released in the image too, which apparently isn't happening, and that's where i think the defect lies - badly configured apps within containers shouldn't be able to permanently consume storage...