is there a website you could point me to with some documentation on this? the archives dont really tell you how to do it, just that it exists.

thanks

On 4/1/06, Maciej Żenczykowski maze@cela.pl wrote:

Install the unsupported kernel from the centosplus repo (lot's of messages in the list archives).

On Sat, 1 Apr 2006, Nick Smith wrote:

...

Im sorry if this is a newb question, but how do you recompile the kernel in CentOS 4.3? I need to add reiserfs support (even though the setup detected it) the kernel it gave me didnt have support for reiserfs, and my entire fileserver is all reiserfs. I tried the gentoo way, which im use to and it bombed. What do i need to do? does it install kernel source by default? I couldnt find any good documentation on the subject, and this is my first RH type install.

thanks

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

---

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

-- Linux, because I'd rather own a free OS than steal one that's not worth paying for.

cant i just recompile the kernel with reiserfs support? where is the documentation for recompiling the kernel? i can enable it myself, i dont need a special kernel do i? ive never had to have one for any other distro, if i can get the kernel source i should be able to just "make menuconfig" and turn on what i want right? why do i have to go into unsupported territory to get a kernel with the support i need? is this just the RH/CentOS way? sorry for all the stupid questions ive just never used a RH type distro before.

thanks

On 4/1/06, Jim Perrin jperrin@gmail.com wrote:

On 4/1/06, Nick Smith nick.smith79@gmail.com wrote:

...

is there a website you could point me to with some documentation on this? the archives dont really tell you how to do it, just that it exists.

http://mirror.centos.org/centos-4/4/centosplus/Readme.txt

-- Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- Linux, because I'd rather own a free OS than steal one that's not worth paying for.

On Sat, 2006-04-01 at 15:59 -0500, Nick Smith wrote:

cant i just recompile the kernel with reiserfs support? where is the documentation for recompiling the kernel? i can enable it myself, i dont need a special kernel do i? ive never had to have one for any other distro, if i can get the kernel source i should be able to just "make menuconfig" and turn on what i want right? why do i have to go into unsupported territory to get a kernel with the support i need? is this just the RH/CentOS way? sorry for all the stupid questions ive just never used a RH type distro before.

Short version: you can do everything you want to do. But you have to operate in the environment of RH setups and the does bring some differences.

But the real stopper is the difference in underlying philosophy: CentOS is "enterprise oriented". This means it is not designed to make customization of every bell and whistle easy, but is designed to provide maximum stability, reliability, upgradeabiliy and maintainability.

This means that CentOS espouses and supports things oriented to minimizing end-user (admin) induced problems. Upgrades by rpm and yum is one leg of that. Offering a "non-standard" kernel is another leg. You see, if you modify your copy and then another upgrade to kernel comes out, your changes may be happily overwritten.

You can avoid this by doing your upgrades and then never taking an automatic upgrade again (for the kernel only? Or are other things which might depend on some kernel facility also affected?).

It's really easy to do it the CentOS way. The hard part is convincing yourself that it's worth the effort when you can "do what I always did" and not have to learn.

MHO, HTH Bill

<snip>

That's because 98% of the time recompiling the kernel is not something you really want to do, and the remaining 2% of the time you just use rpmbuild --rebuild kernel-.....src.rpm

And if that doesn't work _then_ you're out of luck (the above works for me with a couple different kernels). Want to change something? Unpack the srpm into the appropriate directories (just install the src.rpm) and edit the spec file and configuration files and or add kernel patches to the spec file, etc...

Of course you should do all the above as a non-root user for safeties sake, but that's a tad harder (need to have a good macro file - here's mine, although it's rather minimal and not all that good: ~/.rpmmacros: %packager Maciej Zenczykowski %distribution CentOS4 %vendor TCS-II-UJ %_signature gpg %_gpg_name maze@tcs.ii.uj.edu.pl %_gpg_path ~/.gnupg

%_topdir /home/buildcentos/rpm %_tmppath %{_topdir}/tmp

#%_rpmtopdir %{_topdir}/%{name} #%_builddir %{_rpmtopdir}/BUILD #%_rpmdir %{_rpmtopdir}/RPMS #%_sourcedir %{_rpmtopdir}/SOURCES #%_specdir %{_rpmtopdir}/SPECS #%_srcrpmdir %{_rpmtopdir}/SRPMS

%disttag centos4 %repotag maze

# Change default RPM query format to show ARCH %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} # %_query_all_fmt %%{epoch}:%%{name}-%%{version}-%%{release}.%%{arch}

Cheers, MaZe.

On Sat, 1 Apr 2006, Bogdan Nicolescu wrote:

Nick,

The question of kernel compilation is a periodic question, and usually the answer will be anything else except the process itself. I asked the same question just a couple of days ago. Don't bother wasting time waiting for an answer, and start searching the web. rpmbuild seems to be part of the method required for a custom kernel.

The irony is that for a distributions which prides itself to be a recompilation of another distribution (RH) (and we're all grateful for that), the process of recompiling one of the integral part of the districtution, the kernel, is one of the best kept secrets. Why can't some just give a straight answer or point to a page that has the answer?

Anyway, I have searched, and found this guides which might help:

http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-kernel

and

http://www.mjmwired.net/resources/mjm-kernel-fc4.html

Didn't have the time to try it out yet myself. Next week sometimes.

--- Nick Smith nick.smith79@gmail.com wrote:

...

Im sorry if this is a newb question, but how do you recompile the kernel in CentOS 4.3? I need to add reiserfs support (even though the setup detected it) the kernel it gave me didnt have support for reiserfs, and my entire fileserver is all reiserfs. I tried the gentoo way, which im use to and it bombed. What do i need to do? does it install kernel source by default? I couldnt find any good documentation on the subject, and this is my first RH type install.

thanks

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

---

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

You're missing the point... If you want to get into customizing the kernel, you might as well switch to another non-enterprise distribution, more bleeding edge and the like (fedora, gentoo, etc.). An enterprise-level/class distribution is meant to work with _minimum_ user/admin intervention. Compiling the kernel is not a small thing and can potentially affect a lot of things, this simply is NOT what you want to do on a system you want to be a stable server. Furthermore a lot of modules can be compiled outside the kernel tree proper (I've compiled a few netfilter modules for CentOS this way). And, yes, you can compile your own kernel, you can do it for one machine, maybe two, maybe three. But what happens when you start to have to administer and provide updates for more computers (18 in my case) - do you really want to go to the pain of running a kernel compilation for every single one of those machines - and rerunning that every two months when a kernel update comes out? What for, what does this give me which the centosplus kernel doesn't? In almost all cases the centosplus kernel is the far better solution.

MaZe.

On Sat, 1 Apr 2006, Bogdan Nicolescu wrote:

[sarcasm]And all this time, decade+, I though the ability to recompile especially the kernel was the main difference/advantage between a source based O.S. and a binary-only O.S. I don't know how you came out with the statistics but I have a funny feeling you are 100% wrong.[/sarcasm]

Everybody should want to recompile the kernel, if not for the experience, but for removing the bloat. Does everybody really need every chipset compiled in the kernel! If the degree of dificulty of building a custom kernel on Centos change from the traditional method (make clean, make mrproper, make xconfig, etc) than say so, and point to an authoritative howto guide, if there is any. But whatever you do please don't insult by deciding for 98% of us what is and what is not "something you really want to do". I can only speak for myself, and I really want to be able to recompile the Centos kernel, otherwise I wouldn't waste my energy asking a zillion times how to compile Centos' kernel.

Second irony (from second hand information) is that the vanila kernel compile just fine on Centos using the traditional method.

--- Maciej ?enczykowski maze@cela.pl wrote:

...

That's because 98% of the time recompiling the kernel is not something you really want to do, and the remaining 2% of the time you just use rpmbuild --rebuild kernel-.....src.rpm

And if that doesn't work _then_ you're out of luck (the above works for me with a couple different kernels). Want to change something? Unpack the srpm into the appropriate directories (just install the src.rpm) and edit the spec file and configuration files and or add kernel patches to the spec file, etc...

Of course you should do all the above as a non-root user for safeties sake, but that's a tad harder (need to have a good macro file - here's mine, although it's rather minimal and not all that good: ~/.rpmmacros: %packager Maciej Zenczykowski %distribution CentOS4 %vendor TCS-II-UJ %_signature gpg %_gpg_name maze@tcs.ii.uj.edu.pl %_gpg_path ~/.gnupg

%_topdir /home/buildcentos/rpm %_tmppath %{_topdir}/tmp

#%_rpmtopdir %{_topdir}/%{name} #%_builddir %{_rpmtopdir}/BUILD #%_rpmdir %{_rpmtopdir}/RPMS #%_sourcedir %{_rpmtopdir}/SOURCES #%_specdir %{_rpmtopdir}/SPECS #%_srcrpmdir %{_rpmtopdir}/SRPMS

%disttag centos4 %repotag maze

# Change default RPM query format to show ARCH %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} # %_query_all_fmt %%{epoch}:%%{name}-%%{version}-%%{release}.%%{arch}

Cheers, MaZe.

On Sat, 1 Apr 2006, Bogdan Nicolescu wrote:

...

Nick,

The question of kernel compilation is a periodic question, and usually the answer will be anything

else

...

except the process itself. I asked the same

question

...

just a couple of days ago. Don't bother wasting

time

...

waiting for an answer, and start searching the

web.

...

rpmbuild seems to be part of the method required

for a

...

custom kernel.

The irony is that for a distributions which prides itself to be a recompilation of another

distribution

...

(RH) (and we're all grateful for that), the

process of

...

recompiling one of the integral part of the districtution, the kernel, is one of the best kept secrets. Why can't some just give a straight

answer

...

or point to a page that has the answer?

Anyway, I have searched, and found this guides

which

...

might help:

http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-kernel

...

...

and

http://www.mjmwired.net/resources/mjm-kernel-fc4.html

...

...

Didn't have the time to try it out yet myself.

Next

...

week sometimes.

--- Nick Smith nick.smith79@gmail.com wrote:

...

Im sorry if this is a newb question, but how do

you

...

...

recompile the kernel in CentOS 4.3? I need to add reiserfs

support

...

...

(even though the setup detected it) the kernel it gave me didnt

have

...

...

support for reiserfs, and my entire fileserver is all

reiserfs.

...

...

I tried the gentoo way, which im use to and it bombed. What

do

...

...

i need to do? does it install kernel source by default? I couldnt

find

...

...

any good documentation on the subject, and this is my

first

...

...

RH type install.

thanks

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

---

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

---

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

---

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

Already did so.

On Sat, 1 Apr 2006, Bogdan Nicolescu wrote:

"And, yes, you can compile your own kernel..."

Please do tell how, or post a link to the procedure. I'm assuming you are taking the default Centos kernel, and not a vanilla/unsupported kernel.

--- Maciej ?enczykowski maze@cela.pl wrote:

...

You're missing the point... If you want to get into customizing the kernel, you might as well switch to another non-enterprise distribution, more bleeding edge and the like (fedora, gentoo, etc.). An enterprise-level/class distribution is meant to work with _minimum_ user/admin intervention. Compiling the kernel is not a small thing and can potentially affect a lot of things, this simply is NOT what you want to do on a system you want to be a stable server. Furthermore a lot of modules can be compiled outside the kernel tree proper (I've compiled a few netfilter modules for CentOS this way). And, yes, you can compile your own kernel, you can do it for one machine, maybe two, maybe three. But what happens when you start to have to administer and provide updates for more computers (18 in my case) - do you really want to go to the pain of running a kernel compilation for every single one of those machines - and rerunning that every two months when a kernel update comes out? What for, what does this give me which the centosplus kernel doesn't? In almost all cases the centosplus kernel is the far better solution.

MaZe.

On Sat, 1 Apr 2006, Bogdan Nicolescu wrote:

...

[sarcasm]And all this time, decade+, I though the ability to recompile especially the kernel was the main difference/advantage between a source based

O.S.

...

and a binary-only O.S. I don't know how you came

out

...

with the statistics but I have a funny feeling you

are

...

100% wrong.[/sarcasm]

Everybody should want to recompile the kernel, if

not

...

for the experience, but for removing the bloat.

Does

...

everybody really need every chipset compiled in

the

...

kernel! If the degree of dificulty of building a custom kernel on Centos change from the

traditional

...

method (make clean, make mrproper, make xconfig,

etc)

...

than say so, and point to an authoritative howto guide, if there is any. But whatever you do

please

...

don't insult by deciding for 98% of us what is and what is not "something you really want to do". I

can

...

only speak for myself, and I really want to be

able to

...

recompile the Centos kernel, otherwise I wouldn't waste my energy asking a zillion times how to

compile

...

Centos' kernel.

Second irony (from second hand information) is

that

...

the vanila kernel compile just fine on Centos

using

...

the traditional method.

--- Maciej ?enczykowski maze@cela.pl wrote:

...

That's because 98% of the time recompiling the kernel is not something you really want to do, and the remaining 2% of the

time

...

...

you just use rpmbuild --rebuild kernel-.....src.rpm

And if that doesn't work _then_ you're out of

luck

...

...

(the above works for me with a couple different kernels). Want to change something? Unpack the srpm into the appropriate directories (just

install

...

...

the src.rpm) and edit the spec file and configuration files and or add kernel patches to the spec file, etc...

Of course you should do all the above as a

non-root

...

...

user for safeties sake, but that's a tad harder (need to have a

good

...

...

macro file - here's mine, although it's rather minimal and not all

that

...

...

good: ~/.rpmmacros: %packager Maciej Zenczykowski %distribution CentOS4 %vendor TCS-II-UJ %_signature gpg %_gpg_name maze@tcs.ii.uj.edu.pl %_gpg_path ~/.gnupg

%_topdir /home/buildcentos/rpm %_tmppath %{_topdir}/tmp

#%_rpmtopdir %{_topdir}/%{name} #%_builddir %{_rpmtopdir}/BUILD #%_rpmdir %{_rpmtopdir}/RPMS #%_sourcedir %{_rpmtopdir}/SOURCES #%_specdir %{_rpmtopdir}/SPECS #%_srcrpmdir %{_rpmtopdir}/SRPMS

%disttag centos4 %repotag maze

# Change default RPM query format to show ARCH %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} # %_query_all_fmt

%%{epoch}:%%{name}-%%{version}-%%{release}.%%{arch}

...

...

Cheers, MaZe.

On Sat, 1 Apr 2006, Bogdan Nicolescu wrote:

...

Nick,

The question of kernel compilation is a periodic question, and usually the answer will be

anything

...

...

else

...

except the process itself. I asked the same

question

...

just a couple of days ago. Don't bother wasting

time

...

waiting for an answer, and start searching the

web.

...

rpmbuild seems to be part of the method required

for a

...

custom kernel.

The irony is that for a distributions which

prides

...

...

...

itself to be a recompilation of another

distribution

...

(RH) (and we're all grateful for that), the

process of

...

recompiling one of the integral part of the districtution, the kernel, is one of the best

kept

...

...

...

secrets. Why can't some just give a straight

answer

...

or point to a page that has the answer?

Anyway, I have searched, and found this guides

which

...

might help:

http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-kernel

...

...

...

...

and

http://www.mjmwired.net/resources/mjm-kernel-fc4.html

...

...

...

...

Didn't have the time to try it out yet myself.

Next

...

week sometimes.

--- Nick Smith nick.smith79@gmail.com wrote:

...

Im sorry if this is a newb question, but how do

you

...

...

recompile the kernel in CentOS 4.3? I need to add reiserfs

support

...

...

(even though the setup detected it) the kernel it gave me didnt

have

=== message truncated ===

---

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

Bogdan Nicolescu spake the following on 4/1/2006 3:16 PM:

"And, yes, you can compile your own kernel..."

Please do tell how, or post a link to the procedure. I'm assuming you are taking the default Centos kernel, and not a vanilla/unsupported kernel.

As soon as you change something, you have an unsupported kernel, no matter where you got it from. So what is the difference how you do it.

People are still seemingly deciding whats "right" for a person without knowing their situation. No one is asking for support on a kernel they've compiled themselves, nor are they expecting it. They aren't going to slap Centos when a problem arises from it and blame them.

Just some situations sometimes seem to require it. One thing I'll likely be doing in the near future is changing the kernel frequency for example, and as far as I know its only possible with a recompile. Its unlikely it will break much, but if it does, thats on my head, and thats fine. I won't be asking the list why my recompiled kernel suddenly has a fault unless its the same on a default kernel of which I intend to run both, depending on requirements.

I fully understand its not a Centos Supported issue in that sense due to its position, but isn't this mainly what this email list is for as well (i.e to bounce ideas, problems, solutions between each other who have hit a problem and possibly come up with a solution albeit official or unnoficial whatever that means in this context)?

Ian

On 4/2/06, Jim Perrin jperrin@gmail.com wrote:

...

Everybody should want to recompile the kernel, if not for the experience, but for removing the bloat. Does everybody really need every chipset compiled in the kernel!

Uh, that's the beauty of building modules. You only load what you need. And the rhel/centos kernel is almost entirely modular.

If the degree of dificulty of building a

...

custom kernel on Centos change from the traditional method (make clean, make mrproper, make xconfig, etc) than say so, and point to an authoritative howto guide, if there is any.

The idea behind the EL kernel is that it's a stable, reliable, and can be duplicated quickly and reliably across multiple machines and environments. To some non-trivial extent it's also so that there's someone ELSE to blame if it doesn't work. For some reason, employers and corporations love to pay people for support rather than rely on the merits of their tech staff. Keep in mind the nearly 700 patches that are in the EL kernel source rpm. Red Hat has basically stated that if you build your own kernel, you're on your own to support it, and as such, they're not producing documentation on how to build your own. It's not just RHEL and CentOS moving this way. Mandriva, SuSE, and to an extent, Debian and Ubuntu are also like this.

...

But whatever you do please don't insult by deciding for 98% of us what is and what is not "something you really want to do". I can only speak for myself, and I really want to be able to recompile the Centos kernel, otherwise I wouldn't waste my energy asking a zillion times how to compile Centos' kernel.

This has already been decided, and it's not an insult to you. How do you make a distribution easy to use, AND support kernel rebuilds? Is your mother or grandfather capable of rebuilding a kernel? Can they do it better than the RHEL developers who do it for a living? It's not an insult. It's a choice in ease of use vs support vs cost. If you're smart enough to rebuild the kernel, you're completely welcome to.

...

Second irony (from second hand information) is that the vanila kernel compile just fine on Centos using the traditional method.

It does, but it's not the proper method for several reasons. Vanilla kernel source will also work on centos, but it's not something we recommend, and if you break it, you get to keep the pieces. The people who want to rebuild everything aren't the people in our target audience. They're in Gentoo's target audience.

Now, to the information you wanted. There is a blog done by BJS which described the method, although I have misplaced the link. There is no official or otherwise documentation, because it's not something we actively support or recommend. Not to stop you, but for the simple logic of -> why waste time documenting something you aren't supporting when you can document the things you do support instead?

If you search the late March list archive from the last week or so, I did a very brief walkthrough of how the rebuilding is actually done. You're welcome to read through that and see if it helps.

If it doesn't.. .keep in mind that rebuilding the kernel isn't supported, and we've provided a kernel with the feature you claim to want. If you REALLY want to rebuild stuff and get your hands dirty for the experience, check out gentoo or LFS.

-- Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Sun, 2006-04-02 at 00:44 +0100, Ian mu wrote:

People are still seemingly deciding whats "right" for a person without knowing their situation.

That is an *assumption* (and you are not the first or only guilty)!

What is going on is the normal course for a project that has a certain goal and/or viewpoint. That is, one tries to educate people about options that they may be unaware of in the current context.

NOTHING WRONG WITH THAT! Further, they may try and provide some underpinnings that may convince the requester that there is value in the decision made by the project participants.

When the requester comes back with sarcasm, statements indicating what *everybody* else should want to do ("... everybody should want to rebuild their own kernel..."), etc... well, you can see where I would take that.

No one is asking for support on a kernel they've compiled themselves, nor are they expecting it. They aren't going to slap Centos when a problem arises from it and blame them.

Just some situations sometimes seem to require it. One thing I'll likely be doing in the near future is changing the kernel frequency for example, and as far as I know its only possible with a recompile. Its unlikely it will break much, but if it does, thats on my head, and thats fine. I won't be asking the list why my recompiled kernel suddenly has a fault unless its the same on a default kernel of which I intend to run both, depending on requirements.

I fully understand its not a Centos Supported issue in that sense due to its position, but isn't this mainly what this email list is for as well (i.e to bounce ideas, problems, solutions between each other who have hit a problem and possibly come up with a solution albeit official or unnoficial whatever that means in this context)?

In spite of all you state above, it is *very* common that after the requester sails off and does his own thing, he then appears on the list later on complaining that things don't work and asking for help. And then criticizing when it turns out he was burnt by his ignorance of the projects philosophy, goals and design decisions.

So although all you independent folks don't understand why replies are as they often are, there may be good reason.

And I am a hardened LFSer who loves doing my builds of *everything*. But I don't expect CentOS to support that (if I ever asked, haven't yet) without letting me know that there is a "better way", in terms of their operational design.

This is not directed at you, but I must say it for others. As Jim(?) said, if CentOS philosophy, design, implementation, support, ... is not for you, other projects may be more appropriate. Others have complained about having to work through the undesired parts of the answers and said, in effect, "Just tell me what I want to here and shut up about the other stuff".

Doesn't work that way. I hope it never does.

<snip>

MHO Bill

On Sun, 2006-04-02 at 01:26 +0100, Ian mu wrote:

Fair points, but there's a difference though (imo) between the angle some come accross from. I.e if I say I want to do X and it needs me to compile a kernel, and someone knows that there's a resolution without, then great, this is where the information becomes invaluable. Igorance is actually fine a lot of the time (as absurd as that sounds), most of us at some time or another have assumed one solution for someone else to come up with a better one. There's no shame in not knowing better, this is how we learn. This is 95% of our customers these days in fact I find.

However I wouldn't be condenscending like this list can be at times (don't mean the recent replies or even specifically this thread,

I know what you mean there. I would only say that "condescension" seems to be not limited to this list, but seems to reside in various individuals on many lists. And, IMO, is most likely in those who are very experienced, both in project members sometimes and non-members sometimes.

Please keep that in mind. Also, keep in mind that the quality of condescension can be heavily influenced by the listener. To paraphrase an old adage "Condescension is in the ear of the hearer"... sometimes! ;-)

its probably the tail of other responses), there's no harm in saying, "well ideally you could do X, but if thats not suitable, here's the link to do Y which you want". Some people just want an answer they don't understand, but thats very rare I find, most people want a solution they understand even if its not their own solution. Thats simply good education.

As mentioned, the nature of many list participants precludes the shortest possible answer. I think most tend to want to be helpful, in terms of sharing information, and that leads to the least direct answer often.

In reality though, there's rarely been an "ideal" operating that hasn't needed "something" doing which isn't necessarily following the core ideals. What people have said about RH/Centos does make perfect sense, and people do know that (mainly anyway). Unless there's an o.s that "perfectly" matches the applications that run on it, its quite likely its going to happen at some point that you need to go out of bounds.

Agreed. And I've seen this list help many (recent php threads, IIRC, is a good example?).

<snip my previous posting from below>

Anyway, let's hope that all can accomplish what they need and give others the latitude to offer opinions/education/etc. in a way that makes the project pleasant for the majority.

Bill

Jim thank you for the leads.

Sure, but actually, Johnny had it right on the money. I forgot about the kernel notation in the release notes. It's very similar to what was posted in previous threads, and probably has that "Official" tone you were hunting for.

-- Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke

On Sun, 2006-04-02 at 06:50 -0500, Johnny Hughes wrote:

There are hundreds of packages added to the CentOS kernel by the

^^^^^^^^ I meant "patches"

--- Johnny Hughes mailing-lists@hughesjr.com wrote:

On Sat, 2006-04-01 at 20:15 -0500, Jim Perrin wrote:

...

...

Jim thank you for the leads.

Sure, but actually, Johnny had it right on the

money. I forgot about

...

the kernel notation in the release notes. It's

very similar to what

...

was posted in previous threads, and probably has

that "Official" tone

...

you were hunting for.

The question was, can you do it .. you can

as to whether or not you SHOULD do it .. that is a different question entirely.

Unless you know more about building kernels than the RH development team and/or the CentOS development team ... or unless you have a problem that can not be solved in ANY OTHER WAY ... then you should use the stock kernel.

The stability of the kernel and the way it interacts with the rest of the system IS what makes CentOS. It is an Enterprise solution that is not latest/greatest. If you change the kernel, stuff starts breaking.

Example ... we have a bug report where the new ssh (which requires kernel auditing) doesn't properly list users with the "w" command. Only people with this problem ... the ones not using the standard CentOS kernel. Reason ... in this case the new kernel REQUIRES the audit and audit-lib packages to be installed ... which they don't have since they rolled their own kernel.

There are hundreds of packages added to the CentOS kernel by the upstream developers that are not in the kernel.org kernels ... everyone of those has a purpose to be there and many are required to make other parts of CentOS function. You should NEVER change the kernel or glibc unless it is absolutely required.

WHY IS THIS SO HARD TO UNDERSTAND?

What is hard to understand is if I take the same EXACT kernel Centos take, which I assume is available, and I compile everything Centos compiles in, except I compile some hardware in the kernel rather than modularize it (as Centos does), how exactly is that going to break functionality? How exactly is removing ext2 (if it is included in Centos default compilation) from the kernel is going to break Centos if I don't ever use ext2?

ps... At this point in the discussion it is not about how to compile or why/why-not compile the kernel anymore. The how question is going to be solved. If you don't want to have a rational conversation about a feature of any source-base package you don't have to scream, all you have to say "It is the way it is, because Centos says so, and if you don't like it, don't use it."

If this is/was the wrong place to have this conversation, my apologies.

--- Johnny Hughes mailing-lists@hughesjr.com wrote:

On Sun, 2006-04-02 at 12:04 -0700, Bogdan Nicolescu wrote:

...

What is hard to understand is if I take the same

EXACT

...

kernel Centos take, which I assume is available,

and I

...

compile everything Centos compiles in, except I compile some hardware in the kernel rather than modularize it (as Centos does), how exactly is

that

...

going to break functionality? How exactly is

removing

...

ext2 (if it is included in Centos default

compilation)

...

from the kernel is going to break Centos if I

don't

...

ever use ext2?

I told you where to get the kernels and how to compile it in a different post ...

Look in the SRPMS directory in the os or update trees for the latest update set, or in http://vault.centos.org/ for older versions.

Every kernel we have released has it's SRPM there.

I also pointed you to the release notes ... search for "kernel source":

Johny,

In case you didn't have the patience to read my entire previous post here is the part you forget to quote:

" . . . ps... At this point in the discussion it is not about how to compile or why/why-not compile the kernel anymore. The how question is going to be solved. If you don't want to have a rational conversation about a feature of any source-base package you don't have to scream, all you have to say "It is the way it is, because Centos says so, and if you don't like it, don't use it."

If this is/was the wrong place to have this conversation, my apologies. . . ."

Thank you for all the help, and have a really nice day.

ps. You still didn't answer my question about how not compiling ext2 into the kernel brakes everything. Don't worry, it was a rhethorical question.

http://www.its.caltech.edu/~mcc/chaos_new/Lorenz.html

On Sat, 2006-04-01 at 17:08 -0800, Ogdan Nicole's wrote:

--- "William L. Malt by" <Bills CentOS@triad.RR.com> wrote:

...

On Sun, 2006-04-02 at 00:44 +0100, Ian mu wrote:

...

<snip>

...

This is not directed at you, but I must say it for others. As Jim(?) said, if CentOS philosophy, design, implementation, support, ... is not for you, other projects may be more appropriate. Others have complained about having to work through the undesired parts of the answers and said, in effect, "Just tell me what I want to here and shut up about the other stuff".

Doesn't work that way. I hope it never does.

<snip Sig stuff>

Bill,

"[sarcasm]And all this time, decade+, I though the ability to recompile especially the kernel was the main difference/advantage between a source based O.S. and a binary-only O.S. I don't know how you came out with the statistics but I have a funny feeling you are 100% wrong.[/sarcasm]"

What was intended to be under sarcasm, was carefully delimited. Everything else was not sarcastic.

I didn't recognize that delineation meant that it was to be ignored. My apologies for that.

I have no problem with a project's philosophy, but when different signals are being sent out, and conversations on the topic end up either in history lectures, aggressive tones and/or closed threads, than I want to find out as quickly possible who or what I'm dealing with.

If CentOS philosophy is to discourage recompilation for whatever reason, than they should say so. But that is not the signal I see from this post:

http://slashdot.org/comments.pl?sid=180923&cid=14969413

Simple question... simple defintive CAPITALIZED answer (speaking of net properness)... but then god forbid someone asks "How?" because you get a lecture in everything else except on how.

Be a little more thoughtful about that? A list/project is not a single- minded individual. There will be different takes on how to respond to things out of the ordinary. Some will just feed you facts and let you go down in flames (not intentional I'm sure). Others will try to pass on hard-won lessons to save you from grief they may have experienced (intentional I'm sure). Some will echo the "party line" because they believe so strongly in the team aspect of a project. And since you are an unknown quantity... you get the best of all of them. :-)

On kernel/hacker lists, the briefest possible answer with the least amount of humanly possible tolerance (I'll stop the pejoratives there) is expected and, therefore, appropriate. Not all lists are like that.

Jim thank you for the leads.

Anyway, I see you're getting (eventually) what you want. Hope you enjoy, it works for you and you have other opportunities to see a "better side" of this project, from your PROV.

Bill

It is not a matter of being hidden, the kernel source is just not included, so the standard methods will not work if you do not have the source.

There is NO .src.rpm included unless you purchase RHEL4 from Red Hat.

On Mon, 2006-04-03 at 08:34 -0400, Steven wrote:

There is NO .src.rpm included unless you purchase RHEL4 from Red Hat.

--

OK ... this is silly

WTF are you talking about ...

---------------------------------------------------

The upstream provider has published every .src.rpm that in their original release here:

http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/

Every .src.rpm update for RHEL is here:

http://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/

(those include kernels as well as every single apckage that they have in their product)

---------------------------------------------------

CentOS has published every .src.rpm that we have built in the repo where the RPMS are (in an SRPMS directory) ... example, for the currently active CentOS-4 update set (right now, 4.3) all the .src.rpm files are here for the release:

http://mirror.centos.org/centos/4/os/SRPMS/

(You would substitute extras, centosplus, csgfs, updates, addons, etc. for os if you wanted those SRPMS)

If you wanted .src.rpm files for any of the older (non-current) update sets, they would be at:

http://vault.centos.org/4.2/os/SRPMS/

Again, if you were interested in other repos like extras, centosplus, csgfs, updates, addons, etc. ... substitute that for "os". If you are interested in something other than CentOS-4.2 out of the vault ... use that version number in place of 4.2 ... for example ... if you want to look at CentOS 3.4 updates SRPMS you would use:

http://vault.centos.org/3.4/updates/SRPMS/

Both the upstream provider and CentOS provide .src.rpms to anyone who wants to download them ... because we both believe in the GPL and Open Source Software.

Thanks, Johnny Hughes

On Sun, 2006-04-02 at 20:54 -0400, Steven wrote:

It is not a matter of being hidden, the kernel source is just not included, so the standard methods will not work if you do not have the source.

The kernel-source package is no longer included in RHEL > 4 or FC > 3 ... did you read the post I made to the release notes? This is by design of Red Hat.

The release notes tell you how to get the kernel tree ... I have already posted it twice to this thread.

On Apr 1, 2006, at 3:55 PM, Ian mu wrote:

I go along with that. Will be heading down this road myself in the not too distant future and be needing a recompile of the kernel, and for some reason its all very cloak and dagger and misdirection.

I fully understand and agree with the most of the points raised earlier, thats not in question. Sometimes people would just like a straightforward answer though or a reference to a page. If there isn't one and no one knows how to do something then fine, but thats rarely the case.

Thanks for those links, will hopefully help when have to tackle this myself.

On 4/1/06, Bogdan Nicolescu bo2k2@yahoo.com wrote: Nick,

The question of kernel compilation is a periodic question, and usually the answer will be anything else except the process itself. I asked the same question just a couple of days ago. Don't bother wasting time waiting for an answer, and start searching the web. rpmbuild seems to be part of the method required for a custom kernel.

The irony is that for a distributions which prides itself to be a recompilation of another distribution (RH) (and we're all grateful for that), the process of recompiling one of the integral part of the districtution, the kernel, is one of the best kept secrets. Why can't some just give a straight answer or point to a page that has the answer?

Anyway, I have searched, and found this guides which might help:

http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-kernel

and

http://www.mjmwired.net/resources/mjm-kernel-fc4.html

Didn't have the time to try it out yet myself. Next week sometimes.

--- Nick Smith <nick.smith79@gmail.com > wrote:

...

Im sorry if this is a newb question, but how do you recompile the kernel in CentOS 4.3? I need to add reiserfs support (even though the setup detected it) the kernel it gave me didnt have support for reiserfs, and my entire fileserver is all reiserfs. I tried the gentoo way, which im use to and it bombed. What do i need to do? does it install kernel source by default? I couldnt find any good documentation on the subject, and this is my first RH type install.

thanks

Nick

For what it's worth, some stuff may be broken that would work with a vanilla kernel, because Red Hat is making changes targeting their supported versions and customers.

About a month ago, I was trying to make a tiny 2.6 based kernel for a floppy boot, and decided to use the latest Red Hat kernel. When I got around to compiling it, it kept on failing, I believe in the memory management code. I finally gave up and used a vanilla kernel. Later, while trying to make another custom kernel, it came back when I was making smaller changes trying to create a kernel that would support older, obsolete computers like Pentiums and earlier with 128MB of RAM. It turned out to be the option for computers with < 1GB of RAM. But, since 586 computers are not a supported configuration, and since it IS an Enterprise OS, they have figured that computers running their OS would be better configured.

Now, this was an easy problem to see, since the compile would fail. Other possibilities is that an OS would compile, but have a subtle error.

On Sat, 2006-04-01 at 16:58 -0500, Steven wrote:

I found a copy of the kernel source at http://mirror.phy.olemiss.edu/mirror/scientific/4x/x86_64/apt/SRPMS.updates/

--

OK ... this is really simple

The kernel source RPM for every kernel is in the SRPMS directory ... as is every source RPM for everything we release.

http://mirror.centos.org/centos/4/os/SRPMS/

Or substitute "updates" for "os" when a kernel update comes out.

Now for people who say the procedure is hidden ... did you look at the release notes :)

http://mirror.centos.org/centos/4/docs/html/release-notes/as-x86/

Search the page for "kernel source"

Now, if you are compiling your own kernel in RHEL, they do not support you any more. This distro is a clone of that. If you want to compile your own kernel, that is your option ... however, it should not normally be done.

RH does not support reiserfs ... they say it is not stable enough. You can agree or disagree, however if you think reiserfs is a must, then CentOS is probably not the distribution you should use. There are many distros out there (SuSE is one) where they use reiserfs as their default.

I would like everyone in the world to use CentOS ... but if you do, you should conform to what the distro is suited for and what it does. If you want SuSE or Gentoo or Debian or Ubuntu ... it is much easier to just use those than to try and make CentOS be those ... that is, of course, just my opinion.

I agree, I was looking for the source to test whether asterisk PBX worked better with an interruptible kernel. I also was intending to test reiserfs because of its low CPU usage, but from what I have read on it, It may work better/faster than other filesystems, but if it breaks, you are pretty much SOL. So, I am not even going there.