First run of the image asks for .NET installation and --reset fixes it

[pauleve]

Occurs the first time the image is ran.
This has been observed on Mac OS X (issue #3) and maybe on Linux as well.

./run-mtgo --reset

fixes it.
This is strange as --reset puts the environment in the exact same state as if it should be at first run...

[pauleve]

Haven't been able to reproduce on Linux so far..

[Kurolox]

I've found the same issue, and I'm running on Linux.

Linux Horus 4.13.4-1-ARCH #1 SMP PREEMPT Thu Sep 28 08:39:52 CEST 2017 x86_64 GNU/Linux

[pauleve]

Thanks for the feedback. Was there any special output by run-mtgo? Did you pull the image before running it, or did you let the script pull it for you?

[Kurolox]

Unfortunately, I don't remember if there was anything special when running run-mtgo. However, I can confirm that I pulled the image before running the script.

Also, I've done the exact same steps in my desktop and I've been unable to reproduce the issue.

[JeffHoogland]

On my Ubuntu 16.04 based system I had this occur as well.

In order ran:

sudo docker pull panard/mtgo
wget -O run-mtgo https://raw.githubusercontent.com/pauleve/docker-mtgo/master/run-mtgo
chmod +x run-mtgo
sudo ./run-mtgo

[holstvoogd]

Same issue on macos sierra:

[11:19:04] ~/Projects/docker-mtgo $ ./run-mtgo                                                                                                                                             [master][2.2.3]
open -a XQuartz
socat on 192.168.1.3 forwarding to /private/tmp/com.apple.launchd.Ws7Uz8zm4R/org.macosforge.xquartz:0
2018/01/28 11:19:53 socat[69071] E bind(5, {LEN=16 AF=2 192.168.1.3:6000}, 16): Address already in use
docker run --privileged --rm -e DISPLAY -v /Users/arthur/.local/share/mtgo:/home/wine/.wine/host/ -v mtgo-data:/home/wine/.wine/drive_c/users/ -e WINE_X11_NO_MITSHM=1 --net=host --ipc=host -e TZ=/usr/share/zoneinfo/Europe/Amsterdam --name mtgo_running panard/mtgo:latest mtgo
wine: Unhandled page fault on read access to 0x00000018 at address 0x7ed2a83a (thread 0019), starting debugger...
err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046}
err:ole:marshal_object couldn't get IPSFactory buffer for interface {6d5140c1-7436-11ce-8034-00aa006009fa}
err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80004002
err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 80004002
err:ole:get_local_server_stream Failed: 80004002
^C./run-mtgo: line 222: 69078 Terminated: 15          tail -f ${URL_REQUESTS}
./run-mtgo: line 236: kill: (69071) - No such process
     69080                       | while read url; do
    run $WEBBROWSER "${url}";
done

Couple of notes:

• in wants to install .net 4.5.2
• it fails on permissions (didn't get copy of the error)
• --reset did fix it.

[pauleve]

Thanks for the report! This is issue is a total mystery to me... and I cannot reproduce even after a complete removal of docker images and local data on a machine where I did had this issue the first run..

[thisSIDEofRANDOM]

Confirm issue on Ubuntu 17.10

I'll give it a fresh try tonight on Arch and see what comes of it. Been trying to document what files are getting created on this and wondering if it has something to do with the reg files getting dropped under ~/.local/share/mtgo

[pauleve]

Yes, there is maybe some corrupted files somewhere. If you have the issue on arch, you can send the md5sum of the files in ~/.local/share/mtgo so I can check if they are correct.
Also, before doing the --reset, try doing

./run-mtgo --shell
$ wineboot
$ mtgo

[thisSIDEofRANDOM]

@pauleve worked first try on arch running xfce. I'm at a loss now also.

[manpages]

Hard to reproduce, happened to me once yesterday, I tried to reproduce on a clean system, didn't work.

[pauleve]

I reproduced it in the following way:

1. forget to start docker
2. ./run-mtgo (it fails)
3. start docker
4. keep asking for .NET installation, only --reset fixes it.

commit 7bfa284 fixes this scenario.

To whom having experienced this bug, is having missed starting the docker service a plausible scenario as well?