Hi Rob. Yes, but if you want to get the feel of it, just dl the kernel-source package of your distro, (the source for the kernel you are using now) and copy it over , say into your home direcory... and play-config ... also this package would have a .config file sitting there for you, just let the xmenu pick that one, and learn of the settings that your current kernel has. Dont bother installing the kernel image in case you compile one, just get the idea. this would be a very good start. If you get one going of your first 10, you will be a guru soon :-) Cheers Szemir
"The journey of a thousand miles starts with a single step." Lao Tzu On July 16, 2004 16:56, Rob S wrote: > Thank you very much for this message. I was just doing make menuconfig, > and choosing options based more on gut feelings than any sort of actual > knowledge, then directly on to make bimage and then pointing lilo to it. > no wonder that first attempt did not work! :) > > -Rob > > bogi wrote: > >Hi Rob. > >I do remember your question. So, if you feel your question was not > > answered properly, is because the answer (proper) would have taken a good > > 30 minutes, since compiling the kernel is not just issuing 2-4 commands > > and be done with it, you also need to know howto configure the kernel > > with about 70 odd parameters, fortunately we have menuconfig to help, but > > you would at least need to know what does what amongst those 70 odd > > parameters. the answer you got would have helped you read those > > parameters and their meaning. usually to save the effort of the end user, > > the distro kernels come with a default settings file called .config, you > > can call it anything, but this is the default name. this file contains > > all the settings necessary to reproduce the original distro kernel of > > your distribution. Now if you need something else, and your kernel does > > not provide the possibility to load a module , yes it is possible to > > create a kernel with no module loading ability, then you would need to > > compile the kernel again, with the proper modul-loading abilities, or by > > statically compiling what you want into the kernel. This is good if your > > hardware is not going to change, you know the future and you allways > > compile your kernel, for todays distros all come with the module-loading > > ability enabled. There is a usual set of modules, that are compiled-in > > and not set as modules to be loaded later, namely the hdd handlers for > > ide and scsi, if you dont have those in, you may have trouble booting, > > for the kernel would not be able to access the say scsi disk to read the > > scsi module ....., some optional modules may need to be compiled-in like > > the ide-raid and the scsi-raid modules to enable you to boot from such a > > raid device some other options include handling more then 4gigs of ram > > and larger filesystems, or faster (PREEMPTIVE) task managers, would stay > > out until they are deemed production ready, but if you like to > > experiment, well... (preemptive is now in 2.6 by default, just you know). > >so go to www.kernel.org and download the newest stable kernel, and put the > >tarball in /usr/src and unpack it. > >create a symbolic link to point to the folder where you unpacked the > > kernel, that symbolic link should be called linux. > >now cd linux > >now read the README file :-) > >read it again ... > >so your first command would be > >make mrproper > >to clean up any residue from previous compiles, this is generally a good > > idea. now to configure a kernel: > >you would have 3 options: > > > >make menuconfig > >make xconfig > >make oldconfig > > > >The menu version is a character-graphics based GUI to configure the > > compile options, the xconfig is a full-blown GUI to do the same. remember > > your factory configuration is in .config if you load that into these > >configurators, you will see exactly how they did it. > >also you can use oldconfig, this is your old .config file, so don't > >over-write that one. actually you could get a newer kernel and use the old > >.config file and make oldconfig with that. > >to learn more about the configuration options, you should look into the > >Documentation directory, there is a massive 1.2M file called > > Configure.help use it as a manual, it has a few lines of explanation for > > each and every possible option, also mentions which once would conflict. > > I read this one from time to time. > >In general avoid those options marked as "development", "experimental", or > >"debugging". they are likely to bring you back to the list with more > >questions :-) > >After selecting and saving: > >make dep > >this will check all the dependencies, adds some other options that are > > needed for what you selected, but this is an automatic process. > > > >then, yes: > >Compile the kernel :-) > >make bzImage > >this is the recommendation. but if you want to just make a kernel on > > floppy, to boot with, then: > >make bzdisk > > > >This should result in a compressed kernel image (this is how we call the > >compiled kernel in this form.) and this is what you get in a binary > >.rpm/.deb/ whatever package to install along with the compiled modules for > >the kernel, which we still have to compile: > >make modules > >then > >make modules_install > >after the successful compile, you want to copy the kernel image from > >arch/i386/boot/bzImage (this is where it would be created for you) into > > your /boot partition, or your /boot directory, and tell lilo to > > pick-it-up, and this part is in the documentation here, and in the lilo > > part. And i will learn about grub soon. If you make a floppy, then just > > copy that onto /dev/fd0 and you should be ok. It is not a bad idea, to > > put your experimental kernel on a floppy, if it still fits :-) > >and yes > >reboot with the new kernel, this is propably the only part where you > >have-to-reboot . > >I hope this has shed some light on why you did not get a proper answer on > > the 15 minute q&a section, i will put it up as a long presentation as > > soon as possible, this would be a more suitable venue for a question of > > that magnitude. > >I hope i was helpful > >Cheers > >Szemir > > > >On July 14, 2004 21:21, Rob S wrote: > >>I was thinking that a sig could be an hour of people just asking > >>questions, as the question part of the meetings is usually quite tiny. > >>When i asked about building a kernel, i got a deluge of responses, which > >>was helpful and not helpful at the same time. I feel that there was also > >>an impetus on ending the meeting as well. I think, that there is a > >>tendency for "I.T. types" (to use a generalisation) to be answer > >>machines. We give short and efficient answers to questions, which may > >>not be what everyone wants. I think a more relaxed and open atmosphere > >>could help the flow of questions. > >> > >>on the other hand, it may just be that moving the question and answer > >>period to the first item on the meeting, or right after the > >>presentations is what could facilitate this. > >> > >>Of course, i may be right off in left field, so i would like some > >> feedback. > >> > >>-Rob > >> > >>Shawn Grover wrote: > >>>How big of an installfest? Well, I think the answer is somewhat > >>>subjective. If we have two or three "experienced" people there, then we > >>>can probably aim for about 6 to 10 "non-experienced" people at any point > >>>in time. People come and go, so the total number of people attending, > >>> and the total currently in attendance aren't necessarily the same. If > >>> no "experienced" people were there, then you'd have a room full of > >>> people struggling and not getting the help they need (though I'd > >>> imagine they'd have the moral support of the others). This is a great > >>> way to learn, but that isn't the purpose of the installfest. So, how > >>> big depends somewhat on how many experienced Linux users can make it. > >>> In the past I think the target has been 20 computers at any given time. > >>> > >>>For the ISO's, there are normally a number of different distributions to > >>>be found at the installfest, and copies of the CDs can be made on the > >>> fly (gotta luv the open source licenses). > >>> > >>>With regards for a SIG, starting one more or less is up to you. If you > >>>feel there is a need, and would like to take on the role of organizing > >>>and maintaining it, then you just do it. (er, at least that's how it > >>>happened for the Programming SIG.) My personal recommendations though, > >>>are as follows: > >>> > >>>1) Make a judgement if the SIG has enough interest. > >>>2) Determine what the SIG would do. i.e. regular or infrequent > >>> meetings? presentations or open discussions? What topics will be > >>> discussed, or is training the focus? where will the meetings take > >>> place? etc. Get an idea of what the SIG is about, but be ready to make > >>> changes as SIG members offer suggestions. 3) Discuss the SIG with the > >>> executive. Most likely, they will be happy to help out, but may also > >>> have inside knowledge that might suggest the SIG isn't a good idea at > >>> this time. (I hear Jarrod is a little more receptive after a beer or > >>> two.. <grins> j/k.) Also, find out from the executive what would be > >>> needed for their part (attendance tracking, tracking winners of door > >>> prizes, etc.). 4) If you have done the previous and have determined to > >>> proceed with the SIG, decide what needs to be done to make it happen > >>> (meeting place/time, announce to the list, create a mailing list, etc.) > >>> and then make it happen. 5) In the first meeting or two (or prior to > >>> them, if possible), have the SIG members ratify the purpose of the > >>> group, or at least state their expectations of the group. This > >>> information has to then be used to keep the group focused on topics > >>> relevant to the group's desires. 6) Commit yourself. If you are running > >>> the SIG, make sure that it isn't something you'll loose interest in > >>> after a couple of meetings - you're responsible to make sure the > >>> meetings happen and organize any presentations that may be needed. > >>> > >>>That said, my own thoughts on a newbie SIG is that it's not really > >>> needed at this time. The main CLUG meetings are really where the > >>> newbies can get information they need. That's the purpose of the > >>> presentations, and the question/answer period, as well as the casual > >>> social event that happens at the tail end of every meeting. Creating a > >>> SIG tailored for Newbies would be tough, because you would be covering > >>> the same topics over and over, and loosing members once they've become > >>> proficient enough to not be considered a newbie anymore. Not to > >>> mention that everyone has their own specific needs/goals with Linux - > >>> are you building a linux server or desktop computer? Do you use KDE or > >>> Gnome? Do you use the command line to install new applications, or the > >>> distro specific tools? Do you tailor the meetings to one distribution > >>> or all, and how do reconcile the differences? But, these are from my > >>> own perspective - perhaps there is a method of doing things that I > >>> don't see yet, that would work out well. Again, this becomes a > >>> judgement call on your part if you are looking to start a SIG. > >>> > >>> > >>>My thoughts. (sorry for the long post) > >>> > >>>Shawn > >>> > >>>-----Original Message----- > >> > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> > >>>Behalf Of Rob S > >>>Sent: Wednesday, July 14, 2004 1:56 AM > >>>To: CLUG General > >>>Subject: Re: [clug-talk] Installfest > >>> > >>> > >>>I have some questions: > >>> > >>>How big do we want the install-fest to be? > >>> > >>>What iso's do i need to install suse? is the personal edition a demo > >>>version? > >>> > >>>How does one start a sig? I was thinking of starting a sig designed for > >>>newbies, if there is interest and a few fluent linux users are willing > >>>to volunteer time for questions. > >>> > >>>-Rob. > >>> > >>>_______________________________________________ > >>>clug-talk mailing list > >>>[EMAIL PROTECTED] > >>>http://clug.ca/mailman/listinfo/clug-talk_clug.ca > >> > >>_______________________________________________ > >>clug-talk mailing list > >>[EMAIL PROTECTED] > >>http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > > >_______________________________________________ > >clug-talk mailing list > >[EMAIL PROTECTED] > >http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > _______________________________________________ > clug-talk mailing list > [EMAIL PROTECTED] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca _______________________________________________ clug-talk mailing list [EMAIL PROTECTED] http://clug.ca/mailman/listinfo/clug-talk_clug.ca
