A blog by Tim Booth of the NEBC. I'll be using this blog to pass on some of my tips for users of the Bio-Linux system (see the first post), and maybe some other useful nuggets that come my way.
Changing the default keyboard on Ubuntu 12.04 Live CD
Posted 10-30-2012 at 08:07 AM by avarus
Hi,
This isn't a user tip - as you can probably see I didn't do very well keeping up on those. Instead here's a rather technical and long-winded commentary about what is going on regarding setting the default keyboard on the Ubuntu 12.04 Live CD, from a British perspective. This is important to me because I use the customised Bio-Linux Live USB stick image for teaching purposes, and I use it in UK academic labs. If the first thing I have to do in each course is to get the students to change their default keyboard then it looks rather unprofessional and it begs the question "If you're such a Linux guru and you made a custom distro why don't you just change the default keyboard?". Well, heck, I AM a Linux guru and I will have my own default keyboard! But it wasn't easy.
First attempt - I looked for advice on https://help.ubuntu.com/community/LiveCDCustomization. This tells you how to change the default language but not the default keyboard. However, an older version suggested this (to be run in the chroot before remastering - if that doesn't make sense to you then you need to read the Ubuntu help page first):
update-locale LANG=en_GB.UTF-8 LANGUAGE=en_GB.UTF-8 LC_ALL=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8
No joy at all. Setting the locale doesn't switch the keyboard and in any case the configuration for the locale is probably managed more appropriately by some package configuration. I'm not sure. Anyway I know I now have the settings I want in /etc/default/locale and yet it makes no difference to the keyboard.
Second attempt - I used the F3 boot menu in Syslinux to set a UK keyboard, which works, then booted up and looked at the resulting boot stanza (handily available in /proc/cmdline). Then I edited txt.cfg in syslinux to try and make this the default. Simple, or at least this had worked previously in 10.04, but this time no joy. The thing I tried to add was:
"keyboard-configuration/layoutcode=gb"
(In Ubuntu 10.04 the equivalent, that actually worked, was:
locale=en_GB bootkbd=gb console-setup/layoutcode=gb)
Third attempt - I noticed that "keyboard-configuration/layoutcode=gb" looks like a debconf setting, so I tried (this time on a live image):
dpkg-reconfigure keyboard-configuration
Ok, this seemed to work. My keyboard was now fixed. So I did it in the chroot and remastered. But no joy. The console keyboard on the VT (Ctrl+Alt+F2) is set correctly to "gb" but the default keyboard in X is still "us". Grrr.
Fourth attempt. After much digging and fiddling and rebooting I realised the following:
(A) If you get an Ubuntu 12.04 live CD and boot it in default mode, then select "try without installing", you get a US keyboard setup in X with a keyboard switcher icon in the top right that lets you select a US or GB keyboard (and 2 others we don't care about). But even booting with a persistent USB stick rather than a CD this setting does not get saved between reboots.
(B) If you interrupt the boot and select a GB keyboard in the Syslinux F3 menu you get a GB keyboard and the keyboard switcher is absent (or, if it appears, shows only the GB option).
If you start off with (A) and, in a terminal in X, run "dpkg-reconfigure keyboard-configuration" to set a GB keyboard you end up in what looks like (B).
If you start off with (B) and run "ubiquity -g --only" you end up with a US keyboard and looking like (A).
Aha - now it starts to make sense. The above ubiquity system is run like this on a default live boot in order to let the user set their language and to present the options for a live session vs. an installation without the user having to see the ugly Syslinux menus. Certain boot-time options set by Syslinux skip this Ubiquity "greeter" dialogue, but if it does run it takes over the keyboard settings. So, is it possible that somewhere in Ubiquity this behaviour is hard-coded??
Indeed it is - and fortunately as ubiquity is Python-based we can dig right in to look. Reading through /usr/lib/ubiquity/ubiquity/misc.py reveals the culprit around line 620. In 10.04, Ubiquity already ran a very similar greeter window on startup and was happy to leave the keymap alone, but since 10.04 it has been tasked with setting appropriate options in the Gnome keyboard switcher, depending on the language selected in the GUI, and the approach is very hacky, with a hard-coded list of default keyboards for different languages. This code runs even if nothing is clicked by the user and, when libgnomekbd receives the new settings via a gsettings call, the first keyboard it selects ends up as default and is activated. So, seeing the hard-coded list, one thing is clear - unless I bypass ubiquity altogether by fiddling the default boot options I'll need to edit this file in some way.
The former option is quite possible (it involves rebuilding the gfxboot module for Syslinux but this is covered in the Wiki above). But then it would also be nice to still have the keyboard switcher because the Bio-Linux distro I'm making has US users, and they have US keyboards. So, the obvious thing is to set the default "en" keyboard to "gb" in the misc.py internal mapping table. Not quite - now I lose the US option entirely and get "Irish". I didn't even know there was a special Irish keyboard (joking aside - http://goo.gl/1lFuV).
Fifth attempt. My final solution is not ideal - one final hack in the misc.py file - but it's good enough for me. I edited the "restrict_list" function so that, just before it returns, if the first and third keymaps are "us" and "gb" it swaps them round and promotes "gb" to the top spot. And this does the trick. The patch looks like this:
# Patch to add my workaround for the keyboard mapping issue.
# Apply with:
# patch -d ~/reconstructor/root/usr/lib/ubiquity/ubiquity/ < fux_misc_py.patch
*** old/misc.py 2012-07-17 21:55:21.000000000 +0100
--- new/misc.py 2012-10-29 18:21:48.000000000 +0000
***************
*** 699,706 ****
--- 699,711 ----
# gsettings doesn't understand utf8
new_variants = [str(variant) for variant in new_variants]
+ #Hack added for Bio-Linux to prefer gb keyboard over us
+ if new_variants[0] == "us" and new_variants[2] == "gb" :
+ new_variants[0] = str("gb")
+ new_variants[2] = str("us")
+
return new_variants
def call_setxkbmap(variants):
kb_layouts = []
I can't see any other way that doesn't either lose the keyboard switcher for US users or involve major re-coding, so this is what I've stuck with.
TIM
This isn't a user tip - as you can probably see I didn't do very well keeping up on those. Instead here's a rather technical and long-winded commentary about what is going on regarding setting the default keyboard on the Ubuntu 12.04 Live CD, from a British perspective. This is important to me because I use the customised Bio-Linux Live USB stick image for teaching purposes, and I use it in UK academic labs. If the first thing I have to do in each course is to get the students to change their default keyboard then it looks rather unprofessional and it begs the question "If you're such a Linux guru and you made a custom distro why don't you just change the default keyboard?". Well, heck, I AM a Linux guru and I will have my own default keyboard! But it wasn't easy.
First attempt - I looked for advice on https://help.ubuntu.com/community/LiveCDCustomization. This tells you how to change the default language but not the default keyboard. However, an older version suggested this (to be run in the chroot before remastering - if that doesn't make sense to you then you need to read the Ubuntu help page first):
update-locale LANG=en_GB.UTF-8 LANGUAGE=en_GB.UTF-8 LC_ALL=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8
No joy at all. Setting the locale doesn't switch the keyboard and in any case the configuration for the locale is probably managed more appropriately by some package configuration. I'm not sure. Anyway I know I now have the settings I want in /etc/default/locale and yet it makes no difference to the keyboard.
Second attempt - I used the F3 boot menu in Syslinux to set a UK keyboard, which works, then booted up and looked at the resulting boot stanza (handily available in /proc/cmdline). Then I edited txt.cfg in syslinux to try and make this the default. Simple, or at least this had worked previously in 10.04, but this time no joy. The thing I tried to add was:
"keyboard-configuration/layoutcode=gb"
(In Ubuntu 10.04 the equivalent, that actually worked, was:
locale=en_GB bootkbd=gb console-setup/layoutcode=gb)
Third attempt - I noticed that "keyboard-configuration/layoutcode=gb" looks like a debconf setting, so I tried (this time on a live image):
dpkg-reconfigure keyboard-configuration
Ok, this seemed to work. My keyboard was now fixed. So I did it in the chroot and remastered. But no joy. The console keyboard on the VT (Ctrl+Alt+F2) is set correctly to "gb" but the default keyboard in X is still "us". Grrr.
Fourth attempt. After much digging and fiddling and rebooting I realised the following:
(A) If you get an Ubuntu 12.04 live CD and boot it in default mode, then select "try without installing", you get a US keyboard setup in X with a keyboard switcher icon in the top right that lets you select a US or GB keyboard (and 2 others we don't care about). But even booting with a persistent USB stick rather than a CD this setting does not get saved between reboots.
(B) If you interrupt the boot and select a GB keyboard in the Syslinux F3 menu you get a GB keyboard and the keyboard switcher is absent (or, if it appears, shows only the GB option).
If you start off with (A) and, in a terminal in X, run "dpkg-reconfigure keyboard-configuration" to set a GB keyboard you end up in what looks like (B).
If you start off with (B) and run "ubiquity -g --only" you end up with a US keyboard and looking like (A).
Aha - now it starts to make sense. The above ubiquity system is run like this on a default live boot in order to let the user set their language and to present the options for a live session vs. an installation without the user having to see the ugly Syslinux menus. Certain boot-time options set by Syslinux skip this Ubiquity "greeter" dialogue, but if it does run it takes over the keyboard settings. So, is it possible that somewhere in Ubiquity this behaviour is hard-coded??
Indeed it is - and fortunately as ubiquity is Python-based we can dig right in to look. Reading through /usr/lib/ubiquity/ubiquity/misc.py reveals the culprit around line 620. In 10.04, Ubiquity already ran a very similar greeter window on startup and was happy to leave the keymap alone, but since 10.04 it has been tasked with setting appropriate options in the Gnome keyboard switcher, depending on the language selected in the GUI, and the approach is very hacky, with a hard-coded list of default keyboards for different languages. This code runs even if nothing is clicked by the user and, when libgnomekbd receives the new settings via a gsettings call, the first keyboard it selects ends up as default and is activated. So, seeing the hard-coded list, one thing is clear - unless I bypass ubiquity altogether by fiddling the default boot options I'll need to edit this file in some way.
The former option is quite possible (it involves rebuilding the gfxboot module for Syslinux but this is covered in the Wiki above). But then it would also be nice to still have the keyboard switcher because the Bio-Linux distro I'm making has US users, and they have US keyboards. So, the obvious thing is to set the default "en" keyboard to "gb" in the misc.py internal mapping table. Not quite - now I lose the US option entirely and get "Irish". I didn't even know there was a special Irish keyboard (joking aside - http://goo.gl/1lFuV).
Fifth attempt. My final solution is not ideal - one final hack in the misc.py file - but it's good enough for me. I edited the "restrict_list" function so that, just before it returns, if the first and third keymaps are "us" and "gb" it swaps them round and promotes "gb" to the top spot. And this does the trick. The patch looks like this:
# Patch to add my workaround for the keyboard mapping issue.
# Apply with:
# patch -d ~/reconstructor/root/usr/lib/ubiquity/ubiquity/ < fux_misc_py.patch
*** old/misc.py 2012-07-17 21:55:21.000000000 +0100
--- new/misc.py 2012-10-29 18:21:48.000000000 +0000
***************
*** 699,706 ****
--- 699,711 ----
# gsettings doesn't understand utf8
new_variants = [str(variant) for variant in new_variants]
+ #Hack added for Bio-Linux to prefer gb keyboard over us
+ if new_variants[0] == "us" and new_variants[2] == "gb" :
+ new_variants[0] = str("gb")
+ new_variants[2] = str("us")
+
return new_variants
def call_setxkbmap(variants):
kb_layouts = []
I can't see any other way that doesn't either lose the keyboard switcher for US users or involve major re-coding, so this is what I've stuck with.
TIM
Total Comments 0
