Installing Debian on a Toshiba Tecra A10-112

Last update: October 14th 2009
This page provides information on getting Debian working fully on a Toshiba Tecra A10-112. Lenny (testing at the time of writing) was installed initially, and was then 'upgraded' to unstable.


Using the information on these pages, and any files downloaded in relation to this page, is done entirely at your own risk. If your spanking new Tecra goes up in flames, then you have my sympathy, but that's all.

Hardware and Drivers

These are described in more detail later, but summarized here for those just wanting to get something working.

Video - Intel GM45 Express ChipWorks with adjustment
Wireless - Intel Wifi 5000 AGNWorks with adjustment
Audio - Intel 82801I ICH9Works with adjustment
Fingerprint reader - Authentec AES1610Almost works with adjustment
EthernetWorks - Module e1000e picks it up
USB - EHCI and UHCIWorks - adjustment suggested though
Trackpad/Nipple (ALPs)Works - adjustment suggested though
Headphone SocketWorks (once general audio is working)
RFKill SwitchWorks
Card ReaderProbably works
eSATA socketUntested

Basic Installation

I used amd64 Lenny (testing at time of writing) with a network install. I needed to use the ethernet connection - nothing appeared to be available for performing a wireless install.

X was able to start and run, although at a degraded resolution. However, when I 'upgraded' to unstable X stopped working. However, this problem is fixable.

If you're new to Debian/Linux, then you might need to read some background information before tackling all of this install. There are plenty of tutorials out there. I'm only describing getting the hardware working. As a quick reference if you want to move to unstable (I don't think it's necessary):

  1. Edit /etc/apt/source.list so that it contains just:
    deb unstable main contrib non-free
    deb-src unstable main contrib non-free
  2. Get synaptic to reload the sources, mark all upgrades, and then apply the changes.

Kernel Compilation

There was no getting around it - a kernel recompilation was necessary in order to use the built in wireless (note that an extra step was also required for the wireless to work).

As installed, the kernel was version 2.6.26. I knew that I wanted to play with ext4 so I downloaded 2.6.28 from

For those that intend to replace their kernel, i'm providing three options. Only one is really recommended - the full version where you do everything. However, I appreciate that not everyone wants to do this and some are willing to take a risk on a downloaded file from an untrusted website. Hence, the later options.

Full Version

I am well aware that you're not supposed to do all of the following as root. With that said, I did it as root.

  1. Prepared for compilation by downloading a few packages:
  2. Downloaded kernel sources.
  3. Created a working directory /root/src
  4. Decompressed the sources into that directory
  5. cd'd to the new directory
  6. Copied the existing config file, /boot/config-2.6.26-1-amd64, to .config
  7. make menuconfig to make editing the config file easier (mine is available here if you just want to copy that. The following changes were made:
  8. Once the .config file has been written, we can compile: fakeroot make-kpkg --initrd kernel_image kernel_headers.
  9. And then install by going up a directory and doing a dpkg -i on both of the .deb files just created.

Slightly Less Work

Instead of creating the .config file yourself, use mine.

Easy Option

Trouble with this option is that you're downloading unverified kernels. Do so at your own risk - you can't hold me responsible for any damage. If the thought of compiling your own kernel scares you more than the thought of trusting unverified code, then you should download:

And then install them both with dpkg -i. The linux headers may be required if you need to do an out of tree compilation, e.g. with module-assistant

Specific Tasks


The kernel needs to be recompiled in order to have the correct driver. On top of that, the driver requires firmware to be downloaded. Choose the iwlwifi-5000-ucode-5.4.A.11.tar.gz. Once downloaded, untar it, and copy the iwlwifi-5000-1.ucode file into /lib/firmware. I restarted at this point to make sure that it found it and used it correctly.

You'll need to set up /etc/network/interfaces or whatever way you want to configure the network on your system. This task was only about getting the hardware working, not full configuration.

RFKill Switch

This needed no special attention. I tested that it worked by running a ping, and then turning the switch to off. The pings stopped, so that was good enough for me. When turning it on, my simple /etc/network/interfaces meant that the interface did not come back up, but an ifdown wlan0; ifup wlan0 sorted that.


The 'upgrade' to unstable broke what was a working, albeit degraded, X. I'm not sure what my /etc/X11/xorg.conf file looked like before the upgrade, but I know that afterwards it didn't contain much, and that the X server couldn't start because it couldn't work out a valid resolution.

To get X working again required some changes to the /etc/X11/xorg.conf. You can find my modified file here - this can be just copied over yours and gdm restarted with /etc/init.d/gdm restart. However, see the caveats about this file in the next section.

After finding help from another page. It was clear that the driver (xserver-xorg-video-intel) and other settings needed to be set in the xorg.conf. Fortunately, there is no need to recompile the driver. Following a hint I used Xorg -configure to create a basic xorg.conf which I then modified to support the trackpad properly, amongst other things.


My xorg.conf was modified to not only support the video driver but changed the driver for the trackpad to the synaptics driver (already installed as part of the basic installation). Two things to realize about my xorg.conf:

Therefore, if you're going to use it (feel free), then you'll probably be making some changes. Probably the easiest place to find out more about this driver is in the file /usr/share/doc/xserver-xorg-input-synaptics/README, and the corresponding README.alps. The Toshiba has an ALPs trackpad.

A further mouse section was added to allow external mice to optionally be plugged in.

One other change that you may wish to consider is disabling the caps-lock key. I'm not a fan of caps-lock, and i'm not alone. I choose to disable it by moving /etc/gdm/PostLogin/Default.example to just Default, and then adding: xmodmap -e "keycode 66=". This is possibly not the best use because it now doesn't do anything, but for me that's better than the default.


Only a minor changed required to make this one work, but it required instructions. The only thing that's necessary to get audio working is to edit /etc/modprobe.d/alsa-base and add options snd-hda-intel model=toshiba at the end. After a restart (yes, there's bound to be a way avoiding a restart), the sound should be working. I found that the volume was already set to a non-zero value. However, I have been caught out before, so if this didn't work for you, then please check the volume first before wasting your time with anything else.

Headphone Socket

This may seem an odd one because surely, once the audio is working, the headphones are working? Well, no, actually. I've had two other machines (an Acer and a Fujitsu) that could play sound but there was a problem when headphones were involved. The good news is that the Tecra is not like those machines so this didn't require any effort once the audio was working.

Fingerprint Reader

At the time I tried this, there was good news and bad news. The good news is that the hardware works. The bad news is that I couldn't get it to reliably verify my fingerprint so I personally decided to abandon the idea of using it for login. I shall describe here the steps that I took to get to the point of experimentation.

At the time of writing, neither unstable nor the kernel had drivers for the AES1610. The 'experimental' version of Debian does but that sounds much scarier than unstable. In order to get the drivers, and support programs, I downloaded the following source files:


The library libfprint provides the userspace drivers for the fingerprint reader. The fprint_demo program allows you to play around with the reader (quite a nice program actually), and the pam_fprint library would allow the finger print reader to log you in. I didn't play with the pam part.

In order to compile libfprint, some development libraries are required:

After uncompressing the libfprint files it can be compiled with:

The usual compiling as root caveat applies! More instructions can be found here. fprint_demo can be compiled using:

You should now be able to run fprint_demo as root. I found that I couldn't get a reliable verification, a problem that is being investigated. If you still have windows on your machine, then you might be able to help by snooping on the USB traffic.


Just worked.


This just worked but with a slight wrinkle. I've had trouble with EHCI controllers on older laptops so I was interested to see what was in syslog about it. It showed that the UHCI driver was being loaded first and recommended that the EHCI (USB 2.0) driver should always be loaded first. I decided to cheat and compiled the EHCI driver directly into the kernel while leaving the UHCI driver as a module.


PCMCIA, Cardbus, or whatever it's called these days just worked. I tested it by plugging in a USB port card and I could see all of the hub registration messages in syslog.


Bluetooth just worked. I could view the contents of my mobile phone through gnome.


Both hibernation and suspension worked without issue when I tested them. I haven't used them exhaustively, so prolonged use may prove that they don't work as well as when I first played with them. The only issue I noticed after hibernation was that I had lost bluetooth.

Card Reader

I couldn't test the card reader although I believe that it's working. The reason that I couldn't test it was because I only had an Xd card available, and apparently that's not really supported. From the information in that article, and reading through the output of dmesg and lspci, I get a good feeling.


Untested. Couldn't even see an entry in lspci or lsusb for it.

eSATA socket

This wasn't tested conclusively because I tried to test it and I don't know whether the test means that it failed. I took an external drive connector, and an HDD and plugged it in. Nothing happened (no spin-up) so i'm wondering if the drive couldn't take power from the eSATA cable. Maybe it needed an external supply. Hence, I can't say one way or the other.




VMWare Workstation

The following information is no longer relevant, or at least not at the time of writing (14th Oct 2009). I've just changed to lenny as a stable distribution and upgraded to Workstation 6.5.3. I didn't need to do any monkeying around with the vmnet drivers. However, i'm leaving the paragraph in here for future reference.

Getting VMWare working was critical for me, and this is where I had a little trouble. It's working now though, through some help.

At the time of writing, I was testing VMWare Workstation 6.5, on a system running kernel 2.6.28 - there's an issue there. Once vmware has been installed it is unable to use two of its important kernel modules - vmmon and vmnet. The workaround is a little bit scary and my well be unecessary in later version of VMWare.

I shall recap on the original instructions here:

  1. Copy the tar files from /usr/lib/vmware/modules/source into a directory where you can play with them
  2. untar those files.
  3. Go into each of the directories and perform a make. This succeeded for me in all directories other than vmppuser-only. I don't know what this module does but it doesn't seem to have prevented it from working.
  4. The .o and .ko files should now be copied. You can find the .o files in the directory that contains the module directories. Each of the module directories contains its own .ko file. They should then be copied into /lib/modules/`uname -r`/misc.
  5. depmod -a
  6. VMWare can be restarted with /etc/init.d/vmware restart.

There was also a slight problem, some time after installing, that caused the keyboard seemingly mad. This was remedied using the xkeymap.nokeycodeMap trick from the forums.

Contact Information

Files and Links

Valid XHTML 1.0 Strict    Linux On Laptops