On Mon, 2007-01-29 at 18:12 -0500, Mark Hull-Richter wrote: > 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. > 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20070130/e0e3c663/attachment-0005.sig>