Slashdot Mirror
Linux Kernel 2.6.8 Released
J ROC writes "According to The Linux Kernel Archives kernel 2.6.8 is now out. It includes some fixes from 2.6.7. Happy upgrading." You may want to read this earlier story and think twice before upgrading.
← Back to Stories (view on slashdot.org)
Due to an NFS bug a brown paper bag release was produced.
Mirrors
News for nerds, stuff that matters...? ;)
"An infinite number of monkeys typing into GNU emacs would never make a good program."
The latest is actually 2.6.8.1. The (very short) change log for that version can be found here. Looks like there was an NFS bug in the 2.6.8 release that needed to be fixed.
That didn't have anything at all do do with the kernel.
I believe that it was the way Red Hat installer, Anaconda, installed GRUB, the GRand Unified Bootloader, that was at fault. The Linux kernel is generally quite solid, and I certainly will be upgrading.
Search the changelog for "no execute" and you'll get the patch details for adding support for NX.
^_^
I know they added hardware NX, but i'm wondering if they added softwared based NX similiar to Window's DEP in SP2.
Exec Shield isn't the same thing as support for NX-bit, it's "no execute" protection that DOESN'T require CPU support.
If you have the previous version, you can just download the patch; it is 3691743 bytes (about 3.5MB).
Those problems were not in the kernel per se but in the way the auxillary pieces were deployed -- mainly the boot loader.
PS: This is being written on the system which which I had that issue. Solved now.
All my previous sigs now look like this one, I wish they were permanetly recorded when used.
On occasion, someone will write up a nice summary of highlights. Anyone seen such a thing for 2.6.8?
Kerneltrap usually posts one shortly after release. Not yet posted for 2.6.8, though, but check periodically, I would think that they will update later today.
That's the size of the .tar.gz version. Bzip2 compresses a lot better. The .tar.bz2 version at kernel.org is about 9 MB smaller.
people who use NFS should wait for 2.6.8.1: 2.6.8 oopses with nfs
Lots of memory leaks fixed.
Lots of USB issues fixed.
A few patches for prism based wireless card too.
Several filesystem patches:
EXT3 deadlocks removed and buffer issue fixed.
EXT2, Reiser + JFS I/O errors lost issue fixed.
Network oops, I/O oops created in 2.6.7, smbfs + nfs oops, SATA + Highmem oops
X86_64 Memory corruption fix's + "small + serious" bugs.
New hardware support for latest VIA K8%, KT%, VT%, PM% chipsets.
NX (No eXecute) support for x86
Most of the new options seem pretty normal, but can someone explain this "Default codepage for FAT" option? Cheers...
This one goes to the stone age of DOS... Under DOS you could write file names that included ASCII characters with codes above 127. When first localized versions of DOS appeared, you bumped into what most people still don't understand today: under your local codepage (here we used to use CP 850, US one was 437) different codes represent different characters. Since we're talking about times when Unicode was still just a thought in some lonesome head, the characters you typed for filename appeared differently when DIRed under different codepage settings.
Now enter 21st century... most of the charcter strings are already in one or the other UCS/Unicode format. This means that we're mostly talking about Unicode character "small e with caron", not the character 152 in CP 850. The problem you have with this is to guess what was the original codepage used to write the text file or filename so you can convert from Unicode to local CP and back.
In MS Windows this is solved by defining default system codepage. If you're a long-time MS user, then you have basicaly went all the way from the end of '80s to now using default codepages for your particular region and all this is transparent to you.
When you come to the Linux however, what particular application considers to be your codepage has no bearing to what the kernel wants to know about you. Kernel simply doesn't do codepages. Glibc can do them, but hardware as a rule doesn't care whether it runs in China or in US. Thus, for this particular FAT problem, you have to explain the kernel module what do you consider to be a default codepage so it knows how to convert filenames from disk to userland and back.
In short: if you live in a region that considers ISO-8859-1 to be a default, then 437 is for you, if you live somewhere else, you probably already know all this, and you have only read it this far to see if you could correct some of more glaring mistakes I have made.
Anonymous Cowards Unite
Windows would write upper and linux would see it as lower. I'm hoping that you are the bearer of good news.....
Under MS Windows, when you write a filename that conforms into 8.3 format and consists of all upper-case characters, only basic FAT entry will be written, not the VFAT entry.
When you list the name of such file under linux, two things happen:
I belive that knowing this two rules, and behaviour of MS Windows, you will be able to find the solution to your problem.
Anonymous Cowards Unite
A couple of things here. Sticking with 2.4 is reasonable, but running an old version of 2.4 is a bad idea IMO. There are enough security vulns fixed every few releases that I'd seriously consider patching, if I were you. Know how we all pick on Windows kiddes for not updating? Linux doesn't give you a free pass to run unsecure versions either.
Second, even if a particular kernel has issues on your machine, there is *no* reason you would have to reformat. Simply create a new entry in your bootloader and leave the old Kernel as an option. That way if you forget to compile something you need in, you still have the old kernel to fall back on. This is the reason why when my laptop boots up, GRUB offers me a choice of the stock Slackware 2.4 kernel, and 4 or 5 2.6 revisions. HD space is cheap and kernel binaries are small - there's no reason not to.
Try the stuff found in http://linux.netpimpz.com/mx700/, the very first hit on the most obvious google search.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In my case, it was necessary to change Protocol to "ImPS/2" (from "auto") and add Resolution=400 (actually any number was ok, as long as the line was present). With Protocol="Auto" my mouse didn't work, so changing that might help you, too.
I had a manager a few years ago who got burned bad by NT service pack 5. He wouldn't let us install anything newer than SP5 in the lab. Terrible things ended up happening one day when a worm broke out and we couldn't even patch the systems because it was against policy.
/usr/src/linux-2.4.27
.config (/usr/src/linux/.config ?) and copy it to /usr/src/linux-2.4.27/.config
.config in another window to cross-reference. You'll only have to answer questions for changes since your old config.
I've been through bad kernel upgrades too, but you should be fine if you follow procedure and stay conservative:
1. get latest kernel in your tree (2.4.27 for you). It's been out a few days with no major issues. Unpack it to
2. Find your current
3. cd to linux-2.4.27/ do a 'make oldconfig'. You may want to view your current
4. make -j2 bzImage && make -j2 modules
5. install the files. all this is well documented from here on, so I'll stop this, but make sure to keep your current config in your bootloader in case this kernel burns you.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Here's more information on the issue (which is caused by the bootloader modifying the disk geometry reported in the partition table), including how to fix it.
-jim