I am building a new 2.6 kernel and have decided that it is time to look for a different method. What I always did in the past is to download the new kernel I wanted, unpack it in /usr/src/linux and then do the following: make mrproper #That cleans everything up and lets you start from scratch. make config #That starts the question and answer script which prompts you all the way through the process. There are more and more questions as the kernel grows up. I counted 493 on my most recent attempt and I still realized that I forgot something by the time I got to the end. I access Linux via an old P.C. running DOS, a screen reader and kermit software. In the past, I captured the session and then ran those data through a filter I wrote in C to convert that session in to a kermit script that one can feed back in to the build process. The advantage is that if you want to keep everything up to the 420TH question, you just let the script run and make sure it runs out of anything to do at that point. You then start a new log and manually answer the different questions until you see it merge back in to the same set of questions it was answering before. At that point, you can merge your new script with your old one and go on. There is an option to use the old configuration as in make -oldconfig. It certainly remembers your last session, but it just lets you make another kernel like the last one which may not be what you wanted. Is there a way besides kermit or expect scripts to safely edit the configuration and still preserve all those tedious lines of question and answer that don't change from one build to the next such as all those code pages for various international file name support, etc? I expect to have to answer all the questions the first time through because those change drastically from one kernel to the next, but it certainly would be nice to have a way to only answer those lines of questions caused by changing some particular part of the kernel rather than the whole works every time. A really neat thing would be if you could feed the output of dmesg in to the process to answer all the hardware support questions. I have a Linux system at work and one at home and, after a year or two, it gets hard to remember whether this or that system is the one with the PIX3 hard drive controller, etc. For those who haven't ever configured a Linux kernel, it is more tedious than difficult. The one thing you do need to have handy is a list of all your hardware and network cards, preferably the output of dmesg if you have booted a generic kernel. You don't want to compile anything you don't support since at best, it will make your kernel bigger than it needs to be and at worst, it may make it fail because it is looking for something that isn't there. Another reason I like to automate much of the kernel rebuild process is that it gives you something to look at later if you are not sure how you originally answered some of the more obscure questions. Believe me, some of them get pretty strange and one isn't sure whether or not they apply or not. A scripted rebuild lets you quickly answer the question, "What would happen if I tried this or that?" You will know that you kept everything else the way it was and only changed the part you wanted to change. Any suggestions are appreciated and I will certainly share any thing I find out about that makes this process a little more efficient. Martin McCormick WB5AGZ Stillwater, OK OSU Information Technology Division Network Operations Group _______________________________________________ Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list