# Unable to start on-premise demo server per "Getting Started" instructions **URL:** \ **Category:** General Discussions\ **Created:** [January 8, 2020, 9:31pm UTC](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414 "2020-01-08T21:31:07Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [February 15, 2020, 8:44am UTC](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414/21 "2020-02-15T08:44:51Z")
If I recall, there were 3 domains that I had to add to /etc/hosts to make it work in my virtual box VM. I think I looked through prod.yml for all listed domains that needed to be resolved to localhost. I believe a storage proxy domain was one of the domains added. I’m away from office but I have a live running production ready instance of mender running on Ubuntu guest in virtual box, running on a Linux host using bridged networking. I don’t think I had to do anything special in virtual box to make it work. ---
**Author:** ![Kris](https://avatars.discourse-cdn.com/v4/letter/k/82dd89/32.png) [@Kris](https://hub.mender.io/u/Kris)\ **Post date:** [February 17, 2020, 4:56pm UTC](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414/22 "2020-02-17T16:56:21Z")
@0lmi The VM is currently in NAT mode for networking and has been since I started this thread. Is there another network configuration that I should be using? @dellgreen That would be great if you could pass along the hosts modifications if that has an impact! ---
**Author:** ![0lmi](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/0lmi/32/133_2.png) [@0lmi](https://hub.mender.io/u/0lmi)\ **Post date:** [February 18, 2020, 11:14am UTC](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414/23 "2020-02-18T11:14:11Z")
@Kris I installed latest Ubuntu 18.04.4 Desktop in VirtualBox v.6.0.16 (on MacOS 10.15.3) with only NAT network interface connected, applied all available updates, run the script mentioned above and it works. The weirdness in api-gateway logs is that the following message is repetitive. ```auto setting up automatic reload on host IP address changes for DNS names: mender-useradm mender-inventory mender-deployments mender-device-auth mender-device-adm mender-gui ``` [Here](https://github.com/mendersoftware/mender-api-gateway-docker/blob/d7ec3200ff6d2c100e817a19d1860b5b70b95319/entrypoint.sh#L88) in api-gateway entrypoint script this `echo` which prints the message and there are no any loops, so, it should not repeat. Can you try stop everything by `./demo down` and then in one terminal tab run the following: ```auto docker run -it -p 8888:80 openresty/openresty:1.13.6.2-0-alpine ``` and in another terminal tab execute: ```auto curl -X GET http://localhost:8888 ``` And post the output from both terminals in addition to `dmesg` output. ---
**Author:** ![0lmi](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/0lmi/32/133_2.png) [@0lmi](https://hub.mender.io/u/0lmi)\ **Post date:** [February 18, 2020, 11:30am UTC](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414/24 "2020-02-18T11:30:26Z")
I have suspicious that this is happening because `sse4_2` CPU instruction is missing. The issue is described in official openresty github project - [here](https://github.com/openresty/docker-openresty/issues/39). Symptoms are the same - container exits with 132 code. So, let’s check by executing above commands and if this is the case then the case is just in the CPU, and it has nothing to do with VirtualBox, network configuration, docker, Mender, etc… ---
**Author:** ![Kris](https://avatars.discourse-cdn.com/v4/letter/k/82dd89/32.png) [@Kris](https://hub.mender.io/u/Kris)\ **Post date:** [February 18, 2020, 8:04pm UTC](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414/25 "2020-02-18T20:04:23Z")
@0lmi I am absolutely speechless. I think that is absolutely the problem and thank you so much for your help. The `docker` command does return 132: ``` karl@mender-test:~/integration-2.2.1$ sudo docker run -it -p 8888:80 openresty/openresty:1.13.6.2-0-alpine karl@mender-test:~/integration-2.2.1$ echo $? 132 ``` And `dmesg` snip shows the same opcode error: ``` [688.851186] traps: openresty[3560] trap invalid opcode ip:7f986ae17448 sp:7ffe09c479b0 error:0 in libluajit-5.1.so.2.1.0[7f986ae0f000+277000] [689.326609] docker0: port 1(veth7b49596) entered disabled state [689.328498] vethd100f45: renamed from eth0 [689.397711] docker0: port 1(veth7b49596) entered disabled state [689.402546] device veth7b49596 left promiscuous mode [689.402551] docker0: port 1(veth7b49596) entered disabled state ``` Seriously though, great catch, never would have expected that. [Previous page](https://hub.mender.io/t/unable-to-start-on-premise-demo-server-per-getting-started-instructions/1414.md?page=1)