> F30.me

My personal place to publish… stuff.

Programming

Virtio consoles on Debian

libvirt with QEMU/KVM supports Virtio consoles, which are paravirtualized serial consoles. This is natively supported by Linux (for the guest system) and unlike with serial emulation, you don’t have to care about stuff like baud rate and bit parameters.

When using virt-install, a Virtio console can be added using --console pty,target_type=virtio. In the libvirt XML format, the result will look something like this:

<console type='pty' tty='/dev/pts/4'>
  <source path='/dev/pts/4'/>
  <target type='virtio' port='0'/>
  <alias name='console0'/>
</console>

The console will be available inside the guest at /dev/hvc0. To be able to actually use it, a TTY has to be spawned on it, i.e. getty has to be started. However, this is not the case by default on Debian (as of Stretch, with systemd).

The Quick Fix

Common wisdom is to manually enable getty, i.e. run systemctl enable serial-getty@hvc0.

This will work, but should actually not be necessary: systemd-getty-generator is supposed to automatically spawn getty for virtualization consoles. Looking at its source code, you see that this includes /dev/hvc0.

Freezing the Boot

After reading this article by Lennart Poettering, one might be tempted to activate the console using a kernel parameter, i.e. adding “console=hvc0” to “GRUB_CMDLINE_LINUX” in /etc/default/grub. However, this will not work and actually freeze the boot process since the kernel apparently cannot find the “hvc0” device.

This is because the Virtio console driver only gets loaded later in the boot process, which means it is not available at kernel start.

The Proper Solution

As it turns out, the reason for systemd-getty-generator not spawning getty is actually the same: systemd generators run pretty early during the boot process; apparently also before the Virtio console driver has been loaded.

The fix for this is to add the Virtio console kernel module to the guest’s initrd. On Debian, this can be done by putting “virtio_console” into /etc/initramfs-tools/modules and running update-initramfs -u afterwards.

After rebooting, you should be able to get a TTY using virsh console. If you want to get boot messages on the Virtio console, you may now also add the “console=hvc0” kernel parameter without freezing the boot (use “console=tty0 console=hvc0” to keep the messages on the graphical console as well).

No Responses

Installing LaTeX Winfonts on Linux or OS X

The Windows default fonts like Georgia or Verdana aren’t completely bad and still mark today’s standard for lots of applications. Sometimes, one might have the crazy idea of wanting to use them in LaTeX – be it because style rules dictate it, or because one just likes their look.

For this purpose, the “Winfonts” package exists, but it only provides installation instructions for Windows and is not installable through TeX Live. So this guide will walk you through the necessary steps to use Winfonts with TeX Live on Linux or OS X. Read on…

1 Response

Some graphics on Git

While preparing a beginner course on Git for my job at noris network, I was looking for graphics to point out some tough topics: The relationships between working copy, index and repository and between local and remote branches. Unfortunately, I couldn’t find anything satisfying – this here seemed to be the closest it would get to me imaginations.

So I fired up Inkscape and created some images myself. They of course simplify things and I’m not a great graphic designer, but they helped me at making my point. And, as I hope, they might also be useful for you when explaining concepts or understanding yourself.

Therefore today, I am releasing the graphics under the Creative Commons Attribution-ShareAlike 3.0 Germany license. You should attribute to „Felix Dreissig, noris network AG“ as author if you use them. The images are partially based on Tango icons, which are in Public Domain.

Basic branching

(There are a lot of similars to that one out there, I admit.)

Git Branching

Download SVG

Repository/Index/working copy

This attempts to demonstrate the differences between the three areas. Changed or new files are marked in red.

Git Repo/Index/Working-copy

Download SVG

Remote/Local

That one features a remote server and a development machine. The latter keeps an exact copy of the server’s branches, plus some local branches.

Git Remote/Local

Download SVG

3 Responses

(oh-my-)zsh key bindings on Ubuntu 12.10

After upgrading my Ubuntu system to the 12.10 beta recently, I experienced some strange quirk in my shell related to the oh-my-zsh key bindings: The up-line-or-search feature on arrow-up (resp. down-line-or-search on arrow-down) had ceased to work. One could still browse the history using the arrow keys as that seems to be zsh’s default configuration, but the “search history for commands beginning with the first word I entered” feature didn’t work anymore.

I figured out that Ctrl+V reported the key code ^[OA for arrow-up, while the other tools I checked (namely cat and bash) still returned the ordinary ^[[A. At first I guessed that this behavior had to do with Ubuntu’s upgrade to zsh 5.0, but then some help from #zsh on freenode pointed me into the right direction:

Debian’s /etc/zsh/zshrc (and therefore Ubuntu’s as well), which is executed for every shell in addition to your personal .zshrc now contains those crucial lines:

if (( ${+terminfo[smkx]} )) && (( ${+terminfo[rmkx]} )); then
    function zle-line-init () {
        printf '%s' ${terminfo[smkx]}
    }
    function zle-line-finish () {
        printf '%s' ${terminfo[rmkx]}
    }
    zle -N zle-line-init
    zle -N zle-line-finish
else
    # ...
fi

In general, it seems to be a good idea to put the terminal into “application mode” before executing zle, at least you can find code like that in some other zshrcs as well. I still don’t entirely understand what this is about, but some information about terminal modes can be found here. What’s important to know in order to understand the above snippet is that by outputting the smkx or rmkx codes, you enable or disable application mode.

Application mode, however, uses different key codes which don’t match the hardcoded ones from oh-my-zsh. I finally solved the issue by replacing the oh-my-zsh arrow key bindings with this:

bindkey "${terminfo[kcuu1]}" up-line-or-search
bindkey "${terminfo[kcud1]}" down-line-or-search

(Debian’s /etc/zshrc conveniently stores the codes in an associative array called keys, but I didn’t wanna rely on that.)

There might be more key bindings which are affected from the problem, but I only noticed it for the arrow keys in daily usage. In my opionion it is bad style to use hardcoded key codes for the bindings in the first place and this is something that should be fixed by oh-my-zsh. I’m even a bit surprised why I couldn’t already find a patch or at least a bug report – if I manage to find enough time, I’ll definitely do that.

Update: Heres’s my pull request targeting the problem. What I wasn’t aware of (even though there’s a comment describing it right above the relevant lines), is that the reason to enable application mode at all is making use of terminfo. Ironically enough, you have to make sure application mode is really active (using some code similar to the above one), if you want to fix the problem that it causes. After all, however, you get a cleaner and more portable configuration.

4 Responses