linux-2.6.15.2

[Matthew Burgess]

Linux-2.6.0 requires another package (in the form of sanitized kernel headers) so is getting it's own bug. This also means that 2.4.x series upgrades can be tracked seperately via bug 58.

[greg@…]

Version increment (2.6.1)

[jeremy@…]

Version Increment (2.6.2)

[Matthew Burgess]

Version increment (2.6.3)

[tushar@…]

Version Increment (2.6.5)

[Matthew Burgess]

Fixed in 6.0

[Matthew Burgess]

Version increment (2.6.7)

[Matthew Burgess]

Version increment (2.6.8) - a couple of security fixes in this one, along with the usual bug fixes of course.

[Matthew Burgess]

Version increment (2.6.8.1) - NFS client fix.

[alexander@…]

Hm, they use a four-component version? Might break apps that think that linux version always has three components. FSF Binutils 2.13.2.3 did the same bad thing to gcc back in January 2003...

Note that I have not done any testing, I pretend to be a happy debian user.

[Matthew Burgess]

Yes, that binutils breakage sprung to my mind too. I've not tested it yet either. No doubt some of the -hackers folks will do so soon enough.

[Matthew Burgess]

Ack! Hit "Commit" too soon! This also brings us to the point where, if we do this upgrade, we'll have linux-libc-headers older than the kernel. While this is unlikely to cause problems, it may well raise endless support questions regarding the inconsistent version numbers!

[n-roeser@…]

Don't panic. Look at the patch. They simply set EXTRAVERSION = .1 in the top-level Makefile. It can be overridden on making the kernel. Either set it to nothing, but that may be unwise, or set it to "-1" or whatever. But heck, they should have distributed that small patch alone without bumping the kernel version number! Arrrrgh ...

[Matthew Burgess]

Well, the patch is available at ​http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.1.tar.bz2 of course. This bumps the EXTRAVERSION as already mentioned in comment 12. We could prepare our own version which omits that particular hunk, but then I don't think it's worth our trouble until someone can confirm that something does actually break. Then, patching the broken package would be the Right Thing to do IMO, not patching the kernel.

[kpfleming@…]

As I mentioned on lfs-dev, I don't think we want to release a book with mismatched kernel and linux-libc-headers version numbers. Given the security fixes in kernel 2.6.8.1, we can't release a book with kernel 2.6.7, so IMHO that means the 6.0 book needs to wait until linux-libc-headers-2.6.8 are available.

[Matthew Burgess]

OK, so we have 2 options:

1) Wait for linux-libc-headers 2.6.8 2) Patch a 2.6.7 kernel with the 2 known security vulnerability fixes.

I'd prefer option 1, but I'll leave this one to Gerard, given the publishing timescales and such.

[alexander@…]

Why do you think that releasing the book with mismatched linux and linux-libc-headers versions is bad? The mismatch will happen very soon on every computer anyway when one upgrades the kernel. We might just explain that - we are about education, anyway, not about hiding such questions.

[kpfleming@…]

Because this is going into a printed book, which will be on shelves for months, and will be read by users who have no previous exposure to LFS. Having mismatched versions in the printed book will generate support questions that will be a waste of everyone's time.

We are not "hiding such questions", we are trying to avoid an unnecessary support burden. Certainly users will have version mismatches in the future, but hopefully by the time they reach that point they will have enough understanding to know what is happening.

Another option is to put text into the book describing why a version mismatch is OK, but I don't like that, because it sounds like we're explaining away a problem, when it's not really a problem.

[alexander@…]

Our opinions differ then. I prefer putting the text into the book describing why a version mismatch is OK. This is IMHO better because it serves as an illustration of the comments in the book on the Linux-Libc-Headers page.

[gerard@…]

Any ETA on a new linux-libc-package?

[Matthew Burgess]

Can't say for certain, but ​http://cvs.pld-linux.org/cgi-bin/cvsweb/linux-libc-headers/ChangeLog?rev=1.15 looks promising: A couple of 2.6.8 related changes in the last few days. From what I've heard, the maintainers are fairly quick at releasing it. I'd be surprised if a tarball isn't out by the end of this week.

[gerard@…]

It will be a drop-in replacement so I will wait for it and see what happens. I won't bother update the text of the book quite yet or update the kernel version.

If a new linux-libc-headers is available soon both will be updated (then still discuss on lfs-dev if we want to use a stock kernel + the nfs patch, or just use 2.6.8.1 and forget about patching). Else just a kernel update and some text explaining the version mismatch and that it is harmless.

[Matthew Burgess]

New linux-libc-headers (2.6.8.0) are available now from ​http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

[Matthew Burgess]

Additionally, we might want to consider putting a caveat in the book. 2.6.8 (and 2.6.8.1) broke CD & DVD writing for non-root users. It's described in detail at ​http://lwn.net/Articles/98379/, but only if you have a lwn.net subscription. A trawl of the lkml archives, or google should be able to provide similar information.

[jeremy@…]

upgraded to kernel 2.6.8.1 and headers 2.6.8.0 in unstable

[Matthew Burgess]

Version increment (2.6.9) - testers/hackers, please watch out for the problems reported with building gcc at ​http://www.ussg.iu.edu/hypermail/linux/kernel/0410.2/0619.html and ​http://www.ussg.iu.edu/hypermail/linux/kernel/0410.2/0605.html. There's a patch attached under the first of those threads in case we're bitten by it.

[Matthew Burgess]

Version increment (2.6.10)

[jeremy@…]

Upgraded unstable to 2.6.10. Still waiting on 2.6.10.1 LLH

[Matthew Burgess]

There's a security hole in 2.6.10. See ​http://www.uwsg.iu.edu/hypermail/linux/kernel/0412.3/0679.html for the description and the reply has links to a patch for it.

[jeremy@…]

Despite the fact that very few would be affected by this vuln, the patch for this is added to the book with Revision 4469.

[Matthew Burgess]

Version increment (2.6.11)

[Matthew Burgess]

Version increment (2.6.11.3)

[Matthew Burgess]

Version increment (2.6.11.4) - two more security fixes: ​http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/2607.html

[Matthew Burgess]

Version increment (2.6.11.5)

[Matthew Burgess]

Version increment (2.6.11.6)

[jim@…]

Applied to trunk on 4-13

[Matthew Burgess]

Version increment (2.6.11.8)

[Matthew Burgess]

Version increment (2.6.11.9). Fixes the recently disclosed security vulnerability (Linux kernel ELF core dump privilege elevation). Proposing we get this into 6.1 because of the security implications.

[Matthew Burgess]

Version increment (2.6.11.10) - another two security bugs fixed.

[Matthew Burgess]

Version increment (2.6.11.11): x86-64 fixes, a couple of oops fixes and a fix for a minor security hole.

[Matthew Burgess]

Version increment (2.6.11.12)

[archaic@…]

version increment (2.6.12)

[Matthew Burgess]

We're not going to get the new kernel in place in time for the 6.1 release - moving out to some future version!

[Matthew Burgess]

Version increment (2.6.12.1) - two security fixes in this one.

[Matthew Burgess]

Version increment (2.6.12.2)

[Matthew Burgess]

Version increment (2.6.12.3)

[Matthew Burgess]

Version increment (2.6.12.4)

[randy@…]

I can confirm that this package works perfectly with the GCC4 branch.

[Matthew Burgess]

Version increment (2.6.11.5)

[ken@…]

Version increment.

[ken@…]

And meanwhile version 2.6.12.6 came out (I assumed it would not appear because

2.6.13 had beaten it to the door).

[Matthew Burgess]

Version increment (2.6.13.1)

[Matthew Burgess]

Version increment (2.6.13.2)

[Matthew Burgess]

Version increment (2.6.13.3)

[ken@…]

version increment (2.6.13.4)

[alexander@…]

Version increment (2.6.14) Has support for /dev/bus/usb. Proposal: remove the obsolete /proc/bus/usb mount, include the relevant udev rule, upgrade to patched libusb in BLFS.

[Matthew Burgess]

Version increment (2.6.14.1) - fixes a security issue CVE-2005-2709

[alexander@…]

Grrr. This probably means that this kernel should go to 6.1.1 and bring udev-071 after itself :(

[archaic@…]

Is the bug even relevant for a 2.6.11 kernel? If so, a patch would be better as there are too many changes between 2.6.11 and 2.6.14 to for inclusion in 6.1.1.

[alexander@…]

Sorry. The bug indeed can manifest itself only when a network interface goes away. LFS users are therefore safe as onlg as they don't run pppd, qemu or OpenVPN.

But I am not qualified enough to judge if 2.6.11.x is still safe. It is no longer supported by upstream in any case.

And linux-2.6.14{,.1} has a bug that prevents Bind from functioning (to be fixed in 2.6.14.2).

So I don't know what to do for LFS 6.1.1.

[Matthew Burgess]

I think the most pragmatic thing here is to assess a) the chance this bug has of being triggered and b) what affects it causes when it is triggered.

From the Changelog and Alexander's comments, it very much looks like the only way this will be triggered is if a network interface disappears , and even then, from the wording in the Changelog, it's not guaranteed to trigger. I'd say it's far better for us to just release with 2.6.11.12, than upgrade the kernel, kernel headers, udev (possibly), etc. If we start down that road, we may as well release trunk as 6.1.1 :-) All IMHO of course, feel free to beat me with a security flavoured cluebat at any time!

[Matthew Burgess]

Version increment (2.6.14.2)

[alexander@…]

Version increment (2.6.14.3)

[Matthew Burgess]

Version increment (2.6.14.4)

[chris@…]

Version increment (2.6.15)

[Matthew Burgess]

Version increment (2.6.15.1)

[Matthew Burgess]

Version increment (2.6.15.2)

[Matthew Burgess]

Fixed on the udev_update branch, but has now been superceded by #1699 anyway.