Kernel 2.6 On Fedora-based Systems
Since this has come up regularly, I've decided to finally blog it.
Up through all Red Hat Linux releases and Fedora Core 1, which subsequently means through Red Hat Enterprise Linux 3, Red Hat included a package entitled kernel-source-ver.i386.rpm. The purpose of this "binary" RPM was to create a /usr/src/linux-ver directory (and associated /usr/src/linux[-2.x] symbolic link). This was the standard kernel location for not only building custom kernels, but where any 3rd party kernel modules (with their own Makefile) could expect to find kernel headers, build-time configuration information, etc...
There were many issues with this approach.
First off, until kernel 2.6, if you wanted to build any 3rd party kernel module -- even one that included it's own Makefile and built systems -- you had to "prep" a kernel source tree that was exactly as your running kernel. This meant applying the correct configuration, the exact Makefile tags, etc... that were often daunting for newer users -- let alone even experienced users. It was more than just the common "build from source" routine of ./configure and make install. And the order was often important as well.
Secondly, the system headers, including C library and other kernel headers, were commonly used by applications as well as kernel building -- especially when different C compilers were being used for the system. Without going into a lot of specifics, it was not long before kernel headers and system headers became separate entities. A major reason being is that some headers and other build-time configuration information might need to be re-created in the kernel build process. In fact, early in Red Hat Linux 7, changes to kernel 2.2's mrproper ("Mr. Proper" is a non-US marketing name for "Mr. Clean") Makefile target resulted in the blowing away many of the system headers.
RPM is a build system and designed as such for a reason. Red Hat Linux and Fedora-based distros (collectively referred to Fedora-based) as well as even other package systems and distros, such as Debian and Debian-based, have used a dedicated, "protected" build environment for kernels for a long time. Starting in Red Hat Linux 6 (well over 6 years ago), Red Hat kernels, modules and other components that have required the kernel source tree have been built from the kernel-ver.src.rpm, and not via a source tree located in /usr/src/linux-ver.
This addresses many issues, including:
1. Include all components to complete a build
2. Ensure exact steps to complete a build
3. Avoid negative affects to files in the production system (chroot)
4. Force documented changes with source, SPEC, etc...
As of Red Hat Linux 7, I personally and professionally stopped building kernels from kernel-source (now kernel-sourcecode as we'll talk about in a bit). The exact order and requirements in not only building but even "prepping" the kernel source tree for 3rd party kernel modules is extremely important. But beyond that, the "mrproper" target can do some particularly nasty things to your systems' /usr/include and other directories. In the kernel.src.rpm build under the chroot, the system's /usr/include and other directories are not touched, and they have their own, self-contained support.
Starting with Fedora Core 2 based on the new kernel 2.6, Red Hat decided to deprecate the "binary" kernel-source-ver.i386.rpm.
At first, they included a new architecture-independent "binary" package name called kernel-sourcecode-ver.noarch.rpm to avoid confusion with the old approach. Mid Fedora Core 2, they considered it redundant to continue doing so and, subsequently, it is not included with Red Hat Enterprise Linux 4 onward either. There is still a "binary" RPM target defined as kernel-sourcecode in the kernel-ver.src.rpm (Source RPM), but Red Hat no loner builds it by default. Redundancy, safety, etc... are major reasons.
To build a "prep'd" kernel 2.6 source tree in FC2+/RHEL4+, you should follow these steps:
1. Download the kernel-ver.src.rpm source RPM (SRPM, .src.rpm) package for your kernel version. If you don't know your kernel version, run `uname -r`. Alternatively, and preferrably, You should use the automated methods of YUM, UP2DATE, etc... to get the correct Source RPM (.src.rpm) of the currently running version of the kernel without any manual checking.
2. Install this package, e.g., rpm -ihv kernel-`uname -r`.src.rpm
3. Prep the kernel source for your architecture, e.g., rpmbuild -bp --target=i686 /usr/src/redhat/kernel-2.6.spec
That will safely prep the kernel in the RPM chroot environment into a mode that is "ready to use" under /usr/src/redhat/BUILD/kernel-2.6*/linux-2.6*/, although you should consult the kernel-2.6.spec file to see what Makefile targets have and have not been run. You may wish to create a symbolic linke to /usr/src/linux-`uname -r` but be careful when executing any Makefile targets in the unprotected, root filesystem of the system.
Even though Red Hat does not build and distribute the kernel-sourcecode-ver.noarch.rpm, any distribution that rebuilds from Fedora Development, Core, Legacy or Red Hat Enterprise Linux kernel-ver.src.rpm may or may not choose to do the same. Some 3rd party rebuilds have decided to include it. Others agree with Red Hat, that it should be deprecated and the chroot RPM system build process be used.
As I eluded to earlier, you can still create a kernel-sourcecode-ver.noarch.rpm package that creates the /usr/src/linux-ver directory for any FC2+/RHEL4+ kernel 2.6 release. The procedure is as follows:
1. and 2., as the previous section.
3. Modify the SPEC file, e.g.,
# vi /usr/src/redhat/SPECS/kernel-2.6.spec
as follows ...
%ifarch noarch
%define builddoc 0
%define buildsource 1
%define buildup 0
...
4. Build the noarch target, which builds kernel-sourcecode
5. Install the "binary" kernel-sourcecode RPM
Now you have your /usr/src/linux-2.6 directory. I highly recommend against building your kernels in the "unprotected" and "root anchored" environment from an arbitrary set of commands (instead of the chroot of RPM with a pre-tested sequence of commands), but that is your choice.
Yes, before kernel 2.6, the location of /usr/src/linux-ver was expected so you could build 3rd party kernel modules. But it was typically safe to to do so, since you're not running the kernel's Makefile. You still typically wanted to "prep" the kernel tree itself in the RPM chroot environment, even if you were only going to symlink it to /usr/src/linux-`uname -r` after doing so. Kernel 2.6 addresses this, which brings me to my next point.
In the kernel modules directory (e.g., /lib/modules/`uname -r`/), there is a subdirectory called build. It points to the headers and other configuration, dependencies, etc... of the running kernel so 3rd party drivers can be built. Before kernel 2.6, this was a symlink to /usr/src/linux-`uname -r`. As of kernel 2.6, this is now static in the kernel itself (taking up a few MBs). The idea here is that you should be able to build 3rd party kernel modules against the current kernel without having to prep a full kernel tree.
Since most newer, 3rd party module Makefiles were already looking to /lib/modules/`uname -r`/build/ to locate the kernel headers, build-time configuration information, etc... As such, the change in kernel 2.6 should be transparent for most newer 3rd party kernel modules with their own Makefile, with exception of the fact that you no longer have to . At the same time, and in the worst case for kernel 2.6, it's often merely just a matter of:
ln -s /lib/modules/`uname -r`/build /usr/src/linux-`uname -r`
You almost never need to "prep" a kernel source tree to build 3rd party kernel modules against it.
Now as of Fedora Core 4 (and accidentally one Fedora Core 3 kernel release), as well as Red Hat Enterprise Linux 4, Red Hat decided to separate kernel 2.6's /lib/modules/`uname -r`/build/ subdirectory from the rest of the kernel modules in /lib/modules/`uname -r`. This new package is known as kernel-devel-ver.*.rpm (where * is the binary architecture, i386, i586, i686, athlon, x86_64, etc...).
So as of Fedora Core 4+ and Red Hat Enterprise Linux 4+, if you want to build 3rd party kernel modules, you need to to install the kernel-devel-ver.*.rpm package so the /lib/modules/`uname -r`/build/ subdirectory is present. A simple yum install kernel-devel or up2date kernel-devel takes care of that for an Internet connected system. By not installing it, you save several MBs of disk space (which may be useful in embedded/read-only systems, etc...), which I'm sure was Red Hat's rationale (since just the binary kernel modules can total less than 10MB in some cases).
- The "good 'ole days" of the kernel-source-ver.i386.rpm package
Up through all Red Hat Linux releases and Fedora Core 1, which subsequently means through Red Hat Enterprise Linux 3, Red Hat included a package entitled kernel-source-ver.i386.rpm. The purpose of this "binary" RPM was to create a /usr/src/linux-ver directory (and associated /usr/src/linux[-2.x] symbolic link). This was the standard kernel location for not only building custom kernels, but where any 3rd party kernel modules (with their own Makefile) could expect to find kernel headers, build-time configuration information, etc...
There were many issues with this approach.
First off, until kernel 2.6, if you wanted to build any 3rd party kernel module -- even one that included it's own Makefile and built systems -- you had to "prep" a kernel source tree that was exactly as your running kernel. This meant applying the correct configuration, the exact Makefile tags, etc... that were often daunting for newer users -- let alone even experienced users. It was more than just the common "build from source" routine of ./configure and make install. And the order was often important as well.
Secondly, the system headers, including C library and other kernel headers, were commonly used by applications as well as kernel building -- especially when different C compilers were being used for the system. Without going into a lot of specifics, it was not long before kernel headers and system headers became separate entities. A major reason being is that some headers and other build-time configuration information might need to be re-created in the kernel build process. In fact, early in Red Hat Linux 7, changes to kernel 2.2's mrproper ("Mr. Proper" is a non-US marketing name for "Mr. Clean") Makefile target resulted in the blowing away many of the system headers.
- Red Hat does not built kernels from kernel-source-ver.i386.rpm
RPM is a build system and designed as such for a reason. Red Hat Linux and Fedora-based distros (collectively referred to Fedora-based) as well as even other package systems and distros, such as Debian and Debian-based, have used a dedicated, "protected" build environment for kernels for a long time. Starting in Red Hat Linux 6 (well over 6 years ago), Red Hat kernels, modules and other components that have required the kernel source tree have been built from the kernel-ver.src.rpm, and not via a source tree located in /usr/src/linux-ver.
This addresses many issues, including:
1. Include all components to complete a build
2. Ensure exact steps to complete a build
3. Avoid negative affects to files in the production system (chroot)
4. Force documented changes with source, SPEC, etc...
As of Red Hat Linux 7, I personally and professionally stopped building kernels from kernel-source (now kernel-sourcecode as we'll talk about in a bit). The exact order and requirements in not only building but even "prepping" the kernel source tree for 3rd party kernel modules is extremely important. But beyond that, the "mrproper" target can do some particularly nasty things to your systems' /usr/include and other directories. In the kernel.src.rpm build under the chroot, the system's /usr/include and other directories are not touched, and they have their own, self-contained support.
- From kernel-source-ver.i386.rpm to kernel-sourcecode-ver.noarch.rpm to no more "binary" kernel source
Starting with Fedora Core 2 based on the new kernel 2.6, Red Hat decided to deprecate the "binary" kernel-source-ver.i386.rpm.
At first, they included a new architecture-independent "binary" package name called kernel-sourcecode-ver.noarch.rpm to avoid confusion with the old approach. Mid Fedora Core 2, they considered it redundant to continue doing so and, subsequently, it is not included with Red Hat Enterprise Linux 4 onward either. There is still a "binary" RPM target defined as kernel-sourcecode in the kernel-ver.src.rpm (Source RPM), but Red Hat no loner builds it by default. Redundancy, safety, etc... are major reasons.
To build a "prep'd" kernel 2.6 source tree in FC2+/RHEL4+, you should follow these steps:
1. Download the kernel-ver.src.rpm source RPM (SRPM, .src.rpm) package for your kernel version. If you don't know your kernel version, run `uname -r`. Alternatively, and preferrably, You should use the automated methods of YUM, UP2DATE, etc... to get the correct Source RPM (.src.rpm) of the currently running version of the kernel without any manual checking.
2. Install this package, e.g., rpm -ihv kernel-`uname -r`.src.rpm
3. Prep the kernel source for your architecture, e.g., rpmbuild -bp --target=i686 /usr/src/redhat/kernel-2.6.spec
That will safely prep the kernel in the RPM chroot environment into a mode that is "ready to use" under /usr/src/redhat/BUILD/kernel-2.6*/linux-2.6*/, although you should consult the kernel-2.6.spec file to see what Makefile targets have and have not been run. You may wish to create a symbolic linke to /usr/src/linux-`uname -r` but be careful when executing any Makefile targets in the unprotected, root filesystem of the system.
- Non-Red Hat/Fedora Distribution Source Code Rebuilds
Even though Red Hat does not build and distribute the kernel-sourcecode-ver.noarch.rpm, any distribution that rebuilds from Fedora Development, Core, Legacy or Red Hat Enterprise Linux kernel-ver.src.rpm may or may not choose to do the same. Some 3rd party rebuilds have decided to include it. Others agree with Red Hat, that it should be deprecated and the chroot RPM system build process be used.
As I eluded to earlier, you can still create a kernel-sourcecode-ver.noarch.rpm package that creates the /usr/src/linux-ver directory for any FC2+/RHEL4+ kernel 2.6 release. The procedure is as follows:
1. and 2., as the previous section.
3. Modify the SPEC file, e.g.,
# vi /usr/src/redhat/SPECS/kernel-2.6.spec
as follows ...
%ifarch noarch
%define builddoc 0
%define buildsource 1
%define buildup 0
...
4. Build the noarch target, which builds kernel-sourcecode
# rpmbuild -bb --target=noarch /usr/src/redhat/SPECS/kernel-2.6.spec
5. Install the "binary" kernel-sourcecode RPM
# rpm -ihv /usr/src/redhat/RPMS/noarch/kernel-sourcecode-`uname -r`.noarch.rpm
Now you have your /usr/src/linux-2.6 directory. I highly recommend against building your kernels in the "unprotected" and "root anchored" environment from an arbitrary set of commands (instead of the chroot of RPM with a pre-tested sequence of commands), but that is your choice.
Yes, before kernel 2.6, the location of /usr/src/linux-ver was expected so you could build 3rd party kernel modules. But it was typically safe to to do so, since you're not running the kernel's Makefile. You still typically wanted to "prep" the kernel tree itself in the RPM chroot environment, even if you were only going to symlink it to /usr/src/linux-`uname -r` after doing so. Kernel 2.6 addresses this, which brings me to my next point.
- Kernel 2.6 build subdirectory and the kernel-devel-ver.*.rpm package
In the kernel modules directory (e.g., /lib/modules/`uname -r`/), there is a subdirectory called build. It points to the headers and other configuration, dependencies, etc... of the running kernel so 3rd party drivers can be built. Before kernel 2.6, this was a symlink to /usr/src/linux-`uname -r`. As of kernel 2.6, this is now static in the kernel itself (taking up a few MBs). The idea here is that you should be able to build 3rd party kernel modules against the current kernel without having to prep a full kernel tree.
Since most newer, 3rd party module Makefiles were already looking to /lib/modules/`uname -r`/build/ to locate the kernel headers, build-time configuration information, etc... As such, the change in kernel 2.6 should be transparent for most newer 3rd party kernel modules with their own Makefile, with exception of the fact that you no longer have to . At the same time, and in the worst case for kernel 2.6, it's often merely just a matter of:
ln -s /lib/modules/`uname -r`/build /usr/src/linux-`uname -r`
You almost never need to "prep" a kernel source tree to build 3rd party kernel modules against it.
Now as of Fedora Core 4 (and accidentally one Fedora Core 3 kernel release), as well as Red Hat Enterprise Linux 4, Red Hat decided to separate kernel 2.6's /lib/modules/`uname -r`/build/ subdirectory from the rest of the kernel modules in /lib/modules/`uname -r`. This new package is known as kernel-devel-ver.*.rpm (where * is the binary architecture, i386, i586, i686, athlon, x86_64, etc...).
So as of Fedora Core 4+ and Red Hat Enterprise Linux 4+, if you want to build 3rd party kernel modules, you need to to install the kernel-devel-ver.*.rpm package so the /lib/modules/`uname -r`/build/ subdirectory is present. A simple yum install kernel-devel or up2date kernel-devel takes care of that for an Internet connected system. By not installing it, you save several MBs of disk space (which may be useful in embedded/read-only systems, etc...), which I'm sure was Red Hat's rationale (since just the binary kernel modules can total less than 10MB in some cases).
15 comments:
If you could put a "kernel Compilation for RHEL4/CentOS4.2 for Dummies" i would love that.
welcome to the wow power leveling cheap service site, buy wow power leveling cheap wow gold,wow gold,world of warcraft wow power leveling buy wow gold
Gold key link for( wow power leveling )the law by( wow power leveling )all, such as bubble( power leveling )shadow dream hallucinations, such( wow gold )as exposed as well( wow powerleveling )as electricity, should be the case
dYou know ,I have some flyff penya,and my friend also has some
flyff money,do you kouw they have the same meaning,Both of them can be called flyff gold，I just want to
buy flyff penya,because there are many
cheap penyaYou know ,I have some maple mesos,and my friend also has some mesos,do you kouw they have the same meaning,Both of them can be called maplestory mesos，I just want to
buy flyff penya ,because there are many
cheap mesos
I can get Solstice Kron cheaply.
Yesterday i bought Solstice Online Kronfor my brother.
i hope him like it. i will give Solstice Gold to him
as birthday present. i like the Solstice Online money very much.
I usually buy cheap Solstice Kron and keep it in my store.
I can getmaple mesoscheaply,
Yesterday i boughtmesos for my brother.
i hope him like it. i will give maplestory mesos to him
as birthday present. i like the cheap mesos very much.
I usually buymaple story mesos and keep it in my store.
As a new player , you may need some game guides or information to enhance yourself.
World of Kung fu Gold is one of the hardest theme for every class at the beginning . You must have a good way to manage your WoKf gold.If yor are a lucky guy ,you can earn so many buy World of Kung fu Gold by yourself . But if you are a not , I just find a nice way to cheap World of Kung fu Gold. If you need , you can buy World of Kung fu money at our website . Go to the related page and check the detailed information . Once you have any question , you can connect our customer service at any time .
Making Sho Online Mun is the old question : Honestly there is no fast way to make lots of Sho Mun . Sadly enough a lot of the people that all of a sudden come to with millions of Sho Online gold almost overnight probably duped . Although there are a lot of ways to make lots of Sho gold here I will tell you all of the ways that I know and what I do to buy Sho Online gold.
For the wakfu kamas, I believe everyone is familiar with the game. For the wakfu gold, I want to say a few points. You must be able to attract firepower with buy wakfu kamas. Originally playing specter in the wakfu money is a stimulating live. Important point is that wakfu kama which CT can hear breathing PS.
The 12sky2 Gold should be a timely evolution of the world. Please step up efforts to investigate all types of twelve sky2 Gold can be set up in the game. twelvesky2 Gold to add more rudimentary fashion and to do some changes to the players. The buy 12sky2 Gold can help you combat equipment of the production. Use the cheap twelve sky2 Gold may change the door to door battle for offensive and defensive resident.
My friends all told me that the best way to spend rohan online gold is a good way. But I could not like spending my own rohan online crone. rohan crone has many ways for us to use. When you start the Rohan Online game, your character will be level 1. I remembered that when I started playing this Rohan game with some little cheap rohan money. If you do not like upgrading level step by step, you can cost rohan gold to help your character to reach level high.
Frogster continues to throw the Runes of Magic Gold all the game-play they can possibly find into Runes of Magic. Rom Gold which I have spent much more in this game it is necessary. Once the race card is full the race begins, with players avoiding to buy Rom Gold and magical traps. It just amazes me how cheap Runes of Magic Gold and stuff Frogster is tossing into Runes of Magic. Players can help themselves and hinder their foes by picking up Runes of Magic money.
Do you know the Archlord gold, in the game you need the
Archlord money. it can help you increase your level. My friends always asked me how to
buy Archlord gold, and I do not know he spend how much money to buy the
archlord online Gold, when I see him in order to play the game and search which the place can buy the
cheap Archlord gold. I am happy with him.
Do you know the cabal alz , in the game you need the
cabal gold. it can help you increase your level. My friends always asked me how to
buy cabal alz, and I do not know he spend how much money to buy the
cabal money, when I see him in order to play the game and search which the place can buy the
cabal online alz. I am happy with him.
Do you know the cabal alz, in the game you need the
cabal gold. it can help you increase your level. My friends always asked me how to
buy cabal alz, and I do not know he spend how much money to buy the
cabal money, when I see him in order to play the game and search which the place can buy the
cabal online alz. I am happy with him.
Do you know the tcos Gold, in the game you need the chronicles of spellborn gold. it can help you increase your level. My friends always asked me how to buy
the chronicles of spellborn Gold, and I do not know he spend how much money to buy
tcos money, when I see him in order to play the game and search which the place can buy the
chronicles of spellborn money. I am happy with him.
Americans everywhere humor A detention wow gold notice was written like this: a wow power leveling police car with stones, to win wow gold the detention center for seven wow power leveling days all-inclusive accommodation replica rolex Tour Value; hit send 2 a beautiful bracelet, wow power level fashionsuit, police transport; more more surprises , the former can enjoy free shaved 10; before the 100 can play with power leveling the dogs, the guests were presented massage sticks, electric shocks to CHEAPEST power leveling the dead skin beauty care services.
Post a Comment