Networking change causes distribution headaches

Posted Oct 28, 2008 21:22 UTC (Tue) by ca9mbu (guest, #11098)
In reply to: Networking change causes distribution headaches by pj
Parent article: Networking change causes distribution headaches

Even targetting at 10/01 (or, less ambiguously, 2008-10-01), wouldn't have helped in this particular case, I don't think. According to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-..., the fix was only applied on 2008-10-26, which, I don't think, would have given Ubuntu time enough to respin the release. And, given the nature of the bug, picking up an update post-installation through apt-get is unlikely to have worked.

Yes, it sucks that this had the potential to impact Ubuntu's release schedule, but I guess that's the price one pays for time-based releases (which I'm all in favour of). I don't agree with Ubuntu's decision to workaround the issue via a procps update as opposed to a kernel update just to avoid a release slippage, but then I'm not the RM (or even involved with Ubuntu in any capacity).

Regards,

Matt.

Networking change causes distribution headaches

Posted Oct 29, 2008 1:07 UTC (Wed) by jordip (guest, #47356) [Link] (9 responses)

Aiming to 2008/10/01 would have made impossible to use 2.6.27, using 2.6.26 instead so this problem would have not appeared.
The problem here is that Ubuntu released too close to a kernel release. It was a known issue but 2.6.27 have enough benefits to weight that.
I think future releases of Ubuntu will be more conservative on this regard.
Also, a faster Ubuntu bugtracker -> kernel bugtracker interaction may have save the day. This is an old discussion now...

On the other hand 10/01 will make Ubuntu release farther in time from Fedora and Opensuse ...

Networking change causes distribution headaches

Posted Oct 29, 2008 5:27 UTC (Wed) by ncm (guest, #165) [Link] (6 responses)

How will the procps workaround ever be removed, once a fixed kernel is installed? I.e., how does procps know what kernels might be on the system, and need it? Is the workaround a script that will test the running kernel's version, and operate only for known-broken kernels?

Networking change causes distribution headaches

Posted Oct 29, 2008 8:24 UTC (Wed) by rvfh (guest, #31018) [Link] (3 responses)

The procps package with the fix will depend on a kernel with version greater or equal to the fixed one. Simple.

Networking change causes distribution headaches

Posted Oct 29, 2008 11:25 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

It can't do that, since users may be using unpackaged kernels. Also, the Ubuntu kernel packaging system results in a different package name per version (it's the only way to handle parallel installation on Debian-style systems) so you can only depend on a single specific kernel version.

Networking change causes distribution headaches

Posted Oct 29, 2008 16:30 UTC (Wed) by jzbiciak (guest, #5246) [Link] (1 responses)

If only there were a filesystem that allowed the kernel to export information to user space, such as what kernel version was currently running... ;-)

Seriously, why can't procps look at /proc/version and presume that 2.6.27 is broken, but any other version (including 2.6.27.1). As long as it's looking very specifically for the broken version's version string there, it should work ok.

Sure, if someone installs a broken kernel with a different string, then the workaround won't kick in, but I don't really see a problem with that. If you're installing your own kernel rather than sticking to vendor kernels, then you're signing up to own a bit more of the problem yourself, don't ya think?

Networking change causes distribution headaches

Posted Oct 29, 2008 18:21 UTC (Wed) by jzbiciak (guest, #5246) [Link]

Seriously, why can't procps look at /proc/version and presume that 2.6.27 is broken, but not any other version (including 2.6.27.1)

oops. :-) Fixed that.

Networking change causes distribution headaches

Posted Oct 29, 2008 12:40 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

The workaround is a one-line sysctl.conf addition.

Networking change causes distribution headaches

Posted Oct 29, 2008 18:42 UTC (Wed) by ncm (guest, #165) [Link]

So it appears there's no clean way to phase out the workaround.

Networking change causes distribution headaches

Posted Oct 30, 2008 1:05 UTC (Thu) by sbergman27 (guest, #10767) [Link] (1 responses)

"""
The problem here is that Ubuntu released too close to a kernel release.
"""

Ubuntu has traditionally been more conservative. But in a "practice what we preach" action, they sync'd up with the other major distros which were planning to use 2.6.27 to help synchronize problem finding and debugging focus. Personally, the way kernel development is done these days I think the distros need to lag kernel releases a bit more. The fall releases, with the exception of Fedora, should really have targeted 2.6.26. I'm not criticizing the current kernel development process (though I gravely note Andrew's ongoing quality concerns), but the 2.6 dev process means that the distros are responsible for that much more of the QA. And that can't be done in a hurry. This particular issue doesn't seem too severe. But a month before general availability, going gold, or whatever you want to call it, the included kernel shouldn't be physically destroying beta testers' hardware or otherwise exhibiting behavior of baby-eating magnitude.

Networking change causes distribution headaches

Posted Oct 30, 2008 13:50 UTC (Thu) by filipjoelsson (guest, #2622) [Link]

Excuse me but, what are you talking about?

In the earlier series of kernels, the vendor patchsets were much larger - and contained everything from drivers and filesystems to security fixes. I would argue that there was less QA before kernel release in the 2.0, 2.2 and 2.4 series (where the QA was, it boots Linus'/Alan's/Marcello's computer). Ok, so now there is a much bigger difference between each point version than it was then, but still - the vendors cooperate in the same kernel tree to a much larger extent, and there actually _is_ QA now. Anyone remember versions 2.2.0, and 2.2.1 (what were they, one or two days apart)? Care to have a chat about kernel versions 2.4.0 to 2.4.13?

What we have now is tremendously better tested than the old and ancient series.