You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I think it is a question of "how stable is it?" to be on an EOL kernel.

Frequently a kernel needs to be replaced because of newer hardware compatibility or for security reasons.

For example, my current hardware cannot run X using the Slackware 14.0 kernel 3.2.29.

So I had to upgrade my kernel to a later one.

To keep a "stable" system the logical thing to do is upgrade to the latest 3.2 kernel, which today is 3.2.41

A jump staying on the same 3.2 level is usually fairly easy as the kernel configuration does not change very much at all.

If kernel 3.2.29 were EOL then I would be forced to go to 3.4 or higher in order to make the system work.

The kernel jump from 3.2 to 3.4 introduces changes to the configuration for which there are no easy answers.

Try configuring a 3.4 kernel starting with a config file from kernel 3.2.29.
Then use "make oldconfig" and you will see all the questions that need to be answered...

So a kernel jump to a new level introduces instability because there are more changes than simply upgrading a kernel on the same level.

Fair enough Usually Pat's pretty good about providing different .configs for kernel branches, for example there's a 3.5 and 3.6 .config in /testing and a 3.7 in -current. I do understand what you are saying though, I'd prefer to see a LTS kernel used for the next stable.

I tried to jump from 3.2.29 to 3.2.40 and experienced a couple of hard system lockups this week, so I'm not sure jumping between LTS releases is completely safe, but it's probably safer than jumping between minor number releases.

I'd wager -current will release with the next branch marked LTS, but time will tell!

I think PV has already stated the '3.7.1' will eventually be the kernel of choice.

Just upgraded my Slackware64 14.0 to '3.7.10' to get the Intel Corporation Centrino Wireless-N 1030 working properly after my Laptop motherboard and wireless daughter-board were replaced by Dell. They still need to replace the USB daughter-board that is still erratic.

Untar Linus' source in /usr/src. Make all files owned by root:root with reasonable perms. Install a suitable .config, or use make menuconfig, etc. An example would be to use one of the config files here:
# cat config-generic-3.7.10 > /usr/src/linux-3.7.10/.config

Then run the build programs:
make oldconfig
make bzImage
make clean
make prepare
rm .version

That's it! You now have a clean Slackware-configured Linux source tree. The kernel in Slackware supports SMP. With as common as multicore CPUs and SMP boards have become, this seemed like the obvious choice. The kernels are probably better for single CPU machines, too, if they will run them. At this point if you are running huge.s or generic.s, you should have no problems building kernel modules. Have fun! :-) Pat

I think PV has already stated the '3.7.1' will eventually be the kernel of choice.

I think you meant 3.7.10 not .1, but what he actually said was:

Quote:

Here we go with some more updates... a few notes on them are in order.For this kernel update I decided to go with 3.7.10. Yeah, the 3.7 series
is EOL, but I've heard about some broken drivers in 3.8.x that make me
hesitate to push forward. Another option might be to move to 3.4.x, which
is working on my machine finally (a clocksource bug was crashing it with
earlier versions).

"For this kernel update". It doesn't necessarily mean he intends to ship with it when the time comes. Maybe the issues in 3.8 that he's trying to avoid will have been resolved by upstream before current hits RC1.