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@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
Behalf Of Jim Perrin
Sent: Friday, January 26, 2007 5:36 PM
To: CentOS mailing list
Subject: Re: 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
