Updated: Tue, 10 Feb 2004 07:26:02 GMT
|
Updated: Tue, 10 Feb 2004 07:26:02 GMT |
|
This notes are mostly written in real first person style. There are already some clever writings on migration, Redhat related or more general in nature, (see recommended reading below), so I will focus on the (few) gotchas that I have met on my way to a smoothly running kernel.
Generally speaking, migrating from 2.4 to 2.6 kernels is easy - quotation from [3]: "I spent a whole day migrating my GNU/Linux RedHat 9 system to a 2.6 kernel today." Only a whole day? Some people seem to be a lot smarter than I ...
You shouldn't start your first kernel recompile on the occasion of migrating to 2.6 (there are precompiled 2.6 kernels for Redhat to be found in [8]). So it is assumed that you have done a recompile of a 2.4 kernel before.
Some observations after running a 2.6.x kernel for some time now are included further below.
Of course, the latest kernel source from www.kernel.org
or better, from one of the mirrors. You may unpack it with
tar xvfj ~/linux-2.6.X.tar.bz2.
It is a good idea to take a look at
/usr/src/linux-2.6.0/Documentation/Changesthen where the neccessary utilities and packages for a succesful kernel compile are listed. But I have found out that, on my well trimmed Redhat 9 system, only two items were out of date:
./configure --prefix=/The prefix parameter makes the utilities get installed in /sbin, and 'make moveold' renames insmod, rmmod, modprobe etc. to insmod.old, rmmod.old. modprobe.old. This guarantees that the old style module handling still works when you boot into a 2.4 kernel.
make moveold
make
make install
When you have done this before on 2.4 kernels, there should be only few elements of surprise, although the mechanisms of kernel configuration have completely changed. In the beginning, you should still do
make mrproperbut that's neccessary only once in the the kernel source's liftime.
When you have a working configuration file from 2.4, you can copy it to the upper 2.6 source directory as .config and do a
make oldconfig.This will preserve most settings and will prompt you only for new items. But it's indispensable to go into more details with
make xconfigwhich has a complete new look and feel, and even the good old
make menuconfighas undergone a face-lift. I found both very convenient to use.
You will recognize most items at once, although they have been restructured somewhat (not always to greater clearness, most of the known stuff now is hidden under 'Device Drivers').
I don't want to go into the configuration details - they are well described in [1] or [2]. Items that I have misconfigured at the first trial (and which haven't been preserved by the initial make oldconfig) were:
Device Drivers | Networking Support | IP tables support.
General setup | Support for hot-pluggable devices.
Device Drivers | Input device support | Mice | PS2 mouseas a loadable module. That meant: no mouse (I have a Logitech USB wheel mouse). So I repeat David's warning in capital letters: COMPILE THIS INTO THE KERNEL. Doing so (together, of course, with enabling "USB support' further down the endless 'Device Drivers' menu ) gave me immediate mouse support.
It's only
makeand when you are lazy
make modules_install.
make installNo more 'make dep', 'make modules', 'make clean' ...
The module configuration file now is called
/etc/modprobe.conf.There is a script
/sbin/generate-modprobe.conf /etc/modprobe.confto copy entries from the old modules.conf - it produces a lot of noise. I had to manually change the alias for USB support to read like
alias usb-controller uhci-hcdas this is the new name of the USB module.
As ALSA is the kernel makers' preferred sound system now, you may configure its support in the kernel configuration process (as modules). This is quite straightforward, but there are some extra steps to take apart from this:
/usr/src/linux-2.6.0/scripts/MAKEDEV.snd(I didn't find out if this was run automatically during the kernel install process.)
/etc/modules.confor as this is called now
/etc/modprobe.conf.See the ALSA project homepage for further information.
The new kernel really booted at the first trial, but many things weren't running.
lsmodshowed: no modules loaded at all. This was due to a twist in Redhat's 2.4 version of the startup script
/etc/rc.d/rc.sysinitwhich switched off support for loadable modules (and hotplugging) completely. There are hints how to manually fix rc.sysinit (eg. in [2]), but I found it more convenient to get a complete new initscripts package from [8] Even then, you may do some beautifying fiddling with the script ... but it works.
Most of my post-upgrade issues were USB related, as
I have substantially enlarged my zoo of USB devices lately: a digital camera, a flash card reader ... I will only mention one teaser
(and I dont want to talk about my USB scanner which I had been using for years via the 'scanner' module, now
disappeared with the 2.6.3 kernel):
To make the long story short: Each slot of those multiple readers is treated as one device, so you have to set in your kernel
config:
Card readers are USB storage devices. In order to access them you have to enable the following stuff in your kernel configuration under
the Device drivers | USB support:
- Support for USB
- USB device file system
- USB mass storage support
I don't go into details on how to mount a card reader (see e. g. [9]). What kept
me busy for weeks finally turned out to be kernel related:
USB mass storage devices are treated as SCSI devices, so I knew I had to enable the corresponding modules in my kernel
scsi_mod etc.
But
cat /proc/scsi/scsi
only showed me 'Generic Model: USB SD Reader', but I wanted to have a CF Reader!SCSI device support | Probe alls LUNs on each SCSI device
Now there were all four slots in /proc/scsi/scsi, and I could easily mount my beloved CF card als /dev/sdb1!
[root@kp src]# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.40 seconds =322.47 MB/sec
Timing buffered disk reads: 64 MB in 13.73 seconds = 4.66 MB/sec
The reason: hdparm's dma parameter wasn't set, and it was impossible to enable dma support by
hdparm -d1 /dev/hda
This operation wasn't allowed. Again, it turned out to be a kernel config issue: After setting:
ATA/ATAPI/API/MFM/RLL support |
(you might select a different chipset here, please not as a module, but INTO the kernel) I could enable dma support with hdparm and
finally got these test results:
PCI IDE chipset support | Generic PCI bus-master DMA support | Intel PIIXn chipset support/dev/hda:
Timing buffer-cache reads: 128 MB in 0.38 seconds =336.01 MB/sec
Timing buffered disk reads: 64 MB in 1.84 seconds = 34.71 MB/sec
which meant uncached disk reads got more than seven times faster.
 Search
|
|