Tip: Set the keyboard layout in virt-builder

Compared to setting the language of a guest setting the keyboard layout of a guest in virt-builder is a relative piece of cake.

In CentOS you can use the nice Perl-based virt-builder file editing feature to edit the appropriate configuration file:

virt-builder centos-6 \
  --edit '/etc/sysconfig/keyboard:
            s/^KEYTABLE=.*/KEYTABLE="uk"/'

Any line in the file matching KEYTABLE=... is replaced by KEYTABLE="uk". This works by running the Perl expression (s/.../.../ above, but full Perl programs are possible) on the guest file (/etc/sysconfig/keyboard) and uploading the result.

Debian is also simple:

virt-builder debian-7 \
  --edit '/etc/default/keyboard:
            s/^XKBLAYOUT=.*/XKBLAYOUT="gb"/'

Fedora requires that we run a program, localectl(1). Unfortunately localectl requires that dbus is running (for good reasons, but in this case it’s unhelpful), so we can’t just use --run-command to run it while building the guest because libguestfs doesn’t run a dbus daemon. Instead we’ve got to schedule the command to run at first boot, like this:

virt-builder fedora-20 \
  --firstboot-command 'localectl set-keymap uk'

Should virt-builder try to hide all this complexity behind a nice, simple --keyboard option? It’s something to consider.

It would be nice if distros could be more standardized too. I’m suspicious of requiring a program to be run in order to change what ought to be a pure configuration file setting. (If your objection is that other programs must be informed when the configuration changes, then dbus could provide a way to monitor when configuration files change, implemented using inotify.)

3 Comments

Filed under Uncategorized

3 responses to “Tip: Set the keyboard layout in virt-builder

  1. Running localectl isn’t really ‘required’, but it’s recommended.

    The problem is that there are two main system-wide sources of keyboard configuration, which use different configuration files, configuration styles, and sets of keyboard layouts. (This is, of course, idiotic, and everyone involved will breathe a huge sigh of relief when kmscon makes it not true any more, and we can stop hacking up icky abstraction layers).

    /etc/sysconfig/keyboard was part of our old abstraction layer over the two of them, which still involved running a program, you just didn’t necessarily know it was going on: system-setup-keyboard ran at boot and tried to keep things straight. The ‘new’ design of abstracting over the two keyboard configuration layers just arranges things a bit differently and makes the ‘bit of code that tries to keep things in order’ more prominent – instead of editing a config file that the program then parsed away from your attention, you call the program directly.

    So, all that really happens when you run localectl, depending on precisely what options you pass it, is that it edits /etc/X11/xorg.conf.d/00-keyboard.conf to set the xkb configuration, and /etc/vconsole.conf to set the console configuration. If you’re willing to familiarize yourself with all the necessary intricacies of how each of those config mechanisms works, and stay up to date with any changes, you can poke those two config files directly instead of invoking localectl.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s