Wayland is Painful for VNC.

So in setting up Ubuntu 17.10 on a remote server, you might naturally wish to set up VNC on your box because let’s face it, monitor connectivity is at a premium and command-line wizardry, while amazing, isn’t the best way to go for everyone.

Something to consider is that As of 17.10, the default display server is Wayland. Wayland’s great for a default user experience, but for VNC (As well as other screen sharing apps) it is an absolute trainwreck. In fact, for the upcoming 18.04 LTS release in April XOrg will end up becoming the default display server again- you can read more about the rationale here.

So what’s a VNC user to do? Well, you have two real options.

First option is to straight up remove the Wayland session. There’s info on that here, which I haven’t tried but assume it isn’t far off from working.

The second option is to use a shell that relies on XOrg, such as xfce, and use that as your GUI on the box.  Here is a pretty solid article on how to set that up.

Something you need to keep in mind is that VNC, by default, is really not that secure. With an 8 character password max, several glaring flaws in managing it at scale, and so on- actually, let me just drop this, a link to an old but still incredibly relevant blog post on why VNC can be a minefield.  A good practice with VNC is to force localhost only connections to the service, which requires SSH tunneling.  Please do this, even if in a home environment.
Please.  Think of Bob Barker.

Kimchi can give you heartburn…

So, what you might notice if you try to load up one of the latest OSes as a guest in Kimchi is that you get an error.

“Error KCHIMG0001E while creating template: “physical block size is 2048 bytes, but Linux says it is 512 bytes.”

Thankfully, this is a quick fix and already patched but not yet in stable as of the time of this writing.

Here is where the issue is discussed, and the patch can be found in this commit:


Once you apply the patch appropriately and restart wokd, Kimchi should work appropriately.

Eat your Kimchi.

As is relatively unfashionable these days I decided to stand up a little box on my own network to tinker with. I figure I can use it to run a few different things, spin up new VMs to learn, tear them down when I need to.

For the hypervisor I went with KVM. You, dear reader, might be asking yourself “Why”? Well, first I’m a cheapskate and didn’t want to pony up for any sort of hypervisor solution. Second, I figured it was probably the better choice in the war between XEN vs. KVM, at least to try for now.

Now, you can run KVM more or less bare are get away with it, but I wanted a way that I could easily manage VMs. Enter Kimchi, which is an HTML5-based management tool for KVM.

Mise en Place

So from my system’s trusty command line, I did the old two-step shuffle of taking an Ubuntu 17.10 instance and updating it.

sudo apt update
sudo apt full-upgrade -y

Once we’re up to date, it’s time to look into To get a hold of Kimchi and Wok, we run the following commands to get their deb files.

wget https://github.com/kimchi-project/kimchi/releases/download/2.5.0/wok-2.5.0-0.noarch.deb
wget https://github.com/kimchi-project/kimchi/releases/download/2.5.0/kimchi-2.5.0-0.noarch.deb

Also, we need to get a hold of Gingerbase, which is made by the same people who do Wok and allows for some basic remote host management (Patching, etc.).

wget http://kimchi-project.github.io/gingerbase/downloads/latest/ginger-base.noarch.deb

Now, you *can* get a hold of Ginger (Which adds more management capabilities) if you want, but you don’t have to and I’m not going to blame you if you don’t.

wget http://kimchi-project.github.io/ginger/downloads/latest/ginger.noarch.deb

Something very handy about apt (And something not a lot of people realize) is that it can be used to resolve dependencies of deb files pulled down from elsewhere- assuming of course your repos have the dependencies. Anyway, instead of using dpkg, then forcing apt to fix broken across all of these, there is a simpler way to go through installing these. So let’s dive in.

Installing Wok

Installing Wok is dirt simple. Because of some issues with nginx and Wok initially firing off with the install, I’m going to recommend the following:

sudo apt install nginx -y
sudo apt install ./wok-2.5.0-0.noarch.deb -y

Once it’s installed (Dependencies and all), go ahead and start the service.

sudo service wokd start

Installing Gingerbase

Next up, Gingerbase. Gingerbase is required for Kimchi, but thankfully installation couldn’t be easier.

sudo apt-get install ./ginger-base.noarch.deb -y


Once that’s installed, go ahead and reboot. We’ve probably caught kernel updates etc. from doing an update and full-upgrade previously, so now’s as good a time as any.

sudo shutdown -r now

Kimchi, it’s the main course

Your box back up? Good. Now let’s pile on Kimchi. Go ahead and run the following.

sudo apt install ./kimchi-2.5.0-0.noarch.deb -y
sudo service wokd restart

After this finishes up, we need to add a firewall rule to Ubuntu’s firewall setup as otherwise nothing’s getting out.

sudo ufw allow 8001/tcp

After everything is said and done you should be able to access your instance by going to https://INSTANCE_IP_HERE:8001/


If it looks like this, you are probably good to go!

Topping it off with ginger

So if you want to extend the features of Gingerbase and add the capability to start/stop services via Wok (Among other things), you can install ginger. Just go through the same process we did before.

sudo apt install ./ginger.noarch.deb -y
sudo service wokd restart

If it complains about the wokd service having changed, do the following-

systemctl daemon-reload

Then restart the service.

Afterward you get a whole mess of features that you may or may not need, but I leave that for you to decide.