Hi Russ,
On Mon, May 09, 2005 at 07:39:20PM -0700, Russ Allbery wrote:
> The version of OpenAFS in testing has an annoying init script issue that
> can also cause it to fail to start under some circumstances, and I'm
> seriously considering a testing-proposed-updates upload to fix that:
> * Handle modules named either with or without the .mp extension on SMP
> hosts. (Closes: #305389, #307280, #307797)
> Judging from the bug reports, it caused a fair amount of confusion and one
> problem at the important severity level because it can hit people during
> upgrades. See the log for #305389 for most of the analysis.
If a minimally-intrusive solution can be found, I would probably accept it
into sarge.
> However, I'm not quite sure what to do about the problems the version in
> testing has with newer 2.6 kernels (#303495) or with 2.6 preempt kernels
> (#308399, #304040). (See below for discussion on the severity and tagging
> of #308399.) These bugs are fixed in upstream 1.3.82, but the diff
> between that and 1.3.81 is, er, extensive. I took a look at pulling
> specific deltas from upstream just for these problems, but I'm not sure
> I'm correctly identifying which ones I'd need and the diff is still likely
> to be sizeable.
FYI:
$ grep PREEMPT /boot/config-2.6.8-2-686-smp
CONFIG_PREEMPT=y
$ dpkg -S /boot/config-2.6.8-2-686-smp
kernel-image-2.6.8-2-686-smp: /boot/config-2.6.8-2-686-smp
$ apt-cache policy kernel-image-2.6.8-2-686-smp
kernel-image-2.6.8-2-686-smp:
Installed: 2.6.8-13
Candidate: 2.6.8-13
Version Table:
*** 2.6.8-13 0
500 http://debian.oregonstate.edu testing/main Packages
100 /var/lib/dpkg/status
$
I know the Debian kernel team was hoping to have preempt disabled for sarge,
but unfortunately this was an ABI-breaking change that was proposed too
late.
This means that 308399 should most likely be considered RC, if it affects
2.6.8 w/ preempt and the openafs package is advertised as working with 2.6.
However, this may be nothing more than a documentation issue, since the
default kernel for sarge is still 2.4, and there is no requirement that a
kernel patch/module package work with *all* kernel versions we offer.
> So far as I can tell, these bugs do not affect the 2.6 kernel supplied by
> Debian in sarge. I'm not sure, however, if the preempt problems might
> affect the sarge kernel if built with preempt. These problems will cause
> serious difficulties for anyone using a newer 2.6 kernel.
Well, if you've tested the sarge 2.6 kernels and not been able to reproduce
the problem, then it's pretty definitely not RC. :)
> #308399 is severity grave at the moment. I tagged it sid, which is sort
> of true and sort of not -- the bug is present in the package in sarge, but
> is not triggered by the sarge kernel. It only affects preempt kernels,
> but certainly the system not shutting down and unmounting file systems
> cleanly is a serious problem if one happens to run into it.
That's a reasonable use of the "sid" tag.
> Given this, should I consider a backport of 1.3.82 for sarge? Or try to
> pull individual deltas (in which case, testing is going to be *very*
> important to make sure that I didn't miss some code dependency when
> cherry-picking patches) and still end up with a fairly sizeable diff?
> Any advice on this would be welcome.
What Joey said; actually trying to get this kernel incompatibility fixed for
sarge sounds horribly error-prone.
> If I do prepare a testing-proposed-updates upload for sarge, with or
> without trying to backport 1.3.82 fixes, I'll probably also include:
>
> * README.modules: Add documentation for module-assistant and recommend
> it when using Debian kernels. Mention divergences from upstream in
> module naming. (Closes: #253168) Emphasize that the kernel source
> tree used for make-kpkg must be identically configured to the kernel
> the module will be used with.
>
> * README.Debian: Document that the client cache partition must be ext2
> or ext3 and that XFS and ReiserFS will not work. upserver and
> upclient are now provided. Provide some information about why
> kaserver is not provided. (Closes: #249315)
>
> as documentation fixes; I expect that will be uncontroversial.
Yep, per the freeze policy.
Thanks,
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature