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 at centos.org [mailto:centos-bounces at 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.