On 12/18/05, Maciej Żenczykowski maze@cela.pl wrote:

...

Short and easy answer "yum --enablerepo install kernel"

yum --enablerepo centosplus install kernel

GAH! yes. thank you... I'm glad someone was here to translate my babbling into something resembling coherent advice.

You wouldn't happen to know where I left my damn car keys now would you? :-P

-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center

I'd assume

yum --enablerepo centosplus install kernel-devel

:)

Ok, i installed the kernel from the centosplus repo as you told me but when i try to install nvidia driver(from nvidia), the installer said that it can not find the source file for the kernel in order to build the nvidia module!!! Where can i get the source file for the unsupport kernel?

I think i gonna compile the kernel by myself however, i dont know where to find the kernel source code. Is it possible to get the lastest kernel source code from the kernel.org and make oldconfig and compile it? I guess i also need to upgrade the centOS stock gcc. Thanks for respond, guys

It's possible, yes. It's generally a VERY bad idea though, as the centos/RHEL kernels are VERY heavily patched, and the centos/RHEL system is built on them, and designed to work with them. In some cases, updates depend on you using a specific kernelYou'll jeopardize stability by building your own kernel from kernel.org sources. This is true for most modern distros, not just centos and RHEL. Rebuilding the kernel is no longer something required or recommended for the average linux user. We've provided a secondary kernel that has the driver you requested, so I don't see a pressing need for you to rebuild the kernel. Yes rebuilding is possible. No I don't recommend it. You'll probably have issues, at which point I'll probably recommend you use the provided kernels. If it breaks, you get to keep all the pieces.

-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center

On Dec 18, 2005, at 3:41 PM, Jim Perrin wrote:

Long complicated answer: you'd need to get the src rpm, edit the .config used to add support for the driver, rebuild the rpm.... etc.

this is not quite correct; rather that messing with the kernel SRPM, you should also be able to pull down the kernel-source RPM:

yum -y install kernel-source

this will create /usr/src/linux-<kernel version>, which contains the kernel source.

this doc is old, but you may be able to compile a custom kernel using a similar procedure:

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1- custom-kernel-modularized.html

but i'd add my voice to those recommending that you NOT compile you own kernel, and instead use the centosplus kernel, especially if it contains the module(s) you need.

-steve

--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v

On Sun, 2005-12-18 at 18:28 -0500, lnthai2002@aim.com wrote:

this is not quite correct; rather that messing with the kernel SRPM, you should also be able to pull down the kernel-source RPM: yum -y install kernel-source

That was dropped _after_ Fedora Core 1 and, subsequently, RHEL 3 -- i.e., it essentially died with kernel 2.4. I explain this and others in my blog entry here: http://thebs413.blogspot.com/2005/10/kernel-26-on-fedora-based-systems.html

Yes is it winded, but I wrote it for a reason. It explains almost everything you might want to know, as well as "proper" kernel building which is how Red Hat has been building its own kernels since Red Hat Linux 6 (yes, that long), that is now their recommended as of Fedora Core 2 and, subsequently, RHEL 4.

this will create /usr/src/linux-<kernel version>, which contains the kernel source.

Building the kernel in the system's root has been deprecated ever since the header issues of Red Hat Linux 7 -- especially once "make mrproper" was introduced. "make mrproper" cleans out files -- and that means its better to have it wipe out a /usr/include directory located inside of the RPM build process chroot than on the actual root of your system.

this doc is old, but you may be able to compile a custom kernel using a similar procedure: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1-cus tom-kernel-modularized.html

Again, those procedures are now _useless_ for the most part.

Although Red Hat did include a "kernel-sourcecode-*.i386.rpm" for Fedora Core 2 for some time, the _default_ in the kernel-2.6.SPEC file since mid-FC2 is now to _not_ produce that .i386.rpm. anymore. That includes for RHEL 4.

but i'd add my voice to those recommending that you NOT compile you own kernel, and instead use the centosplus kernel, especially if it contains the module(s) you need.

Rebuilding a kernel is _not_ that much of an issue *IF* you use the same system that Red Hat has been using since Red Hat Linux 6 -- the same system forced upon you with FC 2/RHEL 4. Ideally this should still be in the chroot itself, and _not_ by merely symlinking from /usr/src/redhat/BUILD/kernel/linux-* to /usr/src/linux-*.

On Dec 18, 2005, at 7:46 PM, Bryan J. Smith wrote:

That was dropped _after_ Fedora Core 1 and, subsequently, RHEL 3 -- i.e., it essentially died with kernel 2.4. I explain this and others in my blog entry here: http://thebs413.blogspot.com/2005/10/kernel-26-on-fedora-based- systems.html

hey, now i'm in the modern world!

thanks for the info. :)

-steve

--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v

-----Original Message----- From: Steve Huff shuff@vecna.org To: CentOS mailing list centos@centos.org Sent: Sun, 18 Dec 2005 18:18:23 -0500 Subject: Re: [CentOS] Where is the kernel source code???

On Dec 18, 2005, at 3:41 PM, Jim Perrin wrote:

Long complicated answer: you'd need to get the src rpm, edit the .config used to add support for the driver, rebuild the rpm.... etc.

this is not quite correct; rather that messing with the kernel SRPM, you should also be able to pull down the kernel-source RPM:

yum -y install kernel-source

this will create /usr/src/linux-<kernel version>, which contains the kernel source.

this doc is old, but you may be able to compile a custom kernel using a similar procedure:

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1-cus tom-kernel-modularized.html

but i'd add my voice to those recommending that you NOT compile you own kernel, and instead use the centosplus kernel, especially if it contains the module(s) you need.

-steve

--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v

_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

How do i know that the centOSplus kernel has support for my device(in my case bt848 capture device). I must see the config file right? But rpm doesnt put that config file into /boot Thanks, guys NHUT THAI LE ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.

...

How do i know that the centOSplus kernel has support for my device(in my case bt848 capture device). I must see the config file right? But rpm doesnt put that config file into /boot

if you know the module name for your device then you can check rpm file manifest to see if it contains the appropriate module

Sometimes you need to compile your own drivers, since no one kernel has all drivers. Especially out of kernel drivers.

Doubtful, a properly compiled module kernel can contain all the drivers prebuild as modules - as far as I know this is what the centosplus kernel does...

Cheers, MaZe.

On Mon, 2005-12-19 at 01:08 +0100, Maciej Żenczykowski wrote:

...

...

How do i know that the centOSplus kernel has support for my device(in my case bt848 capture device). I must see the config file right? But rpm doesnt put that config file into /boot

if you know the module name for your device then you can check rpm file manifest to see if it contains the appropriate module

...

Sometimes you need to compile your own drivers, since no one kernel has all drivers. Especially out of kernel drivers.

Doubtful, a properly compiled module kernel can contain all the drivers prebuild as modules - as far as I know this is what the centosplus kernel does...

---- actually I need to build the megaraid module (not megaraid_mbox or megaraid_mm) that has been deemed by RHEL and Dell not suitable for inclusion (see release notes)...so I do build the module from the source. While I am there, I also build the appletalk module though as many have pointed out, that one is available in the kernel in centosplus.

Craig

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sun, Dec 18, 2005 at 08:22:36PM -0600, Kevin Krieser wrote:

Another, fatal, use of the standard X86 kernel provided by Redhat, and I assume in the unsupported kernel, is the requirement of at least a 686 (or Athlon) CPU. When you have to support 586 based systems, you have to, at a minimum, recompile the kernel. And replace the 686 glibc with the 386 version. And replace the SSL libraries too._______________________________________________

Okey, so someone please clarify this for me:

# uname -a Linux XXXXXXX.XXXXXXXXXX.com 2.6.9-11.EL #1 Wed Jun 8 20:20:13 CDT 2005 i586 i586 i386 GNU/Linux

# cat /etc/redhat-release CentOS release 4.1 (Final)

# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 7 model name : AMD-K6tm w/ multimedia extensions

# rpm -q --qf "%{ARCH}\n" kernel i586

Unless you mean that CentOS provides 586 kernels, even if RH doesn't.

In any case, I think it needs clarification.

This is a 4.1 machine, yes, but we do have

http://mirror.centos.org/centos/4/updates/i386/RPMS/kernel-2.6.9-22.0.1.EL.i...

avaliable.

OpenSSL is also avaliable on the i386, i586 and i686 flavors on the CentOS 4 updates repository.

Best Regards,

- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sun, Dec 18, 2005 at 09:24:33PM -0600, Kevin Krieser wrote:

...

# rpm -q --qf "%{ARCH}\n" kernel i586

Unless you mean that CentOS provides 586 kernels, even if RH doesn't.

In any case, I think it needs clarification.

Apparently Centos recompiles it for 586. I figured that they would have the same limitation in this regard than Redhat.

That is why I proposed a clarification. I don't have any RH machines here, and every one I used in the past 2 years were 686+, so I could not verify it.

Since it would be either a misinterpretation of what redhat distributes, or CentOS building for i586, I got confusing, at least for me.

At work we still have to use Redhat, due to customer requirements.

I really can't see anyone paying for RHEL and using it on outdated hardware. Of course I might be wrong here, and I'm sure there are some exceptions. Maybe test boxes. In any case, I can understand why RH doesn't ship 586- kernels.

[]s

PS: Drifting too far into politics now. If we decide to continue this discussion, I would like to suggest the linux-practices list :)

- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I'll be replying to this on the linux practices list.

In case anyone wants to join in:

http://www.paxconsultoria.com/mailman/listinfo/linux-practices

PS: This is my last plug of the list practices list, although I will still notify when I'm answering there instead of here.

On Sun, Dec 18, 2005 at 09:47:11PM -0600, Matt Lawrence wrote:

On 12/18/05, Rodrigo Barbosa rodrigob@suespammers.org wrote:

...

I really can't see anyone paying for RHEL and using it on outdated hardware. Of course I might be wrong here, and I'm sure there are some exceptions. Maybe test boxes. In any case, I can understand why RH doesn't ship 586- kernels.

Ummm, I don't consider many of the VIA mini-ITX systems to be "outdated" or even my Soekris net4801. Special purpose perhaps, but not outdated.

-- Matt

- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

On Dec 18, 2005, at 9:40 PM, Rodrigo Barbosa wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sun, Dec 18, 2005 at 09:24:33PM -0600, Kevin Krieser wrote:

...

...

# rpm -q --qf "%{ARCH}\n" kernel i586

Unless you mean that CentOS provides 586 kernels, even if RH doesn't.

In any case, I think it needs clarification.

Apparently Centos recompiles it for 586. I figured that they would have the same limitation in this regard than Redhat.

That is why I proposed a clarification. I don't have any RH machines here, and every one I used in the past 2 years were 686+, so I could not verify it.

Since it would be either a misinterpretation of what redhat distributes, or CentOS building for i586, I got confusing, at least for me.

...

At work we still have to use Redhat, due to customer requirements.

I really can't see anyone paying for RHEL and using it on outdated hardware. Of course I might be wrong here, and I'm sure there are some exceptions. Maybe test boxes. In any case, I can understand why RH doesn't ship 586- kernels.

[]s

PS: Drifting too far into politics now. If we decide to continue this discussion, I would like to suggest the linux-practices list :)

---

Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDpiu7pdyWzQ5b5ckRArnyAJ9j0Rd0lZzbRWg8kLYbIp1N6ipKtQCglcwo LWPJ7qgrk4Q/toGfjyT3agA= =ZM+S -----END PGP SIGNATURE-----

In our case, our first Linux port, from SCO Openserver, targeted Redhat 7.1 on these platforms, where money wasn't available to upgrade much of the older computers. We also target newer computers, which had the disadvantages that the obsolete version of SCO we were using didn't support many of the newer features, such as PCMCIA.

Redhat 7.1 worked fine for a couple versions, then Redhat decided to drop support for their non EL distributions, and it was determined that RHEL 2.1 was a relatively easy port, since it was based on 7.2, and had security support without having to do the security patches ourselves.

Now, there is a desire to support an accredited OS, which essentially requires either a version of Suse, or Redhat 3 or later.

So that is how you can get into a Enterprise level OS for obsolete hardware :)

I also can understand why a company like Redhat won't support old hardware like this out of the box. Who cares, in the enterprise realm, whether Redhat can provide the fastest web server on 486, when you can buy 3 gigahertz computers with 1 gig or more RAM for as cheap as they are nowadays in more widely available platforms. By not supporting it, Redhat doesn't have to test, keep all these configurations around, etc.

This is kind of an issue on the LKML right now. Not 486's, but trying to support large workloads on 32 bit computers when people can go to 64 bit CPUs, for example, where many of the limitations go away.

Unless you mean that CentOS provides 586 kernels, even if RH doesn't.

Simple. RHEL doesn't support 586 - but CentOS does (as does centosplus).

Cheers, MaZe.