Reviving GULEEK i8 with broken Display with Headless Magic and Arch Linux


In February 2016, one of my Maker friends in Jakarta, Indonesia pointed me to an offer of an all-in-one PC too hard to pass up. It was a GULEEK i8 with Intel Quadcore Atom processor (Baytrail), 2 GB Ram, 16Gb ssd, built-in battery, 2 USB 2.0 Ports, micro sd-card reader, Windows 8.1 pre-installed. The whole package sold for incredibly low $70 a piece.

I was not so sure that Windows 8 would perform well on this, so I did a little Internet research and found a couple of people successfully running Linuxes on these machines. I thought these might make great powerful replacements for some of my Raspberry Pis. Especially, if I would not need graphics and ran them headless -- what did I know what I asked for there - see below.

We purchased 3 pieces of this, they arrived two weeks later. My friend tried to upgrade one of them to Windows 10, but had trouble due to space limitations. I installed Ubuntu on the other two (after making a backup of the disk to be able to go back to Windows), having only to replace the 64 UEFI boot loader with a 32 bit one. However on one of the two remaining GULEEKs the Display started to fail - it was just not possible to get an HDMI-out signal anymore. There are several instances in the net where this is described (search for guleek i8 no display), but no consistent solutions. The problems also seem to be not Linux specific, so it seemed to happen in Windows too (I restored my windows image, but to no effect - not sure if it really booted up again though).

Usually it is suggested to try to connect the failing GULEEK to different screens, let the internal battery drain, and connect another day to check again. And I have to admit on some random occasions my display came back, but it was lost very quickly again soon after. So, I was forced to find a solution to drive this device headless.

Fortunately I had a version (with a blue and not a red power led) which seemed to be stable to use as a reference for typing things blindly.

Recently I lost - due to an update to Ubuntu 17.04 - access to this one machine, so I had to boot it from a rescue image. But how can you select to boot from a rescue image if you cannot get any display output on such a machine? The solution was using a default USB-Ethernet adapter, typing some things blindly, and booting from an arch-linux install cd.

To boot from an external device, try to do the following:

  • Make sure the GULEEK is powered off (you might have to disconnect everything and press the power button for approximately 20s until the power led is off)

  • Attach a simple but verified working USB-hub with a USB-Ethernet adapter and a USB keyboard attached to one of the USB ports of the GULEEK and USB-Stick with a flashed arch install image to the other. Make sure the keyboard and USB stick have LEDs so you can get at least some feedback. Compare with the initial image in this article.

  • Press power on button until the power led turns on and keyboard leds all flash on, continue quickly to next step.

  • There are now two possibilities to get into the rescue system, try and see, which one works:

    1. Via boot menu:
    • Directly start pressing F7 repeatedly (for about 7s, this should enter the boot menu)
    • Press up, up, return (sometimes also: up,up,up,return)
    1. Via bios menu:
    • Directly start pressing del repeatedly (for about 7s, this should enter bios menu)
    • Press left, up, up, up, return
  • Wait for numlock light to turn off (activity led on usb stick should flash a lot before that, then no activity for a while). If you can monitor your router/DHCP server, wait to see that an IP was requested.

  • Now press the following (stuff in square brackets is comment, ignore):

    • return [confirm welcome menu]
    • return [confirm another menu]
    • 9 [select exit to shell]
    • return [go to shell]
    • 3
    • return [enter first password, it will be 3]
    • 3
    • return [confirming password]
  • Now check your IP from router or guess it and ssh myip -l root

  • Enter 3 as password.

  • Hopefully you are now in the arch rescue system

  • Use fdisk -l and mount /dev/mmblk1p3 (last number might vary) to access existing data or partitions.

  • You can also follow the Arch Installation Guide to install here Arch from scratch. Don't forget to install openssh and enable ssh access (create authorized_keys in .ssh with correct permissions) to have access later.

Another option is to use a 32-bit version of the system rescue CD, this could even allow you to gain access just via serial USB.

After you have installed a base system, I highly suggest to enable at least one tty to login via serial, this helps if something with the network goes wrong. This is described here:

Careful, you really have to try to connect with 9600 or 38400 baud. If you want to connect with 115200 baud, you have to build your own systemd service file as described here:

If you happen to have a real FTDI serial USB adapter, you can even enable serial at the EFI-prompt. For this you need the following 32-bit efi drivers:

  • FtdiUsbSerialDxe.efi
  • TerminalDxe.efi

Create a file startup.nsh with approximately the following content:

echo Activating serial terminal
load fs0:\efidrv\TerminalDxe.efi
load fs0:\efidrv\ftdi.efi
echo Serial terminal activated.
echo Loading Grub

Copy these to the root and into an efidrv directory on the ESP partition and use efibootmgr to select with the -n option a one time boot to test-boot into the built-in shell.


Guleek now in the eHomeDemonstrator 3, running router, gateway, and media-center (kodi) software

As you see in the picture, I attached to my now headlessly installed machine a Display Link driven USB display (an old 7 inch MiMo Monitor). It basically just works, but might have to be enabled via xrandr or arandr (to switch away from the broken intel display output). Something like this should do the trick:

xrandr --output HDMI2 --off --output HDMI1 --off --output DVI-I-1-1 --mode 800x480 --pos 0x0 --rotate normal --output VIRTUAL1 --off --output DP1 --off

You can use any old monitor with the adapter I linked below.

Inspite of these hassles, I still think these machines are still a tremendous value for money. If you are interested in picking one up (only seeing a slightly more expensive successor offered at the moment) and supporting me, please click on the affiliate links below.

Let me know if you want to read more like this and share your ideas in the comments.

Nice but Powerful Command Line Editors as Alternatives to Vi and Emacs


Lots of Linux beginners face at one point or the other the problem that they have to change a small configuration inside the command line. There is no Notepad, IntelliJ, Eclipse, and not even Gedit or Kate available here.

And very often the default is vi (or it's iMproved version vim). Vi has an edit and a command mode - and starts in the latter. Therefore, most beginners will experience an extreme amount of anxiety when they cannot edit anything nor even exit the program.

On the Raspberry Pi, people usually suggest to use nano instead of vi - some people try Emacs, but also in emacs, the usage feels very unusual, if you are used to the rich GUI editor experience. I do not want to start a flame war here - I have used Emacs myself in my young years and abandoned it it after destroying my perfect configuration (Emacs makes you love the possibility to customize it for your unique specific needs) the second time during an upgrade. And no, at that there was no git yet to keep nicely track of your configuration changes (yes there were rc and cvs, but this is for another post).

I recently stumbled upon Spacemacs and tugged it away for taking a closer look later at it. It turns out to be a heavily configured version of Emacs adding a lot of Vim features to Emacs and lessening the customization effort and wish going along with Emacs. However, all Vim, Emacs, and Spacemacs have still an extremely steep learning curve and do not transfer to anything else in the editing world or back from it. They come though with lots of tempting features - especially interesting for developers, web designers, and bloggers. They also run basically in any type of command line. Even on Android under Termux they provide a powerful command-line editing and development environment on your phone. As I vowed to be more active on my techblog, I wanted a nice command-line-edit way to give me quick and powerful editing support in all the environments where I could potentially write. And yes, I actually often like to edit in the command line. My quick and always available editor is mcedit, which is part of Midnight Commander. Midnight Commander is a very powerful file manager for the command line and even if it is inspired by the Norton Commander dual panel interface from the DOS ages, my systems students still seem to appreciate it as a very easy to use exploration and file management tool today. It happens to come with a built in editor, which very well supports keyboard and even mouse and touch input and has syntax highlighting. Not much more, but very often that is all I need. It is part of nearly all Linux distributions (on Debian, Ubuntu, Mint it is just a sudo apt-get install mc; mc away) and for accessing the editor, you can then type mcedit at the command line.

However, Midnight Commander and respective mcedit as well as nano had a little too few features for making me happy in all my command line editing tasks. Therefore, I started to look for alternatives. Of course, I took another look at vim and emacs, but I am still not feeling comfortable to recommend these to everybody. That's why I was looking for something nicer and easier to learn. I was especially interested in syntax highlighting and extensibility and support of macros or external tools. I also wanted them to be still in development and having some kind of community support.

Three candidates stuck out: ne, the niceeditor, micro, and kaaedit.


ne or nice edit is actually really easy to use. It is very easy to open up the menu (press F1 or alt-M) and look up powerful commands to edit. Most Linux distributions and also cygwin include it, so it might be as easy as sudo apt-get install ne to get it. It does not support mouse input like mcedit (and later micro), but of course this should not be the major focus of a command line editor. It does syntax highlighting and allows to create macros with an inbuilt recording function. It feels very natural to use, I wish I saw a way to add spell checking to it. Unfortunately, it does not support restructured text as highlighted text. Because of its availability I think this should definitely be a consideration for replacing nano.


micro claims to be "a modern and intuitive terminal-based text editor". And, I can confirm this is spot on. It is not part of any major Linux distribution yet, but it comes as a relatively easy to install static binary (which you can also compile yourself). You basically can just copy it (as root) to /usr/local/bin and are ready to go. It supports syntax highlighting, normal editing commands, mouse input and selection, F1 brings you to a quick start screen for telling you that you can exit with ctrl-Q and access advanced commands with ctrl-E and a tab command extension. After using it for a couple of minutes, editing feels very natural and you forget that you are actually in a command line environment. It supports very nice color schemes and overall has a very clean and streamlined feel to it. You can write powerful plugins in the LUA programming language and there is support for compiling and running your programs. There seems to be easy support to add command completion, but I did not test this yet. I did though not find any on the fly spell check in here - maybe it can easily be implemented by a plugin. I will keep a close look for command completion and that as I have the feeling that it should come very soon - I would definitely consider switching every command line editing to micro, when spell checking would be available. Like ne, it also has only very limited syntax highlighting support for restructured text. Functionality wise it feels very similar to ne, but the supporting community seems to be bigger and the whole usage feels a bit more clean than ne.


The other really interesting text editor I found is kaaedit. It feels again very similar to ne and micro but seems to offer a little less in terms of functionality. It is however fully coded in Python and also extensible in Python. This might make it very accessible for a community to provide plugins. Because of these roots it supports of course syntax highlighting for restructured text. No mouse support or spell checking here either.

As a summary, micro made the best impression on me. I would definitely prefer ne to nano and vim (even if vim will have everything from spell checking to syntax highlighting of restructured text - but I still don't see how I would convince a significant amount of people to use it). kaaedit though is really tempting as I have the feel, I could make some changes myself to it and due its already present restructured text support.

This article got much longer than I expected - what can you write about text editors anyway? If you are still bearing with me until here, please feel free to leave your opinion or experience with any of the presented editors in the comments. Also let me know if I have overlooked another nice and easy to use option. Also pless express some encouragement if you want me to take a more in depth look at the gui options or if it would make sense to turn this into a Youtube video.

Here is again a list with all the links:

As I have worked at the same time for comparison with some small lightweight gui alternatives, I should mention at least the direct gui contenders (big advantage: most of them do on the fly spell checking). The honorable mentions for lightweight but still powerful GUI editors are:

  • geany: nearly a full IDE, great plugins, runs even in Windows and one of my favorite small cross platform editor.
  • gedit: small, fast, simple
  • kate: KDE's hidden gem for editing code
  • atom: a new upcoming contender, very extensible,also nearly full die, very active community
  • retext: no on the fly spell checking, but comes with fast preview for Markup languages (markdown and restructured text,which is the base for this blog)

Resources I visited and read for this investigation:

Taming Chrome - Control tabs memory and free space for your work

tab suspender screenshot

Ever seen what a beast Google Chrome has become? I started monitoring that it easily took 2-3GB of my main memory sometimes and was really bogging my system down. Running Android Studio or Pycharm need quite some memory too and things got actually killed by the system once in a while, making me yet again re-consider Firefox.

Firefox never had this issues as it only loads opened tabs, when you re-visited them. You might think having 30-50 tabs open in one browser session is a sign of miss organization, but I like to think it has to do with the fact that I always work on several projects (teaching and 1-2 research projects and recently also blogging again) all opened in different windows.

So isn't there a way to keep all these tabs open without consuming 100-200MB each?

Yes there is, check out the Chrome extension Tab Suspender. And, yes it does the trick, It still consume 200MB for 40 tabs, but that's much better than Gigabyets. The difference browsing with more than 10 tabs is striking. After a while of inactivity in a tab it replaces it with its own link and grayed-out image (see supplied screenshot), you need to click it once to wake it up, should you visit the page again. Everything is stopped on the page and the memory consumption considerably reduced.

If you Google for Tab Suspender, the first hit is actually The Great Suspender. I haven't actually tried it as the last update listed on the Chrome Webstore is from 2015. However The Great Suspender actually is open source and here is its github page. It also has many more ratings than Tab Suspender. Github shows recently filed issues, but no activity on the project since November 2016. So, if you use Tab Suspender, please share your impressions down in the comments.

Issues installing isso as replacement for disqus and how to solve them

Due to extreme trouble with disqus (compare previous posts), I switched my discussion and commenting system to isso.

My server runs at this point Ubuntu 16.04 and therefore you can either use the available isso package (just do apt install isso) or install a newer package from an external source as described here.

Both sources have similar issues: they do install well, but most of the networking and startup related options in the respective configuration options are wrong or described at wrong locations. As the native ubuntu package didn't work for me, I describe here the way how I installed the package from the external source. They ask you to install the key with apt-key add, however as curl falls in a trap downloading the file, and therefore I suggest downloading the file manually with your browser and then install it locally like this:

cat /tmp/downloaded.key | apt-key add -v

You can follow the rest on that page.

Now make sure to have gunicorn installed (apt install gunicorn) and create a file /etc/isso.conf - use this here as a base and configure as described here. Just remember that the local server will always run on localhost, port 8000 independent of what you configure here or in /etc/default/isso.

Make sure that both isso and Nikola either run normal http or both ssl only and let your isso run on a virtual server with a name like comment.yourserver.tdl. In my case isso runs on https over ssl on and my webpage (as you know) on However, as described in a previous post, I redirect now also normal http requests to https. To make this work correctly, you might have to create a valid certificate (you can get a free one and a decent description how on

In Nikola specify COMMENT_SYSTEM = "isso" and COMMENT_SYSTEM_ID = "" (Adjust to your sever!) and recompile your blog.

Start isso with systemctl restart isso, eventually restart your web-server (nginx, apache, or lighttpd) and enjoy comments without spying from a system that you can eventually even debug if some things do not work. now safe - completely via https

As you might have seen, I had a lot of trouble getting disqus back up running for post discussions here on During the related experiments, I also finally went to letsencrypt and folowed the procedure dsecribed there to generate a real certificate for

It didn't work initially, so what finally went well was temporarily disabling my webserver and then running the following:

certbot certonly --standalone -d -d

Then I adapted my nginx rewrite rules - and now you will always access via https. You will also get an idea if somebody eavesdrop or injects information into your connection to my site as the certificate would be marked as insecure.

Enjoy the safety!

Disqus only working for old posts, switch to isso

This is testing the disqus comments, this file was just copied and not generated from a working disqus post. There is something extremely strange happening as comments on my older posts work but not on new posts. It just tells me that it would not load and points me to their installation tutorial with very little documentation and debug options.

I started a discussion thread here, but no answer there in a decent amount of time.

I assume it had something todo with changing my server from Strato to Scaleway and therefore changing my website IP, but this is just guessing.

Suggestions (thanks gour) on the Nikola channel on IRC point me to isso or - however, I am not too happy to put php back onto my own server.

Also thanks to Chris Warrick for pushing me away from yet another weird mailto based discussion system hack.

So, let's take a closer look at isso:

And, even if was not really easy to set-up - some quirks in the documentation and the provided debian packages delayed me a bit, but still much much easier and user friednly than debugging disqus.

We are up and running again, I am looking forward to your comments!