vga consoles? I guess you mean framebuffer consoles. I imagine people whose machines don't implement any sort of text mode find them quite useful:) And if you have a PC and don't like framebuffer, don't use it..

If none appear, then the patch was successful. You can remove the original files that the patch saved (those with a.orig extension):

# find . -name '*.orig' -exec rm -f {} \;

Usually it's a lot easier, since scripts/patch-kernel (go and read it with less) under the kernel tree is a script that automatically applies a set of patches to a kernel tree. Sadly, the irregular numbering on the pre-2.2 series has broken this script (last time I checked)

Now, I know a little bit about programming, so I opened up checksum.c (which is in/arch/i386/lib) and checked out lines 200 and 105. They're function declarations. Line 200 declares function "csum_partial_copy", and line 105 declares function "csum_partial_copy_fromuser". So why does the compiler think that its trying to redefine "csum_partial_copy"?

Don't blame Linus for this. If the ISDN people want it included in the kernel they better submit patches way earlier. The same happened to knfsd and now people are taking responsibility and knfsd has an official maintainer. Just needed a kick in the behind from Linus, I guess.

IMHO, moving from 2.1 to 2.2..0 pre gives bug-testing a whole new boost, which should help iron out a lot of last-minute glitches. (I remember having to wait, with 2.0 - I was able to use almost every development kernel prior to it without problems, but 2.0.0 simply wouldn't work.)

I'm not going to worry, no matter how long it takes. Weeeeell, if we get up to 2.2.0-pre150 I might wonder if maybe Linus switched to the pre phase a tad early....:)

I like RPM because it allows me to keep track of files on my system, provides a powerful versioning system for up/downgrades, and most importantly, it saves time...

I'm pushing for a major switch from Solaris to RedHat Linux here at work. My major selling point is reduced administration time through the use of RPM.

Remember that RPM != Precompiled Binary. SRPMS allow you to compile from pristine source, but also give you the ability to track/update/remove every file created through the compilation process. I like that a lot better than the ".tar.[gz|bz2|Z]" system of spraying and orphaning files all over my file systems.

The Frame buffer console was ported over to x86 because the PC98 spec no longer requires a text mode on video cards - so, in the future, it might be impossible to use Linux on x86 w/o a frame buffer console. As others have said, in the mean time, if you don't like it, don't use it.

Well you're right: I like SRPMs too, but you know what an SRPM is? It's a tar.gz file (maybe a few), together with patches and a spec file.

When you install an SRPM, all it does is copy the tar.gz file(s) and patches to/usr/src/redhat/SOURCES and the spec file to/usr/src/redhat/SPECS (talk about splaying all over your filesystem...and why are the RPMS binaries a part of the/usr/src tree?). You have to then use the spec file to build the RPM, then install the RPM.

The problem is that if you're looking for someone to provide an SRPM for a kernel, then simply build an RPM from their spec file, you *still* have no control over the kernel configuration, which is pretty important when testing the kernel (which is, after all, what the prereleases are for).

If you're building your own RPM/SRPM, you haven't saved any time (especially considering that you often have to build the stuff successfully more than once if you are making your own spec file; once by hand [using the tar.gz] and again from the spec-- for instance to find out what files it provides).

I don't think the original poster cared (or knew) about building his own RPM, he was more concerned with just getting a binary package and installing it, letting others compile for him.

If you want to build your own RPM/SRPM, then just grab a spec file from an earlier kernel SRPM and hack...er, edit it to work with the new kernel. The steps are the same, more or less, only the configuration file (which you would presumably include preconfigured) will be different.-- Aaron Gaudio "The fool finds ignorance all around him.

Don't you use modules? or is that why you have to make bzImage? Nonetheless, most of us do use modules, and that automagically installs into the/lib/modules directory tree so there is some splaying.-- Aaron Gaudio "The fool finds ignorance all around him.

IT SAVES TIME!!! Plus I don't want to dink around with tar files and patches to the point of destroying my system. I've already installed 2.0.36-1 in my RH52 system at home and work with a minimum of fuss. IMHO the RPM system is why RH is the leading distro in the US.

If you are going from a 2.0 to 2.2 kernel, remember that IP Forwarding is off by default, and you need to echo a '1' to the appropriate file in proc (i don't recall it... look at the IP Chains page) to enable it. My masquerading was broken for two weeks until I found this out. Now it works like a champ. Go 2.2!

There are comments on here from people wanting 2.2.0 to be released soon...

I personally would not like to see it released after first quarter this year, but I don't understand why it is so important to people to have 2.2.0 released.

Linux kernel 2.2 is currently in a feature freeze, which means the current pre release does everything the final kernel will do. So why is it so important for 2.2.0 to be released?

Why don't you, the people who want to use 2.2.0 final, just use pre5 AS IF IT WERE FINAL, and only update to the latest pre every 5 releases or when you find a bug in the kernel you are using.

If 2.2.0 were released tomorrow any further bugs that are found would have to be put into a patch, and because end users, not just the `beta testers' will have to apply this, linus will probably want to wait a while before releasing it.

I personally like the releasing of a new pre every 2-3 days, it means I have to compile then re-boot, which makes me feel like I am in windoze again:-) (does flatlining the CPU then having to re-boot for the changes to take effect to install software remind anyone else of a certain OS? *grin*)

Last night (23:00 gmt+1 time) I found the pre5 patch and complete source on ftp.kernel.org, on a completely free system, there where almost no users at all online. Yet I noticed that none of the mirrors had it. So please, whoever posts kernel kernel info on slashdot, look on the mirrors ( all of them ) if it is allready available there.

&ltRANT&gtWell, they could pull a Microsloth and release it as-is, even though it still contains bugs. Or they could do what they're doing, make multiple prereleases and correct the bugs in each, then making sure that the bugfixes do not engender new bugs, so when they do release 2.2.0 final, it's stable and works. Which would you prefer? If you want to speed up the release of the final 2.2.0 kernel, install the latest prerelease and submit intelligent bug reports. &lt/RANT&gt

I don't do -ac patches because I'm too lazy to undo them before the next one. Pre6 should have this fixed; at least I hope so I'm in the middle of configuring a firewall so this bug wrecks the effort. Patienly waiting...

Redhat is the leading distro because of the easy installation. Debian is the best distro because of.deb, dpkg, and apt. When you learn more you'll move up. I needed RedHat for on month before graduating to debian. When you find you can't upgrade sw you want because of rpms don't let you acquire the necessary dependencies or won't overcome conflicts you'll check out debian, and you'll love it. Aside from that, that rpm kernel you installed has options you don't need. You could reduce the size of the kernel by typing make clean, make menuconfig, make dep, make bzImage (if it's that big) or make zImage, then make bzlilo to install it, make modules, make modules_install, that's it, reboot. Participate in the linux community and report bugs. Trust me, if I can do it, you can too.

Well, if a functional patch exists, then ISDN users or their distribution maintainers can apply it themselves. If no functional patch exists, even now, then it probably isn't worth holding up the release of 2.2.0 for it. Annoying, but...

In either case, it is on Alan Cox's todo list, and I'm sure that it will be fixed early in the 2.2.x series.

you smoke too much crack. sure, in a MS world where your forced to use the Man's inflated disfunctional kernel, precompiled updates would be fine. but in a world where you can actually fine tune your computer's abilities, it simply isn't. download the tar and take a bite out of crime.