| Previous | INDEX | Next |
| Installing Debian | Upgrading Debian from stable to testing |
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:
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.
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.
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.
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.
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.
| Previous | INDEX | Next |
| Installing Debian | Upgrading Debian from stable to testing |
