No error messages or anything for me to debug. Any suggestions? I let it sit twice for 6 hours and it never finishes. The “Still Working…” message does keep appearing every minute or so.
K. Finally worked. No idea what happened there.
Hi @badevguru,
Sorry to hear you’ve been having issues with Resin.io.
Could it be a non stable internet connection in your device?
Please let us know if the issue re-appears and we will help you debugging it.
I have the same issue. Something about the caching it seems:
Building on ‘local’
Pulling old image for caching purposes
Still working…
Still working…
Still working…
Still working…
Goes on for ever, not sure whether it is extremely slow or hangs.
The build process works if I use a new app, I guess since nothing can be cached yet then
Hey @tobias,
Are your still running into this issue? Which base image are you using?
You could also try our native ARM builders they are still in testing but seem a lot more robust, to use the ARM builders you’ll just need to run:
git push resin master:master-arm
This “still working…” issue started happening to me too just now. Haven’t experienced this before.
woohoo! The solution @craig offered got it past the caching step and it’s building the image now. We’ll see if everything works afterwards… 
Hey @metakermit, our default builders are experiencing some unexpected behaviour. Currently investigating, but you can keep updated via our status page.
Glad the ARM builders are doing their job in the interim
1 Like
I hit this bug as well on my RPi2. The master-arm trick appears to have worked! Thanks! Also, great job on the resin.io stack I’m really liking it so far.
@craig You guys have probably already discovered this, but I believe the infinite hangs are due to a race condition bug in the qemu-user-static that is used for the cross compilation of the docker containers. It is further described on QEMU’s Launchpad tracker here.
I’m curious as to how to fix this as well for some of my homegrown embedded docker needs as well.
Hey @mevatron, thanks for kind words Glad the arm builders worked for you.
Yip we’ve done a fair share of research into this bug but from what we have seen so far in the bug reports and various other places is that this specific bug needs a big re-architecture of how QEMU handles signals.
The launchpad tracker link is a great place to start in understanding the issues, but it will most likely be a long process to implementing a fix. That’s no reason not to start though
Hey @mevatron. I’ve tried to fix this bug a few times in the past but now I gave it one more shot and I think it worked! I have two problematic testcases that hang forever under the old QEMU but with the new one they work as expected.
I modified this patchset[1] so that it cleanly applies to the latest master branch of QEMU and also added support for the select() syscall. Currently this code lives in a branch[2] if you want to take a look but it seems very promising. We’ll do some more testing and hopefully will roll it out soon 
[1] https://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=Timothy+Baldwin&q=linux-user
[2] https://github.com/resin-io/qemu/compare/master...signal-race-fix
@petrosagg Awesome! I was actually looking at those patches on the mailing last night! 
I will definitely give this branch a shot. Thanks for the info!
Hmmm … I’ve be hitting this issue for the last couple of days. I’m new to resin.io so I’m not sure if the problem is between the chair and the computer or if this issue has surfaced again.
I am experiencing the same problem for my raspberry build - for 2 or 3 days now. Before that it used to work most of the time, but occasionally I would also see endless still working messages.
Pushing to
git push resin master:master-arm
does not seem to do the trick, unfortunately. Same behavior.
Update: Now it worked using
git push resin master:master-arm
Default method works as well:
git push resin master
@hackingparticlesg glad they are working for you as expected now. We had some peculiarities with the builders last week. We’ve pushed an update. Please let us know if you experience anything unexpected again.
Cheers,
Craig
Just to close out this issue. As of Feb-29-2016, the QEMU builds still crash when doing a lot of the git clone commands on my build. I have moved my image building to dedicated ARM servers and then simply use a Dockerfile that references the pre-built arm image on docker hub. That has eliminated this as an issue for me. Good luck!
@badevguru Do you mind trying the regular builders again? We have released another fix which should alleviate all build hangs.
Cheers,
Craig
I just had this issue on the regular builders. raspberrypi2-debian image, running this to get a newer version of mono:
RUN echo 'deb http://plugwash.raspbian.org/mono4 jessie-mono4 main' >> /etc/apt/sources.list.d/mono4.list && \
apt-get install mono-complete
Hung twice for 30-60 minutes before I cancelled each time on Setting up libglib2.0-cil (2.12.10-5.1) ...
Hey @justin8,
I don’t think this is QEMU issue, I must say that mono-complete is a huge packge, I did work on .NET example on Resin long time ago and It took me more than 2 hours just to install mono-complete and other dependencies. So instead of mono-complete, I would say it’s better to compile your work locally and just install mono-runtime which is enough to run .NET binaries.
One more thing, I think you should run apt-get update after adding new sources.list file, before installing mono-complete.
Kind regards,
Trong