Janet, Frankly, I'm no expert, and don't really know exactly what the relevance of kernel.h is, except that it's generated at boot time. I seem to have multiple versions, but they are all exactly the same content. Very curious. I'm sure many people on this list know far more than I do on the subject.
I believe and initrd.img isn't required unless you have scsi drives. I know I've left it out when compiling lots of 2.4.xx kernels, and they all work fine, so I guess that's likely true, as I don't have any scsi drives. Keep us posted on your 2.5.xx experience. I've build 2.5.67 through 2.5.72 with varying degrees of success. I just tried 2.5.73 today with the bk6 patch, and it went well, but then it doesn't boot- just a black screen. 2.5's are really not ready for much except testing purposes, at least for me. I've really tried to get them to work for months, and have gotten it down to either they work fine with no serial drives enabled (thus no internet/modem), or serial drivers enabled, and lots of serious file manager problems (freezes and long delays). For me, it's been a show stopper so far, and seemingly unsolvable. Robert C. On Tuesday 01 July 2003 21:10, kiosk wrote: > Thank you so much, Robert, for an elegant description of a process which > has been to some extent mysterious for me for some time, despite my > experience in compiling kernels for various Slackware installations. I > intend to experiment with a 2.5.xx kernel in the hope that my E7205 > chipset will be supported so that I can load the AGPGART module for my > NVIDIA card. > > However, I wonder if you would be so kind as to explain the presence of > the kernel.h file in /boot, and it's relevance to the boot process. I > don't think I need, and, ideally, would dispense with kernel.h and > initrd.img. > > I'm not sure that I need to patch a kernel at all, but if I can patch a > stable kernel, and, as a result, load AGPGART, then perhaps that would be > the way to go? > > > Janet Blankfield > > > "The ideal love affair is one conducted by post." JBS > > > ----------------------------- > [EMAIL PROTECTED] > ... life's a beach ... > ----------------------------- > > > > On Sat, 28 Jun 2003 12:39:17 -0400 > > Robert Crawford <[EMAIL PROTECTED]> wrote: > > Waiting sounds wise- no use in messing up your current setup. > > > > However, if you really wanted to see if it will apply, what you could > > try is copying your stock MDK kernel sources directory from /usr/src to > > it's own directory in /home. (Compiling there is much safer than doing > > it as root in /usr/src, especially for people like me still > > learning).Then make a backup of your .config file, and cd in a console > > (as user) to the new directory in /home where you copied the MDK kernel > > sources to, and run mrproper. Then, try applying the Hz patch. If it > > applies OK, do a make xconfig and load the copy of your stock .config > > file into xconfig., Then change the value of the Hz line to =1000Hz, and > > save and exit. > > > > VERY IMPORTANT:Check the makefile extra version line at the top of the > > file > > to see if it added the -ck2 extra version when the patch applied, > > otherwise if you do choose to install this kernel and the name (version) > > is the same, it will overwrite your original modules directory, and not > > create a new -ck2 version. In your case, that would be a disaster. > > > > Then you can (as user) do: > > > > make dep > > make clean > > make bzImage > > make modules > > > > If you get through these with no error outs, you are probably OK, and > > will then know the patch probably didn't cause any problem. Up to this > > point, nothing you have done could possibly affect your current kernel > > setup. > > > > If you want to actually install, su to root and do: > > > > make modules_install > > > > This will put a new modules directory in /lib/modules with the new -ck2 > > version name, leaving the original untouched. > > > > I never do the usual final "make install" to call the kernel script > > after that if I'm not compiling in /usr/src. I did that once, and had > > huge problems. I manually copy System.map and bzImage to /boot, naming > > them to reflect the extra version, like System.map-2.4.21-ck2, and > > bzImage-2.4.21-ck2. I then edit lilo, and since I don't use an initrd > > file for the new kernel, I delete the initrd line in the new kernel's > > lilo stanza, so it looks like: > > > > image=/boot/bzImage-2.4.21-ck3 > > label=2421ck3 > > root=/dev/hda10 > > append="devfs=mount hdc=ide-scsi acpi=off quiet" > > vga=788 > > read-only > > > > Then save, and run lilo as root. > > > > Of course there's no way to know if doing all this will actually > > increase system response in a noticable way, even if the patch applies > > on the MDK kernel, without actually doing it. I can report that all the > > ck patches I've applied seem to work great on the vanilla 2.4.21. > > > > BTW, when I installed the MDK multimedia kernel and kernel sources rpms, > > it worked perfectly. I just put them in their own directory, and did as > > root: > > > > rpm -ivh *.rpm > > > > That installed everything, and edited lilo too. But like you said, you > > might need extra drivers that I didn't have to contend with. You might > > have to install the srpm, and patch the source, then rebuild new > > multimedia rpms. I think they posted a newer multimedia (-18mdk, up from > > the -16mdk I used) that might have updated drivers. > > Maybe we can figure out what happen when you tried it. What's the exact > > procedure you used? > > > > Robert Crawford
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
