Quick question: I am using the stock 2.4.4 kernel that comes ith 7.2 and was considering upgrading to a more recent kernel. Is there any reason to do this? In particular, I am trying to understand what I should consider when deciding to update a kernel; what questions should I be asking myself? -- Jon Tillman www.smokingpipes.com www.tobaccoreviews.com www.eruditum.org
Kernels 2.4.10 and later are much faster and secure.
John
----- Original Message -----
From: "Jon Tillman"
Quick question: I am using the stock 2.4.4 kernel that comes ith 7.2 and was considering upgrading to a more recent kernel. Is there any reason to do this? In particular, I am trying to understand what I should consider when deciding to update a kernel; what questions should I be asking myself?
-- Jon Tillman
On Wednesday 14 November 2001 19:13, John Scott wrote:
Kernels 2.4.10 and later are much faster and secure.
John ----- Original Message ----- From: "Jon Tillman"
To: Sent: Wednesday, November 14, 2001 12:12 PM Subject: [SLE] Kernel update??? Quick question: I am using the stock 2.4.4 kernel that comes ith 7.2 and
was
considering upgrading to a more recent kernel. Is there any reason to do this? In particular, I am trying to understand what I should consider when deciding to update a kernel; what questions should I be asking myself?
-- Jon Tillman
Kernel 2.4.10 'till 2.4.13 might have some VM problems, 2.4.11 should be avoided like the plague, and 2.4.14 won't compile without a 2 line patch for some stuff in the loop.c part. -- When someone tells you that Linux isn't user friendly, just tell 'em that it is, but that it is really picky in who his friends are. Gert-Jan Rodenburg. http://members.home.nl/hertog
On 14 Nov 2001, John Scott wrote:
Kernels 2.4.10 and later are much faster and secure.
Yes, completely true, but I would recommend going with the latest stable kernel release (i.e. 2.4.14) because there are no advantages to anything before it. Anything before 2.4.14 had a rather low performing VM and anything before 2.4.6 had a shitty VM (which corrupted by partition, oh, around 6 times). To Jon, the original poster: There are a few reasons to upgrade: 1. Increased stability, speed, etc. 2. Bug fixes (related to [1] or security related) 3. Support for more hardware (if you need it) 4. Shits and giggles I would update my kernel in the days of 2.2.X for reason [4]. Now with 2.4.X, however, I am forced to upgrade because of [1] and [2]. You'd think that at 2.4.14, things would settle down. The VM just friggin' switched... -- Karol Pietrzak PGP KeyID: 3A1446A0
----- Original Message -----
From: "Karol Pietrzak"
On 14 Nov 2001, John Scott wrote:
Kernels 2.4.10 and later are much faster and secure.
Yes, completely true, but I would recommend going with the latest stable kernel release (i.e. 2.4.14) because there are no advantages to anything before it. Anything before 2.4.14 had a rather low performing VM and anything before 2.4.6 had a shitty VM (which corrupted by partition, oh, around 6 times).
To Jon, the original poster:
There are a few reasons to upgrade:
1. Increased stability, speed, etc. 2. Bug fixes (related to [1] or security related) 3. Support for more hardware (if you need it) 4. Shits and giggles
That's basically what I said in one sentence. Well almost. :)
I would update my kernel in the days of 2.2.X for reason [4]. Now with 2.4.X, however, I am forced to upgrade because of [1] and [2]. You'd think that at 2.4.14, things would settle down. The VM just friggin' switched...
-- Karol Pietrzak PGP KeyID: 3A1446A0
Very true on the switch but as Linus said, given the performance difference it was well worth it. Also, Linus pointed out that he had been testing it since 2.4.8 and decided it couldn't get any more stable. Alan Cox said he disagreed with the upgrade until Linus prodded him to looking at the benchmarks. I'll tell you that my Athlon saw no noticeable difference but my dragging Cyrix MII has seen new life since I went from 2.4.7 to 2.4.14. The difference was real! Word to the wise though, if you are still using ipchains instead of iptables you are in for some work. The support for ipchains and further back has to be downloaded separately now and patched. Some will point out iptables are better but I just thought I'd throw that out there for anyone who doesn't already know. John
On Wednesday 14 November 2001 10:31 pm, Karol Pietrzak, went on about:
On 14 Nov 2001, John Scott wrote:
Kernels 2.4.10 and later are much faster and secure.
Yes, completely true, but I would recommend going with the latest stable kernel release (i.e. 2.4.14) because there are no advantages to anything before it. Anything before 2.4.14 had a rather low performing VM and anything before 2.4.6 had a shitty VM (which corrupted by partition, oh, around 6 times).
I would update my kernel in the days of 2.2.X for reason [4]. Now with 2.4.X, however, I am forced to upgrade because of [1] and [2]. You'd think that at 2.4.14, things would settle down. The VM just friggin' switched...
Karol, The VM actually switched at 2.4.10 and Mantel's kernels have been using the new VM since then. The Alan Cox kernels are the only ones that used the old VM, but SuSE always uses Linus' versions which have incorporated the new VM since 2.4.10 and beyond. I don't know if Mantel has done a 2.4.14 kernel yet as those had not been tested enough. The last thing I saw from him was the stable 2.4.13-3 kernel, which is working very well also. Regards, O'Malley -- ---KMail 1.3.1--- SuSE Linux v7.2--- Registered Linux User #225206 /tracerb@sprintmail.com/ *Magic Page Products* *Team Amiga* http://home.sprintmail.com/~tracerb
Okay I've downloaded 2.4.14 and I have a couple of questions: 1. I have a stock 7.2 install; what system implications are there? Does the new kernel require new versions of anything in 7.2? (for example: new libraries, new compiler, is there anything that will fall over when I boot with a later kernel?) 2. How do I rebuild the kernel with the same options as the stock kernel was built with? Is this even possible given the old one is 2.4.4 and I'm about to replace it with 2.4.14? Is it possible to "import" one kernel's build settings into a later version? I would like to keep the changes needed down to a bare minimum. 2a. I suppose I'm asking if /usr/src/linux/arch/i386/config.in or defconfig is the "factory settings" and if whichever file it is can be used in 2.4.14 - perhaps not directly but can it be modified to work? 3. If my attempt at upgrading the kernel goes belly-up, can I tweak the settings in the stock kernel and rebuild it in place, i.e. in /usr/src/linux? I need to modify SEMOPM in sem.h. Again how do I rebuild the kernel with the same config settings as at the factory? Thanks, Dave.
Hi David, As a starter I would suggest you checkout the "make oldconfig" kernel configuration method (see /usr/src/`uname -r`). This takes the configuration of your currently running kernel (in your case 2.4.4) and prompts you for settings for configuration options which are new to your new kernel. Make sure to run this from the top level of the source tree of your new kernel. You should also look up the kernel HOWTO. You will also find information on the www.kernel.org site and also on www.linuxnewbies.org Kind regards, Simon David Spencer wrote:
Okay I've downloaded 2.4.14 and I have a couple of questions:
1. I have a stock 7.2 install; what system implications are there? Does the new kernel require new versions of anything in 7.2? (for example: new libraries, new compiler, is there anything that will fall over when I boot with a later kernel?)
2. How do I rebuild the kernel with the same options as the stock kernel was built with? Is this even possible given the old one is 2.4.4 and I'm about to replace it with 2.4.14? Is it possible to "import" one kernel's build settings into a later version? I would like to keep the changes needed down to a bare minimum.
2a. I suppose I'm asking if /usr/src/linux/arch/i386/config.in or defconfig is the "factory settings" and if whichever file it is can be used in 2.4.14 - perhaps not directly but can it be modified to work?
3. If my attempt at upgrading the kernel goes belly-up, can I tweak the settings in the stock kernel and rebuild it in place, i.e. in /usr/src/linux? I need to modify SEMOPM in sem.h. Again how do I rebuild the kernel with the same config settings as at the factory?
Thanks, Dave.
If you are in the UK, there is an article in the current PCW mag (January issue) which has a long article on Linux, including the steps to upgrade the kernel. Haven't read it all yet, so don't know how relevant it is. Regards, David On Mon, 19 Nov 2001 14:32:34 +0000, Simon Heaton wrote:
Hi David,
As a starter I would suggest you checkout the "make oldconfig" kernel configuration method (see /usr/src/`uname -r`). This takes the configuration of your currently running kernel (in your case 2.4.4) and prompts you for settings for configuration options which are new to your new kernel. Make sure to run this from the top level of the source tree of your new kernel.
You should also look up the kernel HOWTO. You will also find information on the www.kernel.org site and also on www.linuxnewbies.org
Kind regards,
Simon
David Spencer wrote:
Okay I've downloaded 2.4.14 and I have a couple of questions:
1. I have a stock 7.2 install; what system implications are there? Does the new kernel require new versions of anything in 7.2? (for example: new libraries, new compiler, is there anything that will fall over when I boot with a later kernel?)
2. How do I rebuild the kernel with the same options as the stock kernel was built with? Is this even possible given the old one is 2.4.4 and I'm about to replace it with 2.4.14? Is it possible to "import" one kernel's build settings into a later version? I would like to keep the changes needed down to a bare minimum.
2a. I suppose I'm asking if /usr/src/linux/arch/i386/config.in or defconfig is the "factory settings" and if whichever file it is can be used in 2.4.14 - perhaps not directly but can it be modified to work?
3. If my attempt at upgrading the kernel goes belly-up, can I tweak the settings in the stock kernel and rebuild it in place, i.e. in /usr/src/linux? I need to modify SEMOPM in sem.h. Again how do I rebuild the kernel with the same config settings as at the factory?
Thanks, Dave.
Il 12:27, lunedì 19 novembre 2001, David Spencer ha scritto:
Okay I've downloaded 2.4.14 and I have a couple of questions:
1. I have a stock 7.2 install; what system implications are there? Does the new kernel require new versions of anything in 7.2? (for example: new libraries, new compiler, is there anything that will fall over when I boot with a later kernel?)
I dont think so. Maybe you have to upgrade the quota package, if you use them (I am having problem with that stuff, I am gonna change it soon).
2. How do I rebuild the kernel with the same options as the stock kernel was built with? Is this even possible given the old one is 2.4.4 and I'm about to replace it with 2.4.14? Is it possible to "import" one kernel's build settings into a later version? I would like to keep the changes needed down to a bare minimum.
There should be a .config file somewhere. It comes with the standard suse kernel. I think you can also get a .config file from gunzipping /proc/config.gz I do not know if you are running into problems switching from a suse patched kernel to a standard kernel.
2a. I suppose I'm asking if /usr/src/linux/arch/i386/config.in or defconfig is the "factory settings" and if whichever file it is can be used in 2.4.14 - perhaps not directly but can it be modified to work?
3. If my attempt at upgrading the kernel goes belly-up, can I tweak the settings in the stock kernel and rebuild it in place, i.e. in /usr/src/linux? I need to modify SEMOPM in sem.h. Again how do I rebuild the kernel with the same config settings as at the factory?
You do not need to erase your old running kernel. Just change its filename and add the entry in lilo.conf I think you will have to recompile alsa modules too, if yuo use them to hear sounds. Praise
participants (9)
-
David
-
David Spencer
-
Gert-Jan Rodenburg
-
John Scott
-
Jon Tillman
-
Karol Pietrzak
-
Lee O'Malley
-
Praise
-
Simon Heaton