When I used lilo, I ran lilo before booting to the new kernel. (It doesn't hurt anything, and I did have an install that didn't run it, so the new kernel wasn't an option on the boot list.)
With grub, I found that everything had been updated properly every time I have updated the kernel even when I used up2date. (That's RH specific.)
I looked everything up and found out something that makes me look stupid once again. ( I consider SuSE to be an unimpeachable source of linux information.)
http://www.google.com/linux "make mrproper" The results:
Also check the FAQ at
http://www.suse.com/support/faq and the
archives at
http://lists.suse.com
On Wed, 4 Jul 2001, Rafael Herrera wrote:
rh> 'mrproper' leaves your sources as you got them when you unpacked the
rh> sources.
rh>
This will also remove your .config file, this is the file that contains
all your kernel configuration options for what to compile into the kernel
or as modules. So if you've spent alot of time coming up with the perfect
configuration for you system, save the file to another directory before
running mrproper.
rh> 'clean' deletes all the binary objects and a few other files, but leaves
rh> others, like the .depend files.
rh>
--
S.Toms -
smotrs@mindspring.com -
www.mindspring.com/~smotrs
SuSE Linux v7.0+ - Kernel 2.2.18
Loud burping while walking around the airport is prohibited in
Halstead, Kansas.
--
S.Toms" wrote:
> On Wed, 4 Jul 2001, Rafael Herrera wrote:
>
> rh> 'mrproper' leaves your sources as you got them when you unpacked the
> rh> sources.
> rh>
>
> This will also remove your .config file, this is the file that contains
> all your kernel configuration options for what to compile into the kernel
> or as modules. So if you've spent alot of time coming up with the perfect
> configuration for you system, save the file to another directory before
> running mrproper.
I learned that the hard way.
Actually, it seems that if you copy .config to another file in the same
directory, say config.00, it doesn't get clobbered by mrproper. Don't know
about distclean.
--
On 4 Jul 2001, S.Toms wrote:
> rh> 'mrproper' leaves your sources as you got them when you unpacked the
> rh> sources.
> rh>
>
> This will also remove your .config file, this is the file that contains
> all your kernel configuration options for what to compile into the kernel
> or as modules. So if you've spent alot of time coming up with the perfect
> configuration for you system, save the file to another directory before
> running mrproper.
'make mrproper' is supposed to be the first step when compiling
your kernel, so it makes sure there are no "stale" files lying
around from a previous compilation, thereby returning it to its
original prestine state. 'make clean', however, is supposed to
follow 'make dep'.
--
--------------------------------------------------------------------------------
Rafael Herrera wrote:
> 'mrproper' leaves your sources as you got them when you unpacked the
> sources.
>
> 'clean' deletes all the binary objects and a few other files, but leaves
> others, like the .depend files.
So what's the difference, then, between "mrproper" and "distclean"?
--------------------------------------------------------------------------------
Look at the makefile:
mrproper: clean archmrproper
find . \( -size 0 -o -name .depend \) -type f -print | xargs rm -f
rm -f $(MRPROPER_FILES)
rm -rf $(MRPROPER_DIRS)
$(MAKE) -C Documentation/DocBook mrproper
distclean: mrproper
rm -f core `find . \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
-o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
-o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -type f -print` TAGS tags
distclean removes other garbage.
(snip)
When ever I compile a kernel, I redo the configuration anyway, and I forgot why I do the make mrproper step--I've just done it that way since the very first time.
One reason is that things are changing so fast, that I may be unaware of some of the new options. (If I see something new I'll abort, and read the kernel docs--something I should do every time anyway.)
Another reason is that I really want to be aware of exactly what is built on the system. It forces me to be methodical, instead of just doing things on impulse--which makes it much more likely that I will log everything I do on the system. Who me? Forget to log something? Nah. Right.
The creation of the directory in /lib with the full name of the new modules-full_kernel_version_number is part of the makefile. As is the creation of full-named files and new links in /boot. These new kernels have terrific makefiles. I haven't repeatedly compiled kernels with the same name in a while.
When I did it[Before compiling and installing the new kernel]: I mv (rename) the old kernel and related files in /boot, remade the links to point to the corresponding files and directories; renamed (mv) the specific modules directory in /lib; and renamed (mv) the kernel name in /etc/lilo, and /boot/grub/grub.conf. (I try to keep even unused things in sync, because I am paranoid.). The other way is to make an edit in the makefile--something I rarely have the courage to do--unless it is broken, I don't mess with it. (I have written successful scripts and programs, but I don't write them every day.)
P.S. I keep the old source for a while, using it's full name, in the /usr/src directory--in case things break with the newer kernel. That way I can test the cutting edge stuff, but still have the option to apply patches and stay with the older kernel. If you ls -al /usr/src you will see that the linux directory is a link to the current source tree. Before compiling, generally you re-do the link to point to your new sources.
I still keep a copy of the source pkg., but I'm lazy. If I'm going to patch, I want it ready--not in a tar-ball. If you are tight on room in /usr, then tar your old source tree if you haven't kept the package or if it has been successfully patched.
I have a separate /DATA partition to keep stuff like that, downloads, backups, and other stuff I want to keep. /home is kept as small and clean as possible.