[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Call for upgrade testing

> >
> > I have had some problems understanding this process, so I volunteer to
> > review the text you come up with, if you need reviewers.
> I'll take you up on that offer :-)
> Please review:
> http://www.debian.org/releases/testing/i386/release-notes/ch-information.en.html#s-upgrade-to-2.6

The basic structure seems sound. I've attached an initial patch. Mainly
I'm adding little bits of background information.

I have not had time to try a kernel upgrade yet to experience all the fun
things that can happen, I'll post an updated patch then.

I would like to add a bit to the mouse configuration, about what are
the old device files and their new equivalents, for the common cases
- usb, ps/2, generic serial. But I'm not sure what the facts are.
I'll have a go at doing an upgrade and try to come up with something.

One thing I really like documentation to do is cover all the cases and
subcases explicitly; for example here
  <![ %not-i386 [
   <p>Note that if you are using a USB keyboard, this may be configured
   as either a "normal" PC keyboard or as a USB-MAC keyboard. In the
   first case you will not be affected by this issue.</p>
my first reaction is - but what about the second case?
(BTW, perhaps there really is nothing to add in this case)

Question: Is module-init-tools a drop-in replacement for modutils,
in the sense that it will work seamlessly with 2.4 kernels?
I assume "yes" but it might be worth saying so explicitly.

A bit off-topic - I'm not suggesting we add this (these are release
notes, not an encylopedia of linux).
Something that's always seemed missing to me in kernel-upgrade howtos
is a "meta" statement of why packages need upgrading across a kernel
change (ie the kernel's API has changed) and an explanation of how to
go about finding out which packages are affected.

I assume that you could get an initial list from anything that
build-depends on kernel-headers, but then you'd need a tool to check
for actual code changes in the kernel-headers files each that package
#includes. Has anyone tried such a thing?


--- release-notes.en.sgml.orig	Tue May 24 13:12:20 2005
+++ release-notes.en.sgml	Tue May 24 15:17:04 2005
@@ -875,7 +875,7 @@
           <p>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 taken
+          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.</p>
@@ -898,13 +898,28 @@
           the init scripts will detect which kernel is used and execute the
           appropriate version.</p>
+          <p>If you have entries in the <file>/etc/modules</file> file (the
+	  list of modules to be loaded during bootup, once <file>/etc</file>
+          is mounted), be aware that some module names may have changed.
+          If this happens you will have to update this file with the new
+	  module names.</p>
 <![ %i386 [
           <p>For some SATA disk controllers, the device assigned to a drive and
           its partitions may change from <file>/dev/hdX</file> to
           <file>/dev/sdX</file>. If this happens, you will have to modify your
-          <file>/etc/fstab</file> and bootloader configuration accordingly.</p>
+          <file>/etc/fstab</file> and bootloader configuration accordingly.
+          Your system could fail to boot if you make a mistake in the
+          <file>/etc/fstab</file>.</p>
+          <p>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 a misconfiguration of the bootloader
+          prevents yo booting the old kernel.</p>
 <![ %not-s390 [
         <sect1 id="2.6-keyboard">
         <heading>Keyboard configuration</heading>
@@ -957,6 +972,8 @@
         <sect1 id="2.6-udev">
         <heading>Switching to 2.6 may activate udev</heading>
+        <p>&debian;-packaged kernels (<package/kernel-image/ packages) use
+        <package/devfs/, the kernel device filesystem, to represent devices.</p>
         <p><package/udev/ is a userspace implementation of devfs. It is mounted
         over the <file>/dev/</file> directory and will dynamically populate that

Reply to: