On Sun, Apr 01, 2007 at 04:11:51PM -0700, Steve Langasek wrote:
> > Currently the kernel upgrade section is written based on these
> > recommendations (to try to lower the number and minimise the issues
> > if rebooted in the middle of the upgrade):
>
> > - if using 2.4:
> > - (if you rely on hotplug -the package- support). Two options:
> > - (recommended) upgrade to sarge's 2.6 kernel, test and follow then the
> > recommendations for 2.6 sarge kernel upgrades (see below)
> > - (not recommended, "upgrade within an upgrade") upgrade to etch's
> > 2.6 kernel after a minimal upgrade, test, proceed with full upgrade
>
> I'm not sure that upgrading to 2.6.8 first is beneficial. If the user needs
> hotplug in 2.4, they will need udev in 2.6, and the etch udev won't support
> either of the sarge kernels reliably. Further, although installing 2.6.8
> first before upgrading gives the user a chance to test 2.6 support in a
> setting where they can still downgrade to 2.4 to fix things if it's broken,
> there are plenty of driver changes between 2.6.8 and 2.6.18 as well, so
> 2.6.8 is *not* guaranteed to be a good model for success with 2.6.18.
Still, since 2.4 to 2.6 is a major change it is better to have a working
kernel to which to reboot to. If you do the change after a dist-ugprade
(after a minimal upgrade is not an option for Desktop systems as it will
remove most of the system) you have to "cross your fingers" as you don't have
any kernel to reboot to in the event of an issue (sarge's 2.4 does not have
the 'hotplug' package and etch's 2.6 does not work). Granted, a succesfull
reboot with 2.6.8 does not guarantee your system will work with 2.6.18, but
there should be less differences than 2.4 -> 2.6.18.
An alternative is to recommend 2.4 users to become "hotplug-independent" by
getting a manual list of all loaded modules and make them staticly loaded.
> If you think it's going to still be helpful to enough users, I have no
> problem with documenting this option, but I think these caveats should be
> made clear.
I'm not sure how many users it will be helpful to, however.
> Also, if the user does upgrade the kernel to 2.6.18 after the minimal
> upgrade, I don't think we should recommend rebooting to test at that point.
> Any testing can be deferred until the end of the dist-upgrade without risks
> (the only risk is an unintentional reboot, and then they're no worse off),
> and it allows the user to reduce the downtime by only rebooting once at the
> end. It also gives the user a chance to clean all old libraries out of
> memory, which otherwise wouldn't happen for services that were upgraded
> before the upgrade of libraries they depend on.
Agreed. Let's move the "reboot to test your new kernel" to the end.
> > *or*
> > - (if you do not rely on hotplug). Two options:
> > - (recommended, but no risks here) do full upgrade, then upgrade
> > to etch's 2.6 kernel
> > - (not recommended, "upgrade within upgrade") do minimal upgrade,
> > upgrade to etch's 2.6 kernel, test and then do full upgrade.
>
> Again, I see no reason that the kernel upgrade needs to be deferred to the
> end, so I think it's simpler to explain to just do the kernel upgrade early,
> at the same point as for hotplug users. Do you agree?
In 2.4 Desktop systems upgrading the kernel after the minimal upgrade pulls
in udev and removes hotplug, as a consequence half of the system gets
removed. I think it's better to do it at the end. I have the snapshot images
from my testing (best sequence up at
http://people.debian.org/~jfs/etch/upgrade_desktop_2.4.html).
> > > + removals, it is recommended that you upgrade the kernel at this point.
> > > + The reason for this is that the next step will install the latest
> > > + <package/udev/ and remove <package/hotplug/, removing hotplug support for
> > > + Linux kernels before 2.6.15 at some point during the
> > > + <tt>dist-upgrade</tt>. Although this should not remove any kernels you
>
> > I think it should be "removing hotplug support" not (for Linux kernels..)
> > since this applies to 2.4 kernels too.
>
> Sorry, I don't understand what you mean. This upgrade removes hotplug
> support for all Linux kernels before 2.6.15; that includes Linux 2.4 and
> linux 2.6.0-2.6.14. For 2.6 kernels, hotplug support is *normally* provided
> by udev -- but the hotplug package *can* be used, if it's installed (which
> it won't be on a system using a Debian kernel package).
I meant that "for Linux kernels before 2.6.15" is not needed as it is removed
for all kernels we are support upgrade paths from.
>
> > > + <p>In the desktop case, it is unfortunately not possible to ensure the
> > > + new kernel package is installed immediately after the new <package/udev/
> > > + is installed, so there is a window of unknown length when your system
> > > + will have no kernel installed with full hotplug support. See <ref
> > > + id="newkernel"> for information on configuring your system to not depend
> > > + on hotplug for booting.</p>
>
> > Is this comment about hotplug support true for 2.6 kernels?
>
> Yes, it is.
>
> > (I read it and I think about the hotplug package, not the functionality,
> > maybe it should be rephrased)
>
> Suggestions welcome, 'hotplug' is the name of the kernel interface.
Hmmm... I'm not sure how to repharse, but it sure leads to confusion. Could
we say "support for hotpluggable interfaces" instead? (avoid the use of
'hotplug' since it is also the package name)
> + and <package/xserver-common/. For a more complete list of packages
> + obsoleted in &releasename;, see <ref id="obsolete">.
> + </p>
This last pharse is not true. <ref id="obsolete"> does not (yet) list
obsolete packages (the list would be too long) it just describes how to find
which packages are obsolete.
> + <footnote>This command will determine whether you need libfam0 and
> + xlibmesa-glu installed, and auto-select them for you:
> + <example>
> +# aptitude install x11-common \
> + $(dpkg-query --showformat '${Package} ${Status}\n' -W libfam0c102 xlibmesa-glu \
> + | grep 'ok installed$' | sed -e's/ .*//; s/c102//')
> + </example>
This footnote is OK but, I told you in IRC it would be ugly :).
Everything else looks fine.
Regards
Javier
Attachment:
signature.asc
Description: Digital signature