[lug] dumpdates

[John Starkey]

Wayde thanks for this info. 

You were right. I was looking at the Kernel as /lib, /bin, /src,
/proc, /boot, /sbin, /temp and /var. Probably a left over assumption from
the Windows and MacOS install features. Maybe the term is System instead
of Kernel. I assume at this point Mac and Windows also have a Kernel (for
lack of...).

Thinking that each of these would be modified for whatever I compile into
the kernel (and erased using make clean). So my grand plan was to rename
all of these, well except for /var and /tmp and start over, again,
thinking that I could boot via floppy, copy the kernel and sort through
the renamed files putting what I needed back in once I saw what the kernel
put in these dirs (when it created replacements.) I'm kinda glad it didn't
work out that way because the info you've given me makes me think the
kernel wouldn't rebuild the dirs I mentioned. And if it did I think it'd
take forever to figure out what everything was for and make the box
functional again.

Wow, long sentences.

So regarding the security aspect of modules. It is safe to leave them in
if the kernel doesn't support modules? What I'm trying to do is get down
to an "only what I need" state, without losing the existing functionality.
That way if something is in there I added it myself. Red Hat is great for
beginning the Linux trek, in my opinion, but if really want to know
what this box will do I need to know what's in here. And I'm not the type
that can read a book and know what everything does, no adrenaline
involved :}.

John 

On Mon, 14 Aug 2000, Wayde Allen wrote:

> On Mon, 14 Aug 2000, John Starkey wrote:
> 
> > > What kinds of things are you
> > > moving around and why are you moving the /lib files?  Nothing should need
> > > to move to compile or recompile.  
> >  
> > See above. When I re-compiled I disabled modules support. Then I noticed
> > in /lib/modules that everything was still there.
> 
> Yes, just because you compile a kernel not to use the module library
> doesn't mean that the module library should go away.
> 
> > So "what the hell" I decided to try renaming everything else I thought the
> > kernel would replace, knowing that it'd boot from the floppy or CD no
> > matter what.
> 
> It sounds to me like you don't quite understand what a kernel actually is.
> 
> The kernel is really just one single file.  If you go to your root
> directory you should see something like vmlinuz, or in your case perhaps
> bzlinux, ... whatever.  That is your kernel, it is just one executable
> file that the boot loader starts at boot time.  When you compile a new
> kernel you make a new one of these and copy that to your root directory. 
> To make the new kernel boot, you have to tell the boot loader (usually
> LILO) where, and what it's name is. 
> 
> All of thee other stuff you are tinkering with is the source code and the
> compiler library files.  The kernel will either use something from the
> libraries (modules) if you tell it to or not.  Moving your /lib stuff
> around just trashes your compiler, and any programs that make use of
> shared libraries. 
> 
> > The floppy image was gave me the same kernel panic.
> 
> It probably either tried using a library you renamed, or mounting
> something that you've moved.
> 
> >  So I
> > tried CD. And I think I forgot to take the floppy out, because the CD
> > didn't boot.
> 
> Sure that will do it.
> 
> > So that's where I started to get scared. Later the CD did boot. And my
> > panic stricken research really learned me a lot :}
> 
> Yeah, you learn a lot doing things like this.  The CD will boot since it
> doesn't reference anything on your hard drive.
> 
> > > Keep in mind that you
> > > can have as many kernels in your root directory as disk space and desire
> > > allows.  You put entries in your Lilo.conf file to point to each kernel
> > > file.  That way you can start whichever one you want.
> > 
> > This is the route I'll take in the future. I didn't totally understand the
> > HOWTO regarding this technique and heard that it can be done without this.
> > So for newbie sake I did without.
> 
> OK, although that just means you need a different boot loader if you
> aren't using LILO.  The game is the same.
> 
> For LILO if you should have a file /etc/lilo.conf that looks something
> like:
> 
> boot=/dev/sda
> root=/dev/sdb2
> compact
> install=/boot/boot.b
> map=/boot/map
> vga=normal
> delay=20
> image=/vmlinuz  <--------- This is default kernel since it appears first
>    label=Linux
>    read-only
> other = /dev/sda1 <------- This is my dual boot Windows NT (never used it)
>    label = WinNT
>    table = /dev/sda
> 
> So if you compile a new kernel and want it to be bootable you'd modify
> this file so it reads something like:
> 
> boot=/dev/sda
> root=/dev/sdb2
> compact
> install=/boot/boot.b
> map=/boot/map
> vga=normal
> delay=20
> image=/bzlinuz      <---- give the name of the new kernel
>    label=New_Linux  <---- give it a title in the boot menu
>    read-only
> image=/vmlinuz      <---- leave the old kernel intact in case you need it
>    label=Linux_old
>    read-only
> other = /dev/sda1
>    label = WinNT
>    table = /dev/sda
> 
> Next all you do is type the command lilo to run the lilo program.  The
> next time you reboot your machine the new kernel will be the default, or
> you can choose the old kernel (or other OS) by hitting the tab key to get
> the menu and selecting the appropriate entry.
> 
> - Wayde
>   (wallen at boulder.nist.gov)
> 
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>