Pixelbook Revisited: Running Docker Containers – Hacker Noon

Image result for golang docker
Go and docker is a really nice combo. I’m not using any Go in this article but it’s a cute image 🙂

A couple of months ago I’ve written about my experiences setting up a development environment in the Google Pixelbook. Back then the Linux (beta) feature was only available in the development channel, but nowadays this feature has been released on the stable channel as well.

While I did manage to write some decent amount of code on the Pixel, some system update killed my VS Code installation. I was able to launch the application, but the window just didn’t render… looking at the logs the application seemed to be working though, but in a “headless” state.

I don’t have the skills to debug it further, so I almost gave up. But since the feature I’ve needed was released in the stable branch I decided to power wash the device and start over again, this time on the stable channel.

Just as a side note: before resorting to that I’ve also tried to run the Pixelbook in developer mode, but I didn’t like the user experience at all. Every time I started XFCE it messed completely my resolution and colors on the Chrome OS, making switching between both worlds impracticable. If you have different experiences regarding that please let me know.

After the power wash I’ve setup the VS Code and Go binaries again. I won’t repeat the steps here, but you can refer to my previous article or the official website for the step by step:

This time I went a little further and installed Docker as well. Here I document my experiences.

First add the Docker repository (output omitted for brevity):

$ sudo apt-get update
$ sudo apt-get install 
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository 
"deb [arch=amd64] https://download.docker.com/linux/ubuntu
$(lsb_release -cs)

Then install Docker:

$ sudo apt-get update
$ sudo apt-get install docker-ce

Everything should be working right now, so we issue a docker run hello-world to test the installation:

$ sudo docker run hello-world
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "could not create session key: function not implemented"": unknown.
ERRO[0000] error waiting for container: context canceled

Ooops! It seems that we may have a problem!

This changed in the newest versions of ChromeOS… the last time I’ve tried to run docker it worked just fine. With a little investigation I’ve found this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=860565

And this reddit post summarizes the solution: https://www.reddit.com/r/Crostini/comments/99jdeh/70035242_rolling_out_to_dev/e4revli/

I don’t have the background even to pretend I’m actually understanding what this is about, but basically, we are messing with some system privileges here.

The workaround is to launch the Chromium Shell (Ctrl+Alt+T) and unset a blacklisted syscall. After pressing Ctrl+Alt+T you should see the crosh> prompt on a new Chrome tab. Type the following commands:

crosh> vmc start termina
(termina) [email protected] ~ $ lxc profile unset default security.syscalls.blacklist
(termina) [email protected] ~ $ lxc profile apply penguin default
Profiles default applied to penguin
(termina) [email protected] ~ $ lxc restart penguin

If the restart seems to hang, just press Ctrl+C and run it again. It worked for me. 🙂

You may close the terminal afterwards. With those changes you should be able to run docker just fine. At the Linux (penguin) terminal:

[email protected]:~$ sudo docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
For more examples and ideas, visit:
[email protected]:~$

It works!

I’m still missing the Linux post-installation steps to enable running docker without sudo, but I think that’s enough for taking docker for a spin.

Trying something more serious

So, we have hello-world working, but what does that says about more complex docker environments. Luckily we have a wide range of prebuilt container images to pick from.

Messing around with Apache Spark is something I like to do often so I decided to try the jupyter/all-spark-notebook image. You can just docker pull it as usual:

$ docker pull jupyter/all-spark-notebook
(output omitted for brevity)

And then run the image as:

$ sudo docker run -p 8888:8888 jupyter/all-spark-notebook

For those who are not familiar with docker, the -p parameter will map the port of the container to some port in the host. In this case I’m just exposing the 8888 port.

So here comes the tricky part. I’m running a docker image of Jupyter notebook with Spark support on a Linux container running on Chrome OS. Because of that I was not expecting that hitting http://localhost:8888 on my browser would actually access the Jupyter notebook, but I was wrong:

Please note that for accessing the localhost:8888 interface for the first time you need to pass a token. You may find it at the first lines of the log output from the docker run command. In my case it was:

Regarding the localhost actually pointing to the container, I had the slight impression that this wasn’t working that way a few releases ago, but I’m not 100% sure. Nevertheless, it was a great surprise.

read original article here