PreviousINDEXNext
Installing DebianUpgrading Debian from stable to testing

Another Debian Install

I was considering replacing my existing Redhat 7.3 system with Debian, but I thought I would perform a trial by trying to install Debian on silver, the machine used mostly by Tom and Sophie.

I used jigdo to download the first two CD's of the stable (woody) release. I then put the first CD into silver's CD driver and booted.

The first problem was that it booted into the Linux 2.2 kernel (I noticed this because there was no option to format partitions as ext3). Hitting the reset button, I tried the help on the CD. Ah, I had to boot with the "bf42" option to ensure the 2.4 kernel was loaded. Everything proceeded smoothly now, until I got to the point of having to choose which modules to load. I had completely forgotten what the network card was, and the motherboard manual gave no clue. Well, as I was booting from CDs it didn't matter too much at this stage; I could always figure it out later. However, the installer then told me that a network card had been detected, and did I want to configure it via DHCP? Yes, I did. I began to suspect the install on silver was not going to be especially easy when the DHCP failed. Maybe it was because the card wasn't really detected after all...

The Linux disk system was set up as follows:

      Filesystem           1K-blocks      Used Available Use% Mounted on
      /dev/hda8               381139     63128    298333  18% /
      /dev/hda9              7874528    157540   7316972   3% /home
      /dev/hda10             7874528     32828   7441684   1% /opt
      /dev/hda11             2972716    838560   1983148  30% /usr
      /dev/hda12             1968588    556384   1312204  30% /usr/local
      /dev/hda13              980308    122472    808040  14% /var
      /dev/hda14              482217      8244    449074   2% /tmp
    

On the first install reboot, I found two problems: the first was that USB was generating timeout errors and error -110. The light on the USB mouse went off as soon as the USB modules were launched. The second problem was that the network card (an RTL8139C) was being detected, with the 8139too driver bolted into the kernel, but networking was simply not working. DHCP failed, as did setting a hardwired IP address in the /etc/network/interfaces file - just lots of network timeout errors. I decided to concentrate on the network card first; I could always plug the mouse into a PS/2 port as a temporary workaround until I could understand what was happening with the USB drivers.

Googling didn't reveal much help on the network card problem. It seemed the driver had been reworked and renamed between 2.2 and 2.4 (from rtl8139 to 8130too) and the advice was to ensure that you modified the /etc/modules file appropriately. However, I also stumbled on www.scyld.com, Donald Becker's site (now swallowed by Penguin Computing), where he was none too complimentary about the changes wrought in the 8139too driver. His (or is it Scyld Computing Corporation's?) website offered an alternative driver. Hmm, maybe if I downloaded his version and compiled it against the woody kernel, I could use it instead of 8139too and everything would be wonderful.

I downloaded pci-scan.c, rtl8139.c, pci-scan.h and kern_compat.h onto a ms-dos formatted floppy and transferred the files to silver. The command to compile the files is suggested as follows:

gcc -DMODULE -D__KERNEL__ -O6 -c driver.c  -I/usr/src/linux/include  \
    -include /usr/src/linux/include/linux/modversions.h

I had no kernel source on the system, but there were Linux header files in /usr/include/linux. However, if I tried to compile with that directory as the -I argument, no linux/modversions.h was found.

OK, I guess I needed to put the kernel source onto silver before I could compile the rtl driver source. I used apt-get to install the kernel source from the Debian install CDs:

apt-get install kernel-source

Apt-get dumped a bzip'd tar file into /usr/src (helpfully, it also gave me bzip2 to uncompress it). I extracted the source into /usr/local/src. Sadly, in /usr/local/src/kernel-2.4.18/include/linux, there was no modversions.h file.

It appears that the linux/modversions.h file is built as part of the kernel compilation. As I suspected I was going to have to re-compile the kernel anyway to remove the offending 8139too driver from the kernel, this was not really a problem. I decided to try the Debian way of compiling, documented in the installation manual. Firstly, one must install the packages kernel-package and fakeroot using apt-get:

apt-get install kernel-package fakeroot

These were in addition to the kernel-source package I had apt-get'd earlier.

Now I had to configure the kernel, but I didn't fancy working on the kernel using the console. I hadn't got X working yet; the nv driver I had assumed would work against the graphics card (Creative 3D Titanium, based on a Nvidia GeForce 4 chipset), didn't. Furthermore, I still had no mouse because of the USB problems. The hardware side of the mouse seemed simple; plug it into the PS/2 port using a USB to PS/2 adapter. Now, I had to persuade X to use the PS/2 port rather than USB. I ran dpkg-reconfigure xserver-xfree86 to let me configure X again, this time choosing the basic VGA graphics driver, and the PS/2 port for the mouse (guessing that it was the /dev/psaux device). This time X started. Now I needed a better driver for the graphics card (oh, and a window manager). In searching for suitable drivers, I found an article which suggested that the VESA driver might work as a temporary expedient. Putting VESA in as the graphics card driver, and setting a depth of 16 worked just fine. The next step was to install Windowmaker from the CDs. Now I had a working X setup.

I configured the kernel using make xconfig, ensuring configuration of loadable modules support and USB, but omitting all Ethernet card drivers. Next step was to clean the source tree and reset the kernel-package parameters, by:

make-kpkg clean

The kernel is compiled by a command of the form:

fakeroot make-kpkg --revision=silver.1.0 kernel-image

The argument of the --revision switch sets the name used in the resulting .deb file, which is created in the parent directory of the kernel source code.

Before installing the newly created kernel, I tried compiling the pci-scan and rtl8139 modules, using the command shown above, but amended for my kernel location, e.g.:

gcc -DMODULE -D__KERNEL__ -O6 -c pci-scan.c  \
    -I/usr/local/src/kernel-2.4.18/include \
    -include /usr/local/src/kernel-2.4.18/include/linux/modversions.h

These compiled without problems, so I went ahead and installed the new kernel with:

dpkg -i kernel-image-2.4.18-silver.1.0_i386.deb

The Debian way makes rebuilding and installing a kernel fairly painless. Compare with the normal Linux method.

The reboot was fine and, somewhat unexpectedly, the USB errors had disappeared - maybe both problems had fixed themselves at the same time. Once the system was up, I used insmod to load the pci-scan.o and rtl8139.o modules; the rtl8139 card was detected OK. Now the acid test:

ifconfig eth0 192.168.0.80
ping 192.168.0.1

Success - I had a working network card. I installed the modules in the appropriate directory, using the command:

install -m 644 pci-scan.o rtl8139.o /lib/modules/2.4.18/kernel/drivers/net

The module names were placed in the /etc/modules file and rebooted. Yep, still worked.

The remaining tasks to get silver to a good state are:

DHCP support

I edited /etc/network/interfaces to mark eth0 as a DHCP interface, then issued the following commands to bounce the interfaces:

ifdown -a
ifup -a

No DHCP address was assigned. It seems that dhclient (the standard under Debian) needed the options CONFIG_FILTER=y and CONFIG_PACKET=y in the kernel. I checked the .config file in /usr/local/src/kernel-2.4.18 and sure enough CONFIG_FILTER was not set. I set this flag via make xconfig, recompiled and installed the kernel (and modules) and rebooted. This time dhclient worked and a DHCP address was assigned.

USB Mouse support

Well, I'm not sure how, but this 'just works' (TM). I discovered that my son had reconnected the mouse to the USB port, and I didn't even notice. Upon investigation of the /etc/X11/XFConfig-4 XFree86 configuration file, it seems that two mouse devices were configured; a "Configured Mouse", which was set as the /dev/psaux device, and a "Generic Mouse", set for /dev/input/mice. This probably explains why the mouse could be swapped between ports and still work.

For reference, the following modules are required to support a USB mouse in Linux:

mousedev
hid
input
usb-uhci (or usb-ohci)
usbcore

If you find that /dev/input/mice gets "no such device" errors, yet it exists, make sure mousedev is loaded.

Nvidia driver for XFree86

The woody version of the XFree86 server was 4.1, which is relatively old (current is 4.3 at the time of writing). However, the Nvidia-provided driver was noted as working from 4.0.1 onwards, so it was a simple matter to download the install package from the Nvidia website and perform the installation as per the README file instructions.

Creative Audigy support

I swiped the latest version of ALSA off their website, (drivers, libraries, utilities and tools) and built them using the instructions from the website. The Creative Audigy is supported by the emu10k1 driver, which is explicitly requested during the ./configure stage:

./configure --with-cards=emu10k1 --with-sequencer=yes;make;make install

There was a problem in building the utilities, as these required the ncurses library, which according to ./configure was not present. After some digging around on the web, I found that the missing package to load was libncurses5-dev. Once this was installed, all the ALSA modules built OK.

The instructions seem to be incorrect on one point. They state that for versions of ALSA before 0.9.4 you should run ./snddevices, found in the drivers directory. The version I had downloaded was 0.9.8, but running alsamixer produced the error "no such device". I therefore ran ./snddevices which fixed the problem.

I tested the card using aplay to play a .WAV file. That worked fine, but I could not get CD sound from the card using xmcd. The sound was coming out of the jack in the front of the CD fine, and the CD was connected to the card using a molex cable for analog sound. It even worked in Windows 2000.

At this point, I decided to back out the ALSA drivers, and try the emu10k1 driver I found via a link on the Creative OpenSource web-site (website now longer exists). I downloaded the emu10k1 driver and tools from their Sourceforge home, followed the install instructions, and now playing of WAV files and the CD player both work.

Coda - 8139too Ethernet card driver

During the kernel configuration and builds, I decided to include the 8139too RTL8139 driver as a module, to see if the issue was solved by the (probably) unpatched version of the 2.4.18 kernel I was now using. Sure enough, the 8139too driver worked fine, and dhclient was also quite content. I'll stick with the 8139too module on Debian for now, as this causes less hassle when updating the kernel.

PreviousINDEXNext
Installing DebianUpgrading Debian from stable to testing