[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ next ]
None of the python2.X packages that are included with sarge include the standard modules 'profile' and 'pstats', because they are licensed under a license that does not conform to the DFSG (see bug #293932 for details). These two modules can be found in the python-profiler and python2.X-profiler packages that are included in the non-free section of the Debian archive.
The 2.6 kernel series contains major changes from the 2.4 series. Modules have been renamed and a lot of drivers have been partially or sometimes almost completely rewritten. Upgrading to a 2.6 kernel from an earlier version is therefore not a process to be undertaken lightly. This section aims to make you aware of some of the issues you may face.
You are therefore strongly advised not to upgrade to a 2.6 kernel as part of the upgrade from woody to sarge. Instead, you should first make sure your system works correctly with either the old kernel or with a 2.4 kernel from sarge and do the upgrade to a 2.6 kernel later as a separate project.
If you compile your own kernel from source, make sure you install
module-init-tools before you reboot with the 2.6 kernel. This
package replaces modutils for 2.6 kernels. If you install one of
the Debian kernel-image packages, this package will be installed
automatically because of dependencies.
If you use LVM, you should also install lvm2 before you
reboot as the 2.6 kernel does not directly support LVM1. To access LVM1
volumes, the compatibility layer of lvm2 (the dm-mod module) is
used. You can leave lvm10 installed; the init scripts will detect
which kernel is used and execute the appropriate version.
If you have entries in the /etc/modules file (the list of modules
to be loaded during system boot), be aware that some module names may have
changed. If this happens you will have to update this file with the new module
names.
For some SATA disk controllers, the device assigned to a drive and its
partitions may change from /dev/hdX to /dev/sdX. If
this happens, you will have to modify your /etc/fstab and
bootloader configuration accordingly. Unless these changes are made correctly,
your system may not boot correctly.
Once you have installed your 2.6 kernel, but before you reboot, make sure you have a recovery method. First, make sure that the bootloader configuration has entries for both the new kernel and the old, working 2.4 kernel. You should also ensure you have a "rescue" floppy or cdrom to hand, in case misconfiguration of the bootloader prevents you booting the old kernel.
The most invasive change in the 2.6 kernels is a fundamental change of the input layer. This change makes all keyboards look like "normal" PC keyboards. This means that if you currently have a different type of keyboard selected (e.g. a USB-MAC or Sun keyboard), you will very likely end up with a non-working keyboard after rebooting with the new 2.6 kernel.
If you can SSH into the box from another system, you can resolve this issue by running dpkg-reconfigure console-data, choosing the option "Select keymap from full list" and selecting a "pc" keyboard.
If your console keyboard is affected, you will probably also need to
reconfigure your keyboard for the X Window System. You can do this either by
running dpkg-reconfigure xserver-xfree86 or by editing
/etc/X11/XF86Config-4 directly. Don't forget to read the
documentation referred to in Things
to do before rebooting, Section 4.6.
This issue is unlikely to affect the Intel x86 architecture as all PS/2 and most USB keyboards will already be configured as a "normal" PC keyboard.
Again because of the changes in the input layer, you may have to reconfigure
the X Window System and gpm if your mouse is not working after
upgrading to a 2.6 kernel. The most likely cause is that the device which gets
the data from the mouse has changed. You may also need to load different
modules.
For the 2.6 kernel series the ALSA sound drivers are recommended over the older
OSS sound drivers. ALSA sound drivers are provided as modules by default. In
order for sound to work, the ALSA modules appropriate for your sound hardware
need to be loaded. In general this will happen automatically if you have, in
addition to the alsa-base package, either the hotplug
package or the discover package installed. The
alsa-base package also "blacklists" OSS modules to
prevent hotplug and discover from loading them. If
you have OSS modules listed in /etc/modules, you should remove
them.
udev is a userspace implementation of devfs. It is mounted over
the /dev directory and will populate that directory with devices
supported by the kernel. It will also dynamically add and remove devices as
kernel modules are loaded or unloaded respectively, working together with
hotplug to detect new devices. udev works only with
2.6 kernels.
As udev is automatically installed as a dependency of e.g.
gnome, there is a chance that upgrading to a 2.6 kernel will
result in udev being activated.
Although udev has been tested extensively, you may experience
minor problems with some devices that will need to be fixed. The most common
problems are changed permission and/or ownership of a device. In some cases a
device may not be created by default (e.g. /dev/video and
/dev/radio).
udev provides configuration mechanisms to deal with these issues.
See udev(8) and /etc/udev for further information.
If after booting your machine, X fails to load and you see an error
"missing core pointer" in /var/log/XFree86.0.log, the
problem could be that the mouse driver is not loaded fast enough by
hotplug (bug #255744). The solution is to
add the driver module for your mouse (e.g. psmouse) in
/etc/modules.
The X server shipping in sarge contains optimized code which is not properly executed by many Transmeta(TM) Crusoe(TM) processors. The result of this is that at a certain time (when cached code "morphed" from x86 to Crusoe VLIW instructions in the CPU is in a buggy state), X client applications which connect with it fail with the following error message:
X Error of failed request: BadLength
(poly request too large or internal Xlib length error)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 15
Current serial number in output stream: 18
In practical terms, this means that after a few hours of operation, applications will suddenly quit in rapid succession; if a display manager is running, that too will repeatedly quit and attempt to restart itself. The state will persist until the buggy VLIW Transmeta code is flushed from the cache.
Since the bug is in the proprietary Transmeta Code Morphing Software (CMS), and
the laptop BIOS checks the CMS for a vendor signature at boot time, this can
only be fixed in cooperation between Transmeta and the laptop vendor. Further
information about this issue can be found at http://www.cs.auc.dk/~fleury/bug_cms/
and Debian bug report #216933.
The workaround for this bug is to install an X server compiled without
optimization, such as the xserver-xfree86-dbg package.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ next ]
Release Notes for Debian GNU/Linux 3.1 (`sarge'), Intel x86
$Id: release-notes.en.sgml,v 1.71 2006/09/18 13:21:10 fjp Exp $debian-doc@lists.debian.org