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:
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
+ <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
+ <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 [
@@ -957,6 +972,8 @@
<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