Not exactly.
1) I will be modifying the kernel and possibly writing one or more device drivers. I'd like to start with a build that works - that's been one of the best ways I've found to ensure that any added or modified code can be reasonably inferred to cause whatever problems I might find. Why is it a problem for one to want to be able to build a working kernel?
2) The build log was clean - where would I find the error log? Wait - that's kind of secondary. I then moved to the instructions in the README file, which are, yes, drastically different - they don't involve rpm, using the exact same source for the exact same kernel. The only fundamental difference is that make doesn't necessarily generate an rpm package (actually, this one does), and I don't need to use rpm for anything. Later on that may be a problem, but not right now.
3) The modification to xfs is a sample based on what I have been assigned to do - I'm not trying to generate the latest and greatest xfs that's available out there. Maybe I should, in the ideal world, but working in corporate America is pretty far from the ideal world.
4) This is all true, but not particularly relevant. I need a base kernel with NO modifications that I can then start to use to create any customizations, like a new device driver or twiddling with some other code that we need to customize because, perhaps, for compatibility reason, we can't just upgrade to a new version of <some_module>.
As for the lvm "incompatibility," this is the main one I don't understand. If I am building from the same source as the distribution I am running on this box, why would there be an incompatibility here? Here's what the boot panel displays (copied by hand but missing all indents since it hangs at the end and I don't know if there's a better way to capture the display):
Booting (CentOS 2.6.9MHRsmp)' kernel direct mapping nodes[?] up to 10100000000 @ 8000-d000 root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.9MHRsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet [Linux-bzImage, setup=0x1400, size=0x190795] initrd /initrd-2.6.9MHRsmp.img [Linux-initrd @ 0x3706300, 0x18caf6 bytes]
. Decompressing Linux...done Booting the kernel audit (1170068438.664:0): initialized Red Hat nash version 4.2.1.8 starting Reading all physical volumes. This may take a while... No volume groups found Volume group "VolGroup00" not found ERROR: /bin/lvm exited abnormally! (pid 206) mount: error 6 mounting ext3 mount: error 2 mounting none switchresest: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempted to kill init
[system halts]
Thanks.
mhr
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jim Perrin Sent: Friday, January 26, 2007 5:36 PM To: CentOS mailing list Subject: Re: [CentOS] Problems with building a complete kernel
1. There was no need specified for why a custom kernel was needed. If such a need was spelled out, it's possible that much better help could be provided, or it could even be added to the centosplus kernel.
2. No build log or error of any kind was shown to help troubleshoot. And rather than figuring out what went wrong, the user moved to a drastically different set of instructions, which use a drastically different kernel. Doing so without proper understanding could (and likely would) lead to problems down the road. (The install with --nodeps on the howtoforge listing is a nice touch)
3. The user in question seems to have not done homework regarding centos and XFS, and will be modifying the 2.6.9 xfs code instead of using the much nicer xfs code backported by ex-SGI folks specifically for centos.
4. There are many considerations in building a custom kernel for centos, such as the audit libs, utmp compatability, current system compatability (as demonstrated by the lvm troubles) and so on.
On Mon, 2007-01-29 at 18:12 -0500, Mark Hull-Richter wrote:
Not exactly.
- I will be modifying the kernel and possibly writing one or more
device drivers. I'd like to start with a build that works - that's been one of the best ways I've found to ensure that any added or modified code can be reasonably inferred to cause whatever problems I might find. Why is it a problem for one to want to be able to build a working kernel?
- The build log was clean - where would I find the error log? Wait -
that's kind of secondary. I then moved to the instructions in the README file, which are, yes, drastically different - they don't involve rpm, using the exact same source for the exact same kernel. The only fundamental difference is that make doesn't necessarily generate an rpm package (actually, this one does), and I don't need to use rpm for anything. Later on that may be a problem, but not right now.
- The modification to xfs is a sample based on what I have been
assigned to do - I'm not trying to generate the latest and greatest xfs that's available out there. Maybe I should, in the ideal world, but working in corporate America is pretty far from the ideal world.
- This is all true, but not particularly relevant. I need a base
kernel with NO modifications that I can then start to use to create any customizations, like a new device driver or twiddling with some other code that we need to customize because, perhaps, for compatibility reason, we can't just upgrade to a new version of <some_module>.
As for the lvm "incompatibility," this is the main one I don't understand. If I am building from the same source as the distribution I am running on this box, why would there be an incompatibility here? Here's what the boot panel displays (copied by hand but missing all indents since it hangs at the end and I don't know if there's a better way to capture the display):
Booting (CentOS 2.6.9MHRsmp)' kernel direct mapping nodes[?] up to 10100000000 @ 8000-d000 root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.9MHRsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet [Linux-bzImage, setup=0x1400, size=0x190795] initrd /initrd-2.6.9MHRsmp.img [Linux-initrd @ 0x3706300, 0x18caf6 bytes]
. Decompressing Linux...done Booting the kernel audit (1170068438.664:0): initialized Red Hat nash version 4.2.1.8 starting Reading all physical volumes. This may take a while... No volume groups found Volume group "VolGroup00" not found ERROR: /bin/lvm exited abnormally! (pid 206) mount: error 6 mounting ext3 mount: error 2 mounting none switchresest: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempted to kill init
[system halts]
Thanks.
mhr
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jim Perrin Sent: Friday, January 26, 2007 5:36 PM To: CentOS mailing list Subject: Re: [CentOS] Problems with building a complete kernel
- There was no need specified for why a custom kernel was needed. If
such a need was spelled out, it's possible that much better help could be provided, or it could even be added to the centosplus kernel.
- No build log or error of any kind was shown to help troubleshoot.
And rather than figuring out what went wrong, the user moved to a drastically different set of instructions, which use a drastically different kernel. Doing so without proper understanding could (and likely would) lead to problems down the road. (The install with --nodeps on the howtoforge listing is a nice touch)
- The user in question seems to have not done homework regarding
centos and XFS, and will be modifying the 2.6.9 xfs code instead of using the much nicer xfs code backported by ex-SGI folks specifically for centos.
- There are many considerations in building a custom kernel for
centos, such as the audit libs, utmp compatability, current system compatability (as demonstrated by the lvm troubles) and so on.
Are you following the guide and producing an RPM ... or are you trying to build via the make, make modules, etc. route.
If you are building via Jim's tutorial, you should get a good initrd image and should be able to boot the kernel with no problems if the RPM is produced.
If you are building from the manual method ... you should not do that on an RH type distro. If you are absolutely determined to do it the manual way anyway ... then make sure that you copy the configuration file into the kernel directory as .config .. then run the command:
ARCH=i386 make oldconfig
then, run it again
ARCH=i386 make oldconfig
then do the rest of the procedure
Also, when the kernel is done, use mkinitrd to make and initrd.img
------------------------------------
STILL ... highly recommend that you build the kernel RPM.
------------------------------------
Is this a potential cross arch issue ... are you building an i386 kernel on an x86_64 machine or vice versa?
On Tue, 30 Jan 2007 04:37:56 -0600, Johnny Hughes wrote:
If you are building from the manual method ... you should not do that on an RH type distro. If you are absolutely determined to do it the manual way anyway ... then make sure that you copy the configuration file into the kernel directory as .config .. then run the command:
ARCH=i386 make oldconfig
then, run it again
ARCH=i386 make oldconfig
then do the rest of the procedure
Also, when the kernel is done, use mkinitrd to make and initrd.img
STILL ... highly recommend that you build the kernel RPM.
Long before CentOS 5 comes out, I know I would have to build at lease one kernel module before I can use it. That is cifs. cifs in kernel >= 2.6.18 has a bug which causes kernel oops/system crash. The patch finally became available. See:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211672
However, I just leaned that this fix will not make it into RHEL5 because RHEL5 is already "locked down tightly." This means that CentOS 5 will carry this bug.
I have compiled the cifs module for FC5 and FC6 with the patch and am assuming the procedure is the same for CentOS. Is this the case?
Akemi