Difference between revisions of "Installing Debian Lenny on a ThinkPad T60"

From ThinkWiki
Jump to: navigation, search
(Use dash for init scripts)
(Start gdm first)
Line 624: Line 624:
 
. . .
 
. . .
 
</pre>
 
</pre>
 +
Which I got by running
 +
<pre>
 +
mv /etc/rc2.d/S30gdm /etc/rc2.d/S06gdm
 +
mv /etc/rc2.d/S05loadcpufreq /etc/rc2.d/S10loadcpufreq
 +
</pre>
 +
You may have to do things differently if you have other services running or if for some reason you need something to start before gdm. In any case, make sure you know what you're moving around before you do it lest you break some delicate order of dependencies and make your system unbootable.
  
 
===bootlog===
 
===bootlog===

Revision as of 04:10, 15 January 2008

Debian Lenny on a T60 6371-6NU

You might also want to check out Debian Etch on a Thinkpad T60 HowTo and Installing_Debian_Lenny_on_a_ThinkPad_T61.

In case you can't decode the Thinkpad model number above, here are the specs (I've left out modem, infrared, cardbus since I haven't ever used them):

Processor Intel Core 2 Duo (Merom) 1.83GHz
Graphics Adaptor Intel Graphics Media Accelerator 950
Display 15.4" TFT display with 1200x800 resolution (widescreen)
RAM 1 GB PC2-5300 (upgraded to 2GB)
Harddisk 120GB 5400 RPM Hitatchi HTS54161
Audio AD1981HD HD Audio 1.0 controller
Ethernet 82573L Gigabit Ethernet Controller
Optical LG-Hitatchi HL-DT-ST DVDRAM GSA-4083N Dual Layer DVD+/-RW
Wireless Atheros AR5418
Biometric STMicroelectronics Fingerprint Reader

I'm going to do everything in Linux (i.e. assume that you already have a running linux version running somewhere else).

Installation

These are instructions for getting the most customised, minimal base Debian system running. As such, you can probably go with your gut and ignore some of these steps for example using the "expert" install mode or deselecting all but the base system packages.

  1. First of all, get the "businesscard" cd image for amd64 if you want to run 64 bit or i386 if you want 32 bit. Note that flash now works in 64 bit(see this article on the "debian adminstration" blog), java is possible, but a little trickier (see below). If you do however go 64 bit you won't be able to use proprietary 32 bit modules in your kernel. Most notably, ndiswrapper won't work with 32-bit windows drivers.
  2. Burn the cd image to a cd with the command
    cdrecord -v debian-testing-amd64-businesscard.iso
    You may find that you need to add dev=/dev/cdrom (or whatever your burning device is) to the above command.
  3. Now stick in the newly burned disc and reboot.
  4. At the "boot:" prompt type "expert (you could also just hit enter, but you won't get as much control over what's about to be installed on your computer).
  5. Go through the install menu using my answers as outlined below as a guide. You will obviously want to tailor things to your specific situation:
  • Choose Language
    • Choose Language:
      English
    • Choose a locale:
      en_CA (stick with ascii for the default since UTF screws up some terminals)
    • Choose other locales to be supported:
      en_CA.UTF-8
      en_GB.UTF-8
      en_GB
      en_GB.ISO-8859-15
      en_US.UTF-8
      en_US
      en_US.ISO_8859_15
  • Select a Keyboard layout
    • Type of Keyboard:
      PC-Style
    • Keymap to use:
      American English
  • Detect and mount CD-ROM
    • Modules to load:
      <none> (deselect usb-storage, its not needed unless your using a external USB CD drive to read the install disc)
  • Load installer components from CD:
    • Installer components to load:
      <none>
  • Detect network hardware
    • Modules to load:
      <none>(I don't imagine you'd need usb-storage here either unless you were using a USB networking device)
  • Configure the network
    • Auto-configure DHCP:
      yes
    • Hostname:
      <omitted>
    • Domain Name:
      <omitted>
  • Choose a mirror of the Debian archive
    • Protocol for file downloads:
      ftp (might be a tiny bit faster than http, though the latter is less likely not to work if you're behind a draconian firewall. http is also slightly easier because you get a list of available mirrors whereas with ftp, you have to know the address already)
    • Debian archive mirror hostname:
      mirrors.kernel.org
    • Debian archive mirror directory:
      /debian
    • FTP proxy information:
      <blank> (unless you're behind one of the draconian firewalls mentioned above, in which case figure out the proxy to use from your network administrator.)
    • Debian version to install:
      testing
  • Configure the clock
    • Set the clock using NTP?:
      yes
    • NTP Server to use:
      ntp.ubc.ca (though the default provided or any other you prefer should work just as well.)
    • Select your timezone:
      Pacific
  • Detect disks
    • Modules to load:
      <none> (again not necessary unless you want to install onto a USB drive)
  • Partition Disks
    • Partition Method:
      manual
    • This depends largely on personal preference, and needs, but here's how I set up the disks:
      200MB EXT3 /boot
      1.0GB swap
      15GB XFS /
      2GB XFS /var
      All remaining disk space XFS /home
      I use XFS because this tends to be faster than ext3. Reiserfs is also a good alternative but takes a little longer to mount at bootup. Grub has some problems reading XFS, so I use ext3 for the /boot partition. If you're keeping your windows partition, just leave it alone, we'll get to that in a bit. Once you're done setting things up select "Finish partitioning and write changes to disk.
    • Write chages to disk?:
      yes
  • Install the base system
    • Kernel to install:
      linux-image-2.6.22-3-amd64 (or whatever newer one is available by the time you read this).
  • Setup users and passwords
    • Enable shadow passwords:
      yes (duh)
    • Allow login as root:
      yes (unless you're really paranoid)
    • Root password:
      <omitted>
    • Create a normal user account now?:
      yes
    • Full Name:
      <omitted>
    • Username for your account:
      <omitted>
    • Password:
      <omitted>
  • Configured the package manager
    • Use non-free packages:
      yes (unless you have some restrictions ideological or otherwise)
    • Services to use:
      security updates
      volatile updates
  • Select and install software
    • Participate in package usage survey?:
      yes (why not help make Debian even better?)
    • Choose software to install:
      It's up to you to decide whether you want to select go with the default Desktop environment, Laptop and Standard System or just install a bare bones system and deal with it later. I will assume however that you have selected none of them in the remainder of this howto.
  • Install GRUB boot loader on hard disk
    • Install GRUB 2:
      no (for some reason it doesn't work)
    • Device for bootloader installation:
      /dev/sda (unless you have some other bootloader you want to use to chain to GRUB).
    • Grub password:
      <omitted> (don't make this your root password as it ends up in your menu.lst file as plaintext).
  • Skip LILO (unless you like pain)
  • Debconf priority:
    • Prompt at or above:
      critical (I want to be able to automate updates)
    • Finish the installation
    • Finish the installation

The First Boot: getting the ball rolling

If you went with the bare-bones system in the package selection above, you should boot up to a commandline login prompt (X-Windows hasn't been installed yet). Log in as root. It's now time to install the packages necessary to get things running. You'll find that thanks to the business card installation, you have an up to date system (i.e., aptitude update&& aptitude dist-upgrade won't find any packages needing upgrade. So lets get on with installing all the packages necessary to get things looking a little more like home.

First of all, there are a few things even in the base system that you probably won't need so get rid of them:

aptitude purge nano pcmciautils tasksel tasksel-data vim-common vim-tiny

Of course, you'll want to keep pcmciautils if you plan on using antiquated pcmcia cards. Similarly you may want to keep vim and/or nano if you use those editors. If on the other hand, you're like me, you don't and you'll then want to

aptitude install emacs

Now if you're like me and you're craving a windowed multitasking work environment before you go any further, you can just do

aptitude install xorg gdm <your favourite window manager (e.g. gnome or openbox)>

Now do a

/etc/init.d/gdm start

And you should get a login screen.

Xorg.conf

Ah, the infamous xorg.conf. Luckily, since you're running Debian lenny on an Intel integrated graphics chip, editing xorg.conf isn't strictly necessary. Intel has gone to a lot of trouble to make this as painless as possible. God help you if on the other hand, you got a model with an ATI X1300 or ATI X1400 graphics card. I made a few modifications to the automatically generated xorg.conf that might be of interest.

Horizontal edge scrolling

Edge scrolling has to be my favourite pointing device feature ever, thus I find it rather annoying that it is only half enabled by default. In particular you'll find that though vertical scrolling works like a charm, horizontal scrolling along the bottom of the touchpad doesn't work. Additionally, I find that the default threshold edge distance to initiate scrolling is a little on the large side for my slender fingers. I also find that the corner button emulation tends to be accidentally activated while using edge scrolling so I disable it. Thus, I have updated the relevant input device section to make use of some of the options documented on the Synaptics Touchpad page

Xinerama

There is also the issue of using dual monitors. You'll be surprised to find that it "just works" if you have an external monitor plugged in. Well, it kind of "just works" if you like having the displays that is. If, on the other hand you want to expand your desktop, you can either do the configuration on the fly with XRandR, or make it permanent by making the appropriate modifications to xorg.conf

Configuring the package manager

The best thing about Debian is the package manager. Thus, you want to make sure it's configured optimally to get the best use out of it before you go any further. Once you're logged in, you can edit the /etc/apt/sources.list file so that it can find more packages than the default. Below is my sources.list file.

# testing - lenny
deb ftp://mirrors.kernel.org/debian/ lenny main contrib non-free
deb-src ftp://mirrors.kernel.org/debian/ lenny main contrib non-free

# stable - etch
deb ftp://mirrors.kernel.org/debian/ etch main contrib non-free
deb-src  ftp://mirrors.kernel.org/debian/ etch main contrib non-free

# unstable - sid
deb ftp://mirrors.kernel.org/debian/ sid main contrib non-free
deb-src ftp://mirrors.kernel.org/debian/ sid main contrib non-free

# experimental
deb ftp://mirrors.kernel.org/debian/ experimental main contrib non-free
deb-src ftp://mirrors.kernel.org/debian/ experimental main contrib non-free

# security updates
deb http://security.debian.org/ lenny/updates main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free

You'll notice that I've also included entries for etch and sid in addition to experimental. If you use a different mirror than mirrors.kernel.org, you'll want to make sure that it hosts the experimental branch. This is where we'll find the package for the fingerprint reader. I include stable and unstable for completeness in case there are packages I want that that are only available in unstable, or if I want to revert to a version of a package in stable. Note that the order you specify the branches in the sources.list file makes no difference, thus in order to maintain priority for lenny packages (over sid or experimental which in general have newer packages), I also have an /etc/apt/preferences file with pin priorties:

Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 300

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 600

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 200

Package: *
Pin: release o=Debian,a=experimental
Pin-Priority: 100

Basically this is saying that unless I specify otherwise, "testing" (lenny) packages are to be preferred over "stable" (etch) over "unstable" (sid) over "experimental". A lower Pin-Priority means lower precedence. If you want to override this precedence, you can either use the aptitude gui and select a specific version to install or add the flag -t <target branch> to your aptitude install <package> command. If you do this in such a way as to select a package that has a newer, higher priority alternative available, it will be upgraded next time you do an aptitude upgrade unless you pin that particular package version (see the relevant section of the apt howto).

Now that we have that sorted out we should do an

aptitude update

If by some chance you get an annoying message like

W: GPG error: <servername> <branch> Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: You may want to run apt-get update to correct these problems

(especially annoying because it happens when you run apt-get update as well), the solution is to run the following command:

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 07DC563D1F41B907 && apt-key add /root/.gnupg/pubring.gpg && aptitude update

where you of course replace "07DC563D1F41B907" with what ever public key you get in the orginal GPG error message. Now of course, the reason this is happening is to ensure your security. You don't want to be downloading packages from unknown or forged sources, so don't just go verifying keys willy nilly without thinking about why you might be getting such a message. In particular, if the message appears even though you haven't recently changed your mirror, something fishy might be going on.

Installing Packages

You might notice that even once you have your favourite window manager running, you're still missing quite a bit in terms of software beyond the basic operating system.

Essentials

Here are a few highly recommended packages:

acpi-support a set of scripts intended to respond to acpi events such as Fn-_ key combinations.
apt-file allows you to search file names in uninstalled pacakges
aterm a lightweight terminal
cabextract extract files from windows installation executables
colordiff like your old friend diff for identifying dissimilarities between files, but easier on the eyes
cpufrequtils init scripts to setup cpu frequency scaling at boot
cupsys cups print server (you'll need it if you want to print)
dash a light weight bash-like-shell (use it for your init scripts or anything else you want to speed up)
deborphan find unused packages
defoma Debian font manager - makes activating fonts easier
emacs-goodies-el like it says, nice addons for emacs
flashplugin-nonfree yep, it works on 64 bit
gimp Opensource gui image editor rivalling Photoshop in power, quality and comprehensiveness.
gv Ghost View for viewing .ps documents
hdapsd Daemon to stop the disk if the accelerometer detects shocks.
ia32-sun-java5-bin 32 bit java 5 (with plugin)
iceweasel Rebranded Firefox web browser
ifplugd monitors the hard-wired Ethernet and brings the interface up or down automatically depending on link presence.
imagemagick Command line image editor and conversion utilities unrivalled in batch processing power.
laptop-mode-tools Reduce power consumption by reducing hard disk use while on battery
less command line text reader with backscrolling
libpam-thinkfinger used to get the finger print reader running
libtrash Universal trash can diverts file removal from any program using libc6 so deleted files wind up in ~/Trash
localepurge Clean up documentation in unused languages.
menu Manage system-wide menus
msttcorefonts Microsoft fonts
ntfsprogs mount your windows ntfs partition read/write
ntp daemon to regularly syncronise system clock with network time servers
ntpdate used to do one-off on-demand syncrhonisation with network time servers
openoffice.org open source productivity software
prelink optimises share libraries for better program load performance
sleepd automated sleep daemon
mlocate periodically indexes the file system for fast searching
smartmontools monitor harddisk health
sysv-rc-conf ncurses gui to activate and deactivate init scripts
ttf-bitstream-vera bitstream vera true type fonts
ttf-dejavu dejavu truetype fonts
ttf-freefont free truetype fonts
unrar extractor for the archive format popular among hackers
unzip extractor for the winzip archive format
wpagui gui for the wireless wpa supplicant
wpasupplicant the wpa supplicant backend
xfsdump for backing up mounted xfs filesystems
xpdf for viewing pdf files

To install all of the above:

aptitude install acpi-support apt-file aterm cabextract colordiff cpufrequtils cupsys dash defoma deborphan emacs emacs-goodies-el flashplugin-nonfree gdm gimp gv hdapsd ia32-sun-java5-bin iceweasel ifplugd imagemagick laptop-mode-tools less libpam-thinkfinger libtrash localepurge menu msttcorefonts ntfsprogs ntp ntpdate openoffice.org prelink sleepd mlocate smartmontools sysv-rc-conf ttf-bitstream-vera ttf-dejavu ttf-freefont unrar unzip wpagui wpasupplicant xfsdump xorg xpdf

Recommended

Then there are a few package I like that you may also want to check out depending on your preferences/habits.

alsamixergui nice mixer app
arping like ping, but gives you mac address if its available
bc arbitrary precision command line calculator (good for scripting)
bmon command line network bandwidth monitor
css-mode css syntax for emacs
devilspie Watches for new xwindows matching configured parameters and acts on them. Very powerful.
dmz-cursor-theme Make your cursors a little easier on the eyes
equivs for making "ghost" packages to satisfy dependences for example when you compile something from source
ftnchek check Fortran syntax
gawk extended version of awk
genisoimage create cdrom ISO's before burning them.
gkrellm performance monitoring gui
gkrelltop plugin for above showing top resource consuming processes
gkrellmwireless plugin for above showing wireless signal strength
gparted graphical partition manager
gphotofs for mounting digital cameras
grip excellent cd ripping functionality using cdparanoia backend
gsl-bin binary files for powerful scientific computing library
gsl-ref-html documentation for powerful scientific computing library
gtkguitune guitar tuner gui with oscilloscope-like interface
hdaps-utils for reading and visualising the accelerometer output
html-helper-mode enhanced emacs html syntax
ibritish british flavour of ispell
id3v2 id3v2 (and v1) mp3 tag reader and editor
k3b powerful cd/dvd burning gui
lastfm preference based internet radio and social networking
libgsl0-dev powerful scientific computing library headers for compiling your own code
libsox-fmt-all audio file formats for sox, the command line audio player/recorder
lsdvd view the contents of a video dvd
lshw show comprehensive list of system hardware and specifications
lsof display currently open files (good for figuring out what the hell is going on)
mp3gain losslessly normalise mp3's
mp3rename rename mp3's based on id3 tags
mutt powerful terminal-based email client
myspell-en-gb british myspell (used by open office)
nfs-common for mounting nfs drives
nmap for probing open ports locally and remotely
nxml-mode xml syntax for emacs
obconf configuration gui for openbox
offlineimap sync imap folder so you have a local copy accesible when no internet is available
openbox versatile lightweight window manager
openssh-server allows remote login
pbzip2 make full use of the dual core when bzipping things.
post-el emacs email syntax intended for use with mutt
powertop see what's causing your processor to wake up and use more battery power
pypanel lightweight configurable panel
qiv quick image viewer good for slide shows
rsync efficient remote and local copying. Copies only differences and ssh for secure communication
samba windows file server/client software
screen powerful detachable/reattachable terminal interface
smbfs allows mounting of windows shares
sox command line audio recording and playing utilities
sshfs allows mount of remote trees on ssh server machines with no special remote configuration
sux su that passes proper Xauthority
sysstat command line system monitoring
udftools tools dealing with the filesystem common in optical media
unclutter hide of mouse cursor when its not being used.
unison keep local and remote filesystems in sync using the rsync protocol and ssh
urlview open urls in mutt with your favourite browser
wbritish-huge large british words list
whois detailed domain querying command
wmctrl control window manager from the command line
wodim command line cd buring (successor to cdrecord)
xclip command line x clipboard tool feed standard input into clipboard, extract clipboard to standard output.
xmms x multimedia system winamp-like mp3/media player
xmms-cdread read cd's via the digital link rather than rely on that annoying analogue cable
xmms-crossfade for gapless playback
xmms-shell for command line control of xmms
xmms-skins skins for xmms
xosd-bin for writing on screen display messages from the command line
xosview performance monitor gui (key feature is the irq monitor)
xscreensaver locks the screen after inactivity

To install all of the above:

aptitude install alsamixergui apt-file arping bc bmon colordiff css-mode deborphan devilspie dmz-cursor-theme equivs freeglut3 ftnchek gawk genisoimage gkrellm gkrelltop gkrellmwireless gparted gphotofs grip gsl-bin gsl-ref-html gtkguitune hdaps-utils html-helper-mode ibritish id3v2 k3b lastfm libformsgl1 libgsl0-dev libsox-fmt-all lsdvd lshw lsof mkisofs mp3gain mp3rename mutt myspell-en-gb nfs-common nmap nxml-mode obconf offlineimap openbox openssh-server pbzip2 post-el powertop pypanel qiv rsync samba screen smbfs sox sshfs sux sysstat udftools unclutter unison urlview wbritish-huge whois wmctrl wodim xclip xmms xmms-cdread xmms-crossfade xmms-shell xmms-skins xosd-bin xosview xscreensaver

Fingerprint reader

Ok, admit it. This is the real reason you got a thinkpad. Getting the fingerprint reader is surprisingly easy with the new open source thinkfinger driver. This is highly recommended over the binary only driver which I have found is less stable even leading xscreensaver to crash and expose the desktop without a provided fingerprint or password!

If you didn't install it among the packages above, see the relevant section of the howto.

Once you have it installed, you must instruct PAM to use it so that it will ask for your fingerprint when you login with gdm or at the command line (or any thing else that uses PAM). To make it brief and more Debian-specific, you want your /etc/pam.d/common-auth file's only uncommented lines to be

auth    sufficient      pam_thinkfinger.so
auth    required        pam_unix.so nullok_secure try_first_pass

Then you want to enroll the fingerprints of any users as well as also root

tf-tool --add-user <username>
tf-tool --add-user root

This will put the fingerprint patterns in /etc/pam_thinkfinger/<username>.bir. You may also want to make sure you have the uinput module probed by typing lsmod | grep uinput. If not, then probe it (modprobe uinput) and put it into your /etc/modules file to be probed on boot

echo uinput >> /etc/moduleds

Now for the icing on the cake. If you have xscreensaver (>=5.0) or a sufficiently recent version of gnome-screensaver, you can use your fingerprint to unlock the screen as well.

A few /etc configurations

services

By default, you'll probably have a bunch of services running at startup that are going to lengthen your boot time and likely eat up system resources as long as they're running. You can use the sysv-rc-conf utility to enable or disable scripts. The ncurses gui shows each service as a row and each run level as a column. An X indicates that the script or service is activated at that particular run level. An empty space means that it is not. In debian, run level 2 is the regular multi-user mode, while run level 1 is single-user (maintenance mode). Run levels 3-5 are usually identical to 2, but you can customise them otherwise. You generally only want to mess with run levels 2-5 and unless you want to create custom run levels, you want to keep them all identical (i.e., all X's or all blank). And you probably don't want to mess with run levels 0,6 and S at all unless you really know what you're doing. For more on how debian deals with run levels, take a look at the Debian Policy Manual. Below is a table with all of my init scripts in the left column and their state indicated in run level 1 and 2-5 in the adjacent columns. As with sysv-rc-conf, and X indicates enabled, while a blank indicates disabled. Keep in mind that I don't use gnome and as such gnome users might experience negative effect from disabling dbus or hal as I have. I have also completely removed the discover1 package.

aptitude purge discover1
service run-level 1 run-level 2-5
acpi-support
acpid X
alsa-utils
anacron X
atd
avahi-daemon
bootclean
bootlogd X
cpufrequtils X
cron X
cupsys
dbus
exim4 X
fuse
gdm X
hal
halt
hdapsd X
hdparm
hibernate
ifplugd X
ifupdown
ifupdown-clean
killprocs X
klogd X
laptop-mode X
loadcpufreq X
module-init-tools
networking
nfs-common
ntp X
openbsd-inetd
portmap
procps
rc.local
reboot
rmnologin X
rsync
samba
screen-cleanup
sendsigs
single X
sleepd X
smartmontools X
ssh
stop-bootlogd X
stop-bootlogd-single
sysklogd X
sysstat
udev
udev-mtab
udftools
umountfs
umountroot
urandom
vbesave
wpa-ifupdown
x11-common

Use dash for init scripts

Dash is essentially a lighter weight POSIX compliant version of bash. It is supposed to run slightly faster than bash, so it would seem like a good idea to use it to replace bash for executing your init scripts. This can be done simply by replacing the #!/bin/sh or #!/bin/bash line at the beginning of each script with #!/bin/dash. The following script does just that:

#!/bin/sh
# Since the operation takes a second or two, lets check if it's necessary first
head -qn1 /etc/init.d/* | egrep -q '/bin/sh|/bin/bash'
if [ $? = 0 ];then
    echo dashing init scripts
    for file in /etc/init.d/*;do
        sed -i '1 s|#![ ]*/bin/b\?a\?sh|#!/bin/dash|g' $file
    done
fi
exit 0

Even though this is rather quick and easy, you don't want to have to worry about this tweak being undone by future package upgrades. So we add an apt rule in /etc/apt/apt.conf.d/90-initdash:

// Make sure init scripts use dash
DPkg
{
Post-Invoke {"/usr/local/sbin/initdash";};
};

This tells apt to run /usr/local/sbin/initdash (which is where I keep the above script) after each time it invokes dpkg. So any init scripts installed by new packages will get "dashed".

Start gdm first

By default, adding gdm as a service in runlevel 2 creates the symlink /etc/rc2.d/30gdm to /etc/init.d/gdm. This tells init to start gdm in runlevel 2 after all services that are symlinked with prefixes less than 30. In the above enabled init scripts, there's nothing that gdm strictly depends on to start, so why not start it first and get a login while the rest of the bootscripts complete? Below are the first three S## entries in my /etc/rc2.d/ symlink farm.

S05bootlogd     
S06gdm          
S10loadcpufreq
. . .

Which I got by running

mv /etc/rc2.d/S30gdm /etc/rc2.d/S06gdm
mv /etc/rc2.d/S05loadcpufreq /etc/rc2.d/S10loadcpufreq

You may have to do things differently if you have other services running or if for some reason you need something to start before gdm. In any case, make sure you know what you're moving around before you do it lest you break some delicate order of dependencies and make your system unbootable.

bootlog

You'll notice I enabled bootlogd in the above. If you actually want it to work, you must additionally edit /etc/default/bootlogd and make sure that it says:

BOOTLOGD_ENABLE=Yes

This will cause boot messages to be logged into /var/log/boot

hdapsd

Hdapsd is the daemon that monitors the accelerometer and parks the hard disk heads if it detects sudden movement of the laptop. It does however need to be told what to protect. By default it works on /dev/hda, but modern thinkpads use SATA and so this needs to be changed to /dev/sda. This is set in the file /etc/default/hdapsd, where you must change the line DISK="hda" to DISK="sda".

NOTE!
This alone will not enable hdapsd protection. You need to patch the kernel for this as described below

smartd

By default, smartd is not enabled when you install the smartmontools package. To enable it, uncomment only the line

start_smartd=yes

in /etc/default/smartmontools. Don't mess with the line about smartd_opts=, we deal with that in the /etc/smartd.conf file. I modified mine so that the only uncommented line is

/dev/sda -a -d sat -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

I figured there was no point in using DEVICESCAN when I already know that I just want to monitor /dev/sda (the cdrom doesn't have smart). This will probably speed things up. The remaining options tell smartd that the disc is behind a SCSI to ATA translation layer, that it should not spin up the disk to do a check and that it should email root should there be a problem. You can check to make sure the emails get through by adding -M test to the end of that line and restarting smart. Remember to remove it though, otherwise, you'll get an email every time you boot up.

exim4-config

You need to tell exim how to send mail. To do this, type

dpkg-reconfigure exim4-config

and follow the dialogs. To be honest, I have trouble sorting through exactly what I want each one to say whenever I do this. Here are the answers I decided on:

  • Mail sent by smarthost;recieved via SMTP or fetchmail
  • System mail name: The FQDN of my laptop
  • IP-addresses to listen on:127.0.0.1
  • Other destinations for which . . .: same as system mail name
  • Machines to relay mail for: <blank>
  • IP address or host name of outgoing smarthost: (this is the server to which your machine should send outgoing mail) Since my mail server requires an SSL/TSL connection on port 587, I must suffix the server name with "::587". Note the two colons.
  • Hide mail name in outgoing mail: yes
  • Visible domain name for local users: same as mail name
  • DNS queries minimal?:no
  • Delivery method:/var/mail
  • Small files?:no

Then, I edit the file /etc/email-addresses so that it says

<my user name>:my.email.address@server.com

Then I make sure that mail to root goes to me by ensuring that /etc/aliases looks as follows:

# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: <my user name>

and that mail sent to me ends up at my regular email address:

echo my.email.address@server.com > ~/.forward

Finally, since as I mentioned, I'm using SSL/TLS, I have to put my user name and password (for the outgoing mail server) in the file /etc/exim4/passwd.client, which unfortunately must be plain text. The format is as follows:

mail.server.address:username:password

Then I restart exim4

/etc/init.d/exim4 restart

and send some test emails in various contexts:

mail -s 'test from user to user' <myusername>
mail -s 'test form user to root' root
mail -s 'test from user to outside' alternateemail@alternateserver.com
su 
mail -s 'test from root to user' <myusername>
mail -s 'test form root to root' root
mail -s 'test from root to outside' alternateemail@alternateserver.com
exit

and hope all those emails go where I expected them to.

If you run into trouble, check the various subdirectories of /var/spool/exim4. msglog and input should have nothing in them after you've sent emails if everything is working. See if you can't find some error messages that give you some clues in any files that do crop up here.

browser keys

You can make the "back" and "forward" keys above the left and right arrows do pretty much anything you want. Since they generate their own X-events (keycodes 234 and 233 respectively), they can be mapped to whatever keysym you want via Xmodmap. For example, I mapped them to F19 and F20 in my systemwide /etc/X11/Xmodmap file so they are automatically mapped for all users.

keycode 234 = F19
keycode 233 = F20

There are a couple ways you can get Firefox (or rather iceweasel) to correctly recognize these keysyms. You could install keyconfig.xpi and configure the keybindings via Tools->Keyconfig, but this is only user specific and quite frankly just too easy. So I went about doing it the hard way and editing /usr/share/iceweasel/chrome/browser/content/browser/browser.xul. Both are described in detail here.

The latter method has the advantage that paired with the system wide Xmodmap discussed above, all users automatically have working browser keys. The disadvantage (other than having to dig around in a hairy .xml file) is that whenever you upgrade or reinstall firefox, your changes disappear and you have to go back in there and do it again. To mitigate slightly this last problem, I wrote the following script and put it in /usr/local/sbin/firefox-keys

#!/bin/sh
FILE=/usr/share/iceweasel/chrome/browser/content/browser/browser.xul

grep -q VK_F20 $FILE
if [ $? != 0 ];then
sed 's|<key id="goForwardKb2" key="\&goForwardCmd.commandKey;" command="Browser:Forward" modifiers="accel"/>|<key id="goForwardKb2" key="\&goForwardCmd.commandKey;" command="Browser:Forward" modifiers="accel"/>\n    <key id="goBackKb" keycode="VK_F19" command="Browser:Back" />\n    <key id="goForwardKb" keycode="VK_F20" command="Browser:Forward" />|g' $FILE > $FILE.tmp
mv $FILE.tmp $FILE
fi
exit 0

Then I just have to run this script everytime Iceweasel is updated. But wait, that seems pretty programmatic. Isn't there some way to automatically run the script when Iceweasel is updated? The answer is yes. I created the file /etc/apt/apt.conf.d/98-iceweasel-keys and added the following to it

// Add browser keys to firefox if it's being installed

DPkg
{
Pre-Install-Pkgs {"cat > /tmp/pkgs";};
Post-Invoke {"if grep -iq iceweasel /tmp/pkgs && [ $(ps w -p "$PPID" | grep -c remove) != 1 ];then /usr/local/sbin/firefox-keys;else exit 0;fi";};
};

It's kind of hackish, but here's the idea. Whenever apt calls dpkg, it will first call the command listed in Pre-Install-Pkgs passing the names of all the packages as standard input (which get tossed into /tmp/pkgs). Then after dpkg has been invoked and installed everything, the Post-Invoke command is called which checks if any of those packages were Iceweasel. If the case insensitive pattern "iceweasel" is among their names (and the package in question is not being removed rather than installed), the aforementioned firefox-keys script will be invoked. The natural question is why I need this intermediate file. Well for some weird reason apt does not pass the package names to the Post-Invoke commands.

default applications

Right now, the system wide default for the terminal is gnome terminal. This is second only to Konsole in bloat. If you want to keep things streamlined, change the systemwide default to aterm (which you downloaded above).

update-alternatives --config x-terminal-emulator 

And select /usr/bin/aterm-xterm. Now for the browser you're going to want iceweasel (firefox)

update-alternatives --config x-www-browser 

And select iceweasel.

bash completion

It's also nice to have more extended bash completion enabled. This will give you such niceties as completion of man at if you hit tab, or give you suggestions as to what you can ifup. Trust me, if you're going to be using the command line, you're going to want to open up /etc/bash.bashrc and uncomment the lines

# enable bash completion in interactive shells
#if [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#fi

that annoying beep

Ok, so you've hit tab a couple times or directed the emacs cursor off the buffer and have heard quite enough of that pc speaker beep. Here's how you get rid of it:

echo blacklist pcspkr >> /etc/modprobe.d/blacklist

That prevents the module from loading when you boot up. If you want to remove it right now without further ceremony:

rmmod pcspkr

daily defrags

One of the great things about the XFS file system is that it has a defragmenter. I don't however want to worry about running it all the time, so I've added the file /etc/cron.daily/xfs_defrag containing simply

#!/bin/sh
xfs_fsr

prelink

According to the comments in /etc/default/prelink prelinking isn't enabled by default upon instlalling the prelink package. In order to enable it, edit /etc/default/prelink and make sure that

PRELINKING=yes

Build your own kernel (the Debian way)

You may be reluctant to venture into the world of kernel compilation, but it is necessary to get the accelerometer hard disk protection working. Code has to be added to the kernel (don't worry you don't have to write it!) to tell it how to "park" the hard disk heads when hdapsd tells it the laptop is moving around. Hopefully, as this feature becomes more common, it will be built into future releases of the mainline kernel, but for now we must rely on patching the kernel ourselves. There is also something to be said for having a kernel that is tailor matched to your machine. You can cut out a lot of unnecessary stuff and optimise the kernel to your specific system. Thankfully, Debian has eased the burden of kernel compilation and installation with the kernel-package package. The following is heavily based on this howto.

  1. Add yourself to the src group so that you have write access to the /usr/src directory and can do most of the procedure as a regular user.
  2. Install the necessary packages
    aptitude install gcc kernel-package kernel-source-2.6.23 libc6-dev tk8.3 libqt3-mt-dev libncurses5-dev fakeroot
  3. Log out and log back in for the addition to the src group to take affect. You can ensure that this is the case by typing groups and looking for "src" in the resulting list.
  4. As a regular user, get the hdaps-protect patch:
    mkdir /usr/src/hdaps/ && cd /usr/src/hdaps && wget 'http://sourceforge.net/mailarchive/attachment.php?list_name=hdaps-devel&message_id=87pry7ehx3.fsf%40denkblock.local&counter=2' -O hdaps-protect.2.6.23.patch
  5. Now, unpack the kernel source
    cd /usr/src && tar xvjf linux-source-2.6.23.tar.bz2 && cd linux-source-2.6.23
  6. Apply the patch:
    patch -p1 < ../hdaps/hdaps-protect.2.6.23.patch
  7. As a starting point for configuration, you can use the Debian .config file
    su -c 'aptitude install linux-headers-2.6.23-1-amd64'
    cp ../linux-headers-2.6.23-1-amd64/.config .

    This is the recommended route if this is your first time compiling a kernel. Alternatively, you can take a look at mine, which is highly customised to my particular model and you should probably go through yourself to make sure it's not missing anything that you want.
  8. To edit/view the configuration with the "user friendly" gui
    make xconfig
  9. Once you've gotten a suitable configuration
    export CONCURRENCY_LEVEL=3 && fakeroot make-kpkg clean && fakeroot make-kpkg --append-to-version=.mycfg kernel_image
  10. While your kernel is compiling you might take a minute to make it easier on yourself when it comes time to install it. It seems that by default dpkg does nothing special when it installs a kernel package. This is WRONG! If you don't add the kernel to the /boot/grub/menu.lst file, then it will just sit in your /boot directory doing nothing. You can solve this by running update-grub after you install or remove a kernel. One better however is to tell dpkg to do the dirty work for you:
    printf 'postinst_hook=/sbin/update-grub\npostrm_hook=/sbin/update-grub\n' >> /etc/kernel-img.conf
  11. This is also a good time to tweak your boot parameters. One in particular is vga=794 which tells the kernel to display the console at higher resolution that default. To enable this, find the section that looks like
    ## ## Start Default Options ##
    ## default kernel options
    ## default kernel options for automagic boot options
    ## If you want special options for specific kernels use kopt_x_y_z
    ## where x.y.z is kernel version. Minor versions can be omitted.
    ## e.g. kopt=root=/dev/hda1 ro
    ## kopt_2_6_8=root=/dev/hdc1 ro
    ## kopt_2_6_8_2_686=root=/dev/hdc2 ro
    # kopt=root=/dev/sda11 ro
    and change the last line to
    # kopt=root=/dev/sda11 ro vga=794
    That's right, keep it commented. Debian's update-grub command reads the comments and uses them to decide how to format that actual entries further down in the file.
  12. After a little under 10 minutes thanks to some hot dual core action, you'll have a .deb package containing your very own kernel. Just install it as you would any other .deb
    su -c 'dpkg -i /usr/src/linux-image-2.6.23.mycfg_2.6.23.mycfg-10.00.Custom_amd64.deb'
  13. This should handle the painful part for you. You should now be able to reboot and select your custom kernel on your bootloader screen.
NOTE!
If you notice that your kernel is repeatedly spewing the message
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xef
Saying yes to the IDEDISK_MULTI_MODE kernel option under Device Drivers->ATA/ATAPI/MFM/RLL->Use multi-mode by default in the xconfig menu won't solve your problem as the description suggests. This is more likely caused by power management scripts calling hdparm on the cdrom. See below for the real solution.

Wireless with madwifi

I had the brilliant idea of getting the 11n capable ThinkPad_11a/b/g/n wireless adaptor which is really just an Atheros AR5418. In retrospect, I should have gone with a more sensible choice like the Intel Pro which is directly supported in the mainline kernel. I think it's fair to say that Atheros is the ATI of wireless cards in terms of Linux support. It works, but you'll pull your hair out in the process. Since the AR5418 is so new, the latest release of madwifi doesn't even support this card. However the latest subversion snapshot does (though of course only up to 11g).

As you've probably noticed I'm going with a 64 bit system. Thus the more stable ndiswrapper won't work because the windows driver supplied by Lenovo is 32bit only. But don't go thinking that going 32 bit and using ndiswrapper will get you 11n. It won't.

That said, to install the latest snapshot of madwifi, you first need to install subversion.

aptitude install subversion

If you skipped the kernel compilation step above and are using a stock Debian kernel, you will also need to install your kernel headers.

aptitude install linux-headers-`uname -r`

Where "`uname -r`" is of course evaluated by the shell to the currently running kernel version.

Now follow the howto. Pay attention to the note at the end about changing the name of the device to wlan0. This was written by me, so it's fair to assume that you'll encounter the same thing using Debian.

wpa_supplicant

wpa_gui is quite a powerful applications that lets you interact with a running wpa_supplicant in an intuitive way. It allows you to scan and connect to available networks as well as save and delete preferred networks. By default however wpa_gui has to be run as root because only root has permissions to affect wpa_supplicant. To remedy this, ensure that your wpa_supplicant.conf has the global settings

ctrl_interface_group=netdev
update_config=1

near the top of the file. "netdev" is the name of the group which is allowed access to the wpa_supplicant interface and update_config allows you to save changes to your preferred networks. You now need to add yourself to the netdev group so you can run wpa_gui.

adduser <you> netdev

You'll be added to the group after completely logging out and logging back in. The only minor annoyance is that wpa_gui is still located in /usr/sbin which is not in your default path. As such, you might want to create a symbolic link to it in /usr/bin/

ln -s /usr/sbin/wpa_gui /usr/bin/

If you want maximum control over how various wireless networks are setup, you can of course edit wpa_supplicant.conf directly. You can get a comprehensive list of examples by typing the command

zless /usr/share/doc/wpasupplicant/examples/README.wpa_supplicant.conf.gz

Don't bother however putting any comments in the wpa_supplicant.conf file since these will be erased if you have the update_config=1 parameter set as described above.

tp_smapi

tp_smapi is a module that allows you to access various bits of information about your thinkpad generally focused around the battery. It also provides a more up to date driver for the hdaps accelerometer. Here's how to get it running:

  1. Get the source:
    wget http://downloads.sourceforge.net/tpctl/tp_smapi-0.34.tgz
  2. Unzip the source and go into the directory:
    tar xvzf tp_smapi-0.34.tgz && cd tp_smapi-0.34
  3. Build and install it with the new hdaps driver:
    make install HDAPS=1
  4. In order to get the module probed on bootup, just add "tp_smapi" to /etc/modules.
    echo tp_smapi >> /etc/modules
  5. You can find a list of userspace applications that utilise this driver here. I use the gkrellm plugin:
su -c 'aptitude install libgtk2.0-dev'
cd /usr/local/src
wget http://www.ksp.sk/~rasto/gkrellm-thinkbat/gkrellm-thinkbat-latest.tar.gz
tar xvzf gkrellm-thinkbat-latest.tar.gz
cd gkrellm-thinkbat-0.2.2
make install

Configuring ACPI

thinkpad_acpi/enabling hotkeys

First of all, similar to tp_smapi it seems that thinkpad-acpi doesn't load automatically, so put it in /etc/modules as well.
echo thinkpad_acpi >> /etc/modules

If it has somehow found itself installed (as is the case if you selected "laptop" packages in the initial installation), get rid of hotkey-setup. It's totally unnecessary with the new thinkpad-acpi module which captures all the keys just fine.

aptitude purge hotkey-setup

The same goes for tpb. thinkpad-acpi now covers the gap in key-coverage that this previously made up for.

Now to enable some hotkeys. Assuming you have acpid running, you can monitor acpi events by typing

tail -f /var/log/acpid

You'll find that with thinkpad_acpi probed with the default parameters, you get an acpi event for all Fn-F# key combinations except Fn-F7 and Fn-F10. You also get acpi events for Fn-Space, Fn-Home, Fn-End, Fn-PgUp, ThinkVantage, Mute, VolUp, VolDown, Power, Wireless switch on/off as well as lid open/close. You might notice however that the Fn-F4 and Fn-F10 events seem to register for individual keypresses that are sufficiently spaced in time. You can enable an event for Fn-F7, by changing the value of /sys/devices/platform/thinkpad_acpi/hotkey_mask to the value of /sys/devices/platform/thinkpad_acpi/hotkey_all_mask.

cat /sys/devices/platform/thinkpad_acpi/hotkey_all_mask > /sys/devices/platform/thinkpad_acpi/hotkey_mask

To make this permanent, you need to change the mask in /etc/modprobe.d/thinkpad_acpi.modprobe so that the the only uncommented line is

options thinkpad_acpi hotkey=enable,0x00ffffff experimental=1

acpid

The next question you're probably asking is "what do you with all these acpi events?". That's where acpid comes in. Every time the acpid deamon starts up, it reads all the files contained in the /etc/acpi/events directory. These files contain the names of all events that acpi should acknowledge and what to do when they are recieved. The syntax is pretty simple:

event=<name of event>
action=<what to execute upon registering that event>

As noted previously, you can experiment with generating various events by watching the /var/log/acpid file and determining what events go with what key. You might also notice that there are a few events that are generated by other things (like a change in CPU frequency scaling states). By convention the action scripts are all contained in /etc/acpi/. If you write your own, make sure they have the same permissions as all the others. For more info check out the How to configure acpid page. You might also want to check out How to get special keys to work for some attempts at cataloguing some of the events generated. Note that you can change the scripts without restarting acpid but if you change the event files, you need to restart it so that it reads in the modified versions.

Though you can turn acpi events into user-level xevents, the main advantage of using acpi events is that you can use the special keys to execute scripts that require root access (since acpid is run by root). You should also keep this in mind from a security perspective. You shouldn't give too much power to the hotkeys lest you allow someone to do too much without the root password.

dpkg-divert /etc/acpi

You're likely going to want to do a lot of customising of the /etc/acpi/ directory, most of which was originally put there by the acpi-support package. The problem with this is that next time there's an update to that package it's going to want to change back all those changes you made to the distribution defaults. Now the distribution defaults are good for a reference point, but you want ultimate control over how your acpi system behaves and don't want it changing every time that there's a package upgrade. Enter dpkg-divert. This handy utility will allow you to keep the original distribution files and even have them upgraded, but keep your heavily customised /etc/acpi directory safe. Before modifying a file that you will not want subsequently changed by the package manager, you can dpkg-divert it so that future upgrades do not overwrite it.

dpkg-divert --add --rename --divert  <path to file>.dpkg-dist <path to file>

This will move the original file to one of the same name with the .dpkg-dist extension and divert files from any packages to the latter. Now if you want to use the distribution default as a staring point for your modifications, you can just copy it back

cp  <path to file>.dpkg-dist <path to file>

And begin editing.

If you're going to be editing the majority of the files in /etc/acpi, you might want to divert the whole directory. Unfortunately, dpkg-divert doesn't officially divert directories, but here's how you can hack it to nearly do it. First create a mirror acpi.dpkg-dist directory structure.

cd /etc/acpi
find -type d |  xargs -i mkdir -p /etc/acpi.dpkg-dist/{}

Now divert all the files in /etc/acpi to this new directory structure.

find -type f | cut -d/ -f 2- | xargs -i dpkg-divert --add --rename --divert /etc/acpi.dpkg-dist/{} /etc/acpi/{}

Finally copy the distribution defaults back for a staring point to your massive customisation.

cp -r /etc/acpi.dpkg-dist /etc/acpi

The limitation of this of course is that if future versions of the packages have new files in this directory, or if you install new packages that want to put files in here, they will not be diverted, and you will have to add these to your diversions as they appear.

hd power management: laptop-mode

There was a lot of buzz a couple months back about aggressive hd power management shortening the life of drives by excessively parking and unparking the disk heads (note that this is different that what happens with hdapsd). I'm not going to go into the gorey details. You should probably follow the above link and dig around on the web if you're really concerned about this. Suffice it to say, it's a good idea to have an awareness of hd power management an in particular be aware that there is some overlapping functionality between the laptop-mode and acpi-suppport packages and that if you aren't careful, they may even come into conflict.

First of all, you may note that in the above init scripts, I have disabled acpi-support. If you take a look at what that does and follow your nose, you'll find that pretty much the only thing it's doing is running /etc/acpi/battery.d/90-hdparm.sh which sets aggressive disk power management for both hard disk and cdrom if it is detected that the laptop is on batteries at bootup. On the other hand, it sets it less aggressively with /etc/acpi/ac.d/90-hdparm.sh if ac power is detected. You'll also find that there is an acpi event associated with connecting and disconnecting the power which, by default call the script /etc/acpi/power.sh which runs one of the aforementioned scripts according to the new adapter state.

This is probably a good idea in principle. Aggressive power management tells the disks to spin down more often and thereby conserve battery power. Laptop hard disks are designed to do this relatively frequently, but their so-called rated "load-cycle count" is finite falling generally in the 600,000 parks/unparks range. But there is more . . .

For one, it doesn't appear that the cdrom plays well with the hdparm command used to modify the power settings as evidenced by scary looking kernel messages to the tune of

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec

upon even querying the drive with what should be an innocuous request for basic information: hdparm -I /dev/hda. For this reason, it would seem that we don't want to be sending any hdparm commands to the cdrom drive.

Secondly, there is the issue that you might have laptop-mode enabled to to do the same thing and you probably don't want the two doubling the effort, or worse, fighting with each other. Something further to consider is that at the same time as it deals with the level of drive power management, laptop-mode makes an effort not to spin the drive up as often once it's been spun down. It would seem to make sense then, to have both these efforts coordinated by the broader scope of laptop-mode alone. As an added bonus, laptop-mode doesn't touch the cdrom.

So here's how I hand the matter over to laptop mode:

  1. Disable the /etc/init.d/acpi-support boot script with sysv-rc-conf as described above.
  2. Remove, or better yet, divert the files 90-hdparm.sh from /etc/acpi/ac.d and /etc/acpi/battery.d and /etc/acpi/resume.d.
  3. Make sure laptop-mode gets started at boot up with sysv-rc-conf also as described in the init script section.
  4. Enable hardrive power managment from within laptop mode by editing /etc/laptop-mode/laptop-mode.conf so that the line
    CONTROL_HD_POWERMGMT=0
    becomes
    CONTROL_HD_POWERMGMT=1
  5. If you want to be a more conservative with your drive life (at the expense of battery life), you probably want to change the line
    BATT_HD_POWERMGMT=1
    to something more like
    BATT_HD_POWERMGMT=180
  6. Now you can enhance laptop mode to further reduce drive spin up. First, you can have syslog not sync all the time on battery which requires disk write access and consequently spinup. Just run lm-syslog-setup and answer yes to the question of whether or not you want to create the split syslog configuration.
  7. You can crank up the LM_READAHEAD=8192 if you have lots of RAM (don't forget to make sure that CONTROL_READAHEAD=1).
  8. You can set CONTROL_NOATIME=1 to prevent disk writes related to updating file access times while on battery.

This is only the tip of the iceberg for laptop-mode configuration.

sleep

Though you can make your laptop sleep, by simply executing

echo -n $ACPI_SLEEP_MODE >/sys/power/state

The /etc/acpi/sleep.sh script wraps this command in some other niceties that may ease the transition in and out of sleep. In particular, it sources the scripts in /etc/acpi/suspend.d before sleeping and those in /etc/acpi/resume.d after awaking. If you feel uneasy about playing with these scripts yourself, you can alter some of their behaviour by editing the /etc/defaults/acpi-support.

It would seem to make sense to bind the Fn-F4 key with the moon on it to the /etc/acpi/sleep.sh script. You could also set it up so that your laptop goes to sleep when you close the lid. I however prefer to have my laptop remain awake when the lid is closed so that it can continue background tasks such as ripping a cd, downloading a file, compiling a kernel, playing music, etc. I do however want to have some system of going to sleep during inactivity. For this I use the sleepd package which automatically puts the laptop to sleep after a period of inactivity. It does however requires some configuration to make it actually do this.

First of all, if you haven't already installed it, do so

aptitude install sleepd

Now edit the configuration file /etc/default/sleepd. Set PARAMS to the arguments you want to give the sleepd daemon as started by init. You can take a look at the sleepd man page to get an idea of what you might want to put here. As an example, you might have

PARAMS="-u 180 -U 1800 -s /etc/acpi/sleep.sh -i 1 -i 12 -i 23"

This tells sleepd to sleep after three minutes of inactivity while on battery(-u 180) and after half an hour of inactivity while on ac (-U 1800). I have defined "activity" as signals on irqs 1(keyboard), 12(mouse), and 23(usb mouse) (-i 1 -i 12 -i 23). 1 and 12 will be autodetected, but 23 may not be. You can use the xosview utility to discover when the various IRQ's are used. Finally sleepd itself doesn't actually know how to put the computer to sleep, so you have to supply it with the command to do so (-s /etc/acpi/sleep.sh). You could really put anything at all here.

You'll note however, that the above is a rather limited definition of "inactivity". Unfortunately, it's the best sleepd has to offer. Alas, none of the above mentioned background tasks that I want my computer to continue doing can be reliably mapped to the use of a particular IRQ. The next best thing then is to have our sleep command be a script that before putting the computer to sleep checks for a wider range of activity before actually going to sleep and aborts the sleep process if such activity is detected. This will reset the sleepd timer so that it must wait for an other interval of human inactivity before running the sleep/check script again.

There are four checks that I want to do before going to sleep:

  1. CPU activity
  2. Disk activity
  3. Network activity
  4. Is sound playing?

The first three can be checked using the sar utility included in the sysstat package, while the latter can be checked using teh rec utility included in the sox package. If you haven't already, install those packages. Sox is additionally going to need alsa support, so you could install that package, or just go ahead an install off of sox since its a handy program to have the full functionality of.

aptitude install sysstat sox sox-fmt-all

The following script autosleep.sh is intended to be called by sleepd after user inactivity to check for the background inactivity described above. If there is inactivity in these four fronts, it calls the sleep.sh script and puts the computer to sleep.

#!/bin/bash
# autosleep.sh
# Checks if the computer is inactive before going to sleep. Aborts if it looks like 
# there's some action.
#

# Thresholds - these may depend on what you do with your computer and what 
# you want it to stay awake for.
CPUTHRESH=5        # in percent 
DISKTHRESH=500     # in blocks/sec (the sar manpage says blocks are 512 bytes in normal cases) 
NETTHRESH=10       # in kB/s
SNDTHRESH=200      # in ???? rms 
# (no sound playing is ~25 while playing mp3 w/ pcm+master turned all the way to zero is ~250)

# Sample times (in seconds) - again needs may vary
CPUTIME=1   
DISTTIME=2  
NETTIME=2 
SNDTIME=2 


# Check CPU usage defined as non-idle time.
CPU=`sar $CPUTIME 1 | awk '/Average/ { printf "%d\n",100-$8}'`
echo "CPU = $CPU%"
if [ $CPUTHRESH -lt $CPU ];then
    echo CPU is working, not sleeping
    exit;
fi

# Check disk usage (read + write)
DISK=`sar -b $DISKTIME 1 | awk '/Average:/ { printf "%d",$5 + $6 }'`
echo "DISK = $DISK"
if [ $DISKTHRESH -lt $DISK ];then
    echo Disk is working, not sleeping
    exit;
fi

# Check net usage (exclude wifi0 which appears to have activity all the time for some weird reason)
NET=`sar -n DEV $NETTIME 1 | awk '/Average:/ && $2 !~ /(IFACE|wifi0)/ { SUM += $5 + $6 } END { printf ("%d\n",SUM)}'`
echo "NETWORK = $NET"
if [ $NETTHRESH -lt $NET ]; then
    echo Network is in use, not sleeping
    exit;
fi

# Set the mixer to some controlled values and put set it to record the mixed sound output
# This unfortunately is going to be sound-chip specific.
alsactl -f /var/tmp/sound.state store
amixer sset Capture 20% cap
amixer sset Digital 20%
amixer sset Mix cap
# Record to null and use RMS amplitude in resulting statistics with a convenience 
# factor to make it integer
SND=`rec -n stat trim 0 $SNDTIME 2>&1 | sed -n 's/^RMS[ ]*amplitude:[ ]*/1000000 * /gp' | bc | cut -d. -f 1`
# Restore previous mixer state
alsactl -f /var/tmp/sound.state restore
echo "SOUND = $SND"
if [ $SNDTHRESH -lt $SND ];then
    echo Sound is playing, not sleeping
    exit;
fi

. /etc/acpi/sleep.sh

hibernate

Hibernate works with the described setup (my custom compiled kernel in particular) as long as I don't have the uswsusp package installed by calling /etc/acpi/hibernate.sh. I could probably get it to work with uswsusp if I worked at it, but I don't really care since I don't hibernate all that often. Of note, I have the boot parameter resume=/dev/sda2 (my swap partion) added to the kopt= variable in my /boot/grub/menu.lst so that running update-grub appends this option to my kernel:

# kopt=root=/dev/sda11 ro resume=/dev/sda2 vga=792

results in

title		Debian GNU/Linux, kernel 2.6.23-amd64.005
root		(hd0,2)
kernel		/vmlinuz-2.6.23-amd64.005 root=/dev/sda11 ro resume=/dev/sda2 vga=792 
savedefault

The above is also probably unecessary as I have set PM_STD_PARTITION=/dev/sda2 in my kernel config which can be found under Power Management Options -> Hibernation (aka 'suspend to disk') -> Default resume partitoin:.

64-bit headaches

Java

Ok, so Sun is being lazy and though they've made an amd64 java, they didn't bother to make the accompanying browser plugin. So you're left to try and use the 32-bit version that I've included in my package list above. Unfortunately, this won't work in iceweasel as flash does. You don't however have to start mucking about with chroots if you really need that no doubt ridiculous java app to work. Go to the Firefox download site and grab the linux version. Also if you didn't get it with the rest of the packages I recommended above, get ia32-sun-java5-bin. For some reason this trick doesn't work with ia32-sun-java6-bin, it ends up just hanging the browser.

aptitude install ia32-sun-java5-bin

Now go to the directory where you saved the firefox tarball (it can even be in a subdirectory of your home directory), unzip it and put a symlink to libjavaplugin_oij.so in the firefox/plugins directory.

tar xvzf firefox-2.0.0.11.tar.gz
ln -sf /usr/lib/jvm/ia32-java-1.5.0-sun-1.5.0.13/jre/plugin/i386/ns7/libjavaplugin_oji.so firefox/plugins/

Now, you're ready to enjoy all the wonderful java content the web has to offer via your personal firefox installation. First close any iceweasels you have running, then run

firefox/firefox http://www.java.com/en/download/help/testvm.xml

You should see the stupid java guy. Until Sun joins the rest of us in the 21st century, you're going to have to use this firefox to view web-applets. The good news is that the vanilla firefox will seamlessly use the same profile directory as iceweasel. You can even use it as your main browser if you want. There's also this blackdown java I've heard of that has a 64-bit web plugin, but the things I've read about its instability have not encouraged me to go hunting for it.