-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trying to run Hangover inside a docker container on my Raspberry PI #114
Comments
I also tried downloading the arm compiled version from here: https://github.com/AndreRH/hangover/actions/runs/615456472 I simply downloaded the When running commands against this version I got different errors again:
|
Just some related question, yesterday I created a new github actions build that actually builds the image using the ARM64 architecture (using Qemu): It however seemed to stop after 6 hours. I was comparing it with your builds which do complete after about 2.5 hours. It seems that for whatever reason your builds run quite a bit faster. I suppose this is due to them being build on x64 rather then ARM, could this be true? And if this is the case, should I build |
Hi, interesting project! Regarding your /root/hangover2 approach, the artifact you downloaded only includes the build folder, but for various reasons it expects to sit in a hangover checkout with the source files. same setup as it has in /root/hangover, so you might be able to just copy everything over from there. Regarding building in qemu, yes, that's horrible slow and exceeded the time allowed for github actions... |
@AndreRH , thanks for your quick response.
I did try to run normal wine on an x86 docker container which also showed similar warnings but worked correctly. Also with the "FileOptimizerFull.exe /S" command quite a few warnings/errors were shown but the end result was that the .exe file installed correctly. The main reason I chose to test it with xcopy is because I would expect it not to need a $DISPLAY to actually run this CLI application. You can check out my X86 wine install of file optimizer here:
To me it feels like something else is going wrong, but I can't figure out what it is.
I'll try this, thanks for the suggestions :)
So you're saying that (with your dockerfile) the build output should be the same when you run it on an x86 image and on an arm image? |
Here you are running into my terrible, terrible way of qemu telling you that an unimplemented function got called. The PE loader will set any unimplemented function to a byte containing 0xcc. You see the RIP pointing to the next instruction after the breakpoint. I don't see any obvious issue in your FileOptimizerSetup output. I'll give it a try myself. And I need to silence those CharPrevW spam lines some day. |
@stefand, is xcopy supposed not to work? (If you're saying its calling unimplemented functions) And if so, is there another program I can use to better test if everything is working? |
@AndreRH I just copied over the build directory into a newly cloned /root/hangover3 directory. After running this the errors seem to be the same as with my own build version (which I guess is good since I could simply include your compiled version rather then compiling myself):
Would it be possible to create github releases with the actual /build folder output? That way I would be able to simply do a Currently the output is only being pushed to github actions which can't be easily downloaded using I've set this up previously using this task:
What would probably need to happen to make it all work a bit nicer is to have only 1 workflow which does all 3 builds, and if all complete successfully the release would be created. Edit: |
Sounds good. That's the plan for releases, the normal runs also vanish after 90 days |
What software are you guys testing with to see if it's working? (As xcopy doesn't seem to be working for me) |
Do you guys use discord / slack to maybe connect to each other a bit quicker? |
My usual test to find out if the basic functionality is Wine's notepad - but that is a GUI program. I have fixes for xcopy coming. It used to work once, but since Wine has been migrating from ELF builds of its internal programs to PE builds that are linked against ucrtbase.dll those programs started hitting missing functionality in hangover's thunks. I am hanging out in #winehackers on freenode. The dxvk guys run a discord bridge to that channel if you want to use it. But beware that hangover is a pet project for both of us, so the time available is limited anyhow. |
I've just pushed fixes that make "xcopy /?" run for both 32 and 64 bit xcopy. I haven't tested actual copying functionality. Please remember to update the submodules. |
Oh also the build system is kinda bad with incremental rebuilds, so I recommend to rm -rf build/ |
Yeah my ImageOptimizer is only a side project for me as well, so no hurry :). I'll try to setup builds for you guys so that I can also more easily integrate that in my docker container. That way I don't have to wait 6 hours every time to build a new image if you've made some changes. |
The installer runs fine for me and FileOptimizer starts OK as well. However, it doesn't optimize any files because it can't start subprocesses. The Wine hack to start qemu for x86 apps needs to be updated for the recent move of CreateProcess to ntdll. I suspect two problems: Either the installer doesn't work without an X server after all, even in silent mode, or you cancelled it while it was working (it takes some time here due to uncompressing and slow I/O) or it installed OK and you didn't realize it. Did you check for the installed files in C:\Program Files? |
I just tried running the command again and checked the Program Files folder (I expected this to be in /root/.wine/ but I'm not sure if this is correc). I couldn't find the installed data though. When running this with the latest version of wine in a docker container on x86 it does work correctly though. Anyway here's the output of running it inside my ARM docker container:
I also tried running it in a docker container running on x86 with normal wine installed.
With the files actually being installed:
|
An update: The installer now works! Apparently using the new build output in my /root/hangover4 folder I was able to successfully install FileOptimzer! 😄, for me it doesn't matter then direct calls don't work since I'll be manually calling the other binaries myself. I'll keep you guys up to date on the progress of the rest. Edit:
I just tried running these in an x86 wine docker container too which worked fine: |
I pushed a fix for the immediate 7z.exe problem. I can now unpack and compress files, but when I pass an incorrect command line parameter it crashes and gets stuck in an exception loop. I guess it throws a C++ exception that it handles internally and hangover's exception handling code has some problem with that. I don't immediately see what problem ECT has. I can reproduce that it doesn't run right, but unlike 7z it isn't immediately obvious why. |
Thanks for the 7z fix, hopefully the other one can also be solved. Did you already have some time to look at my pull request for automated builds? Btw, I did see that one of the builds is currently failing for you: |
That was done today: https://github.com/AndreRH/wine/tree/2d8f779203e42f8c2f842393da3062f6c9aeb8fe/programs/hangover |
Thanks @AndreRH , As I mentioned in the IRC chat I'm running into some trouble creating a docker container without actually compiling the code. For some reason simply unzipping the latest build shows me errors while if I do the 6 hour compile again on my raspberry pi it works fine. If you want, I created 2 containers and pushed them to docker hub, one where I just extracted the zipfile (:beforemake) and one where I executed the make command after (:aftermake): |
Apparently with the latest build I managed to get it working for xcopy again :). This is the dockerfile I'm using currently to create my own image:
Do you know if there's any steps I should be able to skip when creating an image with just the build output? (I think I wouldn't need the whole compiler stuff). The thing is that if I simply continue with this image my whole apt-get shows some errors when I run things:
And installing nano for example:
|
I was now actually playing around with getting my C# application working. I did get everything running which is really great! But I still have one strange issue. When I freshly start my docker container with hangover and directly run my C# application. It gets stuck while trying to run the first application using hangover. If I run it again, the same thing happens. However if I do the following call:
And then execute my C# application, everything works fine. I've made a screenshot of my problem: Edit:
Edit2: This really needs some more investigation but I can't really figure out where to start. |
I did also run a test where I compare the speed of running my x64 docker container where the complete container runs in emulation using https://github.com/dbhi/qus vs running my own C# application as an ARM build with hangover. x64 docker container + QUS (Everything runs in emulation): ARM docker container + hangover (my own application which does a pixel by pixel comparison runs in native ARM, the rest runs in hangover emulation): What you can see here is that the image comparison step (happening in my own C# code which is compiled as ARM) happens in about 2 seconds rather then 46 in the x64 emulated version. What I do find strange though is that all the other tooling, which are exactly the same .exe files, actually run about twice as slow. So in the end the whole process took about the same time. Could this maybe be explainable by me running the |
I just spoke a little bit on this topic with stefand in IRC, however I also wanted to add my comment here. The thing my C# application does is basically invoke 6 tools to optimize an image and then do a pixel by pixel comparison with the original to see if everything went fine. The strange thing is though that if I let my C# application execute the JHEAD.exe command it gets stuck. Even if I restart my C# application. However if I manually call it, it works:
So for some reason, when I execute this command from inside my C# application something breaks. Everytime I first call |
Docker image gets stuck if ran with -t rather then -it I've managed to get quite far with actually building / running a docker image based on hangover now. I successfully managed to optimize some images. I'm running into another strange thing though: If I create an AMD64 image based on normal wine (without hangover) and run my image optimizer, everything runs fine with the The image I created with hangover running on ARM64 for my RaspberryPI does run fine on my raspberry pi with the I've added a build that shows this behavior: I did try to run the docker container in github actions using For some reason the build just hangs (I suppose waiting on terminal input) on the Summary of all my problems So basically here's a summary of all my issues that aren't solved, hopefully @stefand or @AndreRH you can take a look at this sometime :) (no hurry but I would like to look into these at one point in time). Most of the details are described somewhere in this post:
|
irrelevant with new Hangover approach |
System Details
Platform I'm running on: Docker image on Raspberry PI 4 8GB (Rasperry PI OS 64 bit)
Platform I used for compilation: Docker image on Raspberry PI 4 8GB (Rasperry PI OS 64 bit)
Toolchain: I basically used your dockerfile used in Github actions
Problems Description
I'm currently working on a tool that does image optimization inside a docker container. It makes use of Windows executables since not all of them are available on Windows. I created a docker container for this which makes use of Wine to actually call the executables which works fine. (My repo: https://github.com/devedse/DeveImageOptimizer/)
I thought, wouldn't it be cool to be able to run this on my Raspberry PI (it's of course not going to be very fast, but I like to search the boundaries of what's technologically possible).
That's when I found out about
hangover
.I created the following docker file (with some sections commented out so that I could more easily play around with it):
For just testing
hangover
I guess everything below the line where I download FileOptimizer can be ignored.If you place this dockerfile in
DeveImageOptimizer.ConsoleApp/Dockerfile2
and build this image on ARM64 (my Raspberry PI) it takes about 6 hours but after that it seemed to be complete.I simply started the image using the following command:
After this I had a working image with a
/root/hangover/build
folder.On the Readme.MD it's specified you need to run
/root/hangover/build/wine-host/loader/wine64
however on my build I could only find....../loader/wine
Based on what was further described in the readme I tried running some simple programs from the
wine-guest32
andwine-guest64
directories. However this resulted in some errors:/root/hangover/build/wine-host/loader/wine /root/hangover/build/qemu/x86_64-windows-user/qemu-x86_64.exe.so /root/hangover/build/wine-guest32/programs/xcopy/xcopy.exe
/root/hangover/build/wine-host/loader/wine /root/hangover/build/qemu/x86_64-windows-user/qemu-x86_64.exe.so /root/hangover/build/wine-guest64/programs/xcopy/xcopy.exe
And also when trying to run my the setup file I would actually like to install,
FileOptimizerFull.exe
I run into similar problems:/root/hangover/build/wine-host/loader/wine /root/hangover/build/qemu/x86_64-windows-user/qemu-x86_64.exe.so /root/FileOptimizerSetup.exe /S
Hopefully someone can give me some insight in how to resolve this 😄
The text was updated successfully, but these errors were encountered: