So these .old kernels are generated by the standard linux kernel build system? Can you give a reference to some documentation or discussion that can be used to convince upstream that they should be ignored?

They are generated by the installkernel script, from /sbin/installkernel
on a Fedora 16 box:

if [ -f $INSTALL_PATH/$KERNEL_NAME-$KERNEL_VERSION ]; then 
      mv $INSTALL_PATH/$KERNEL_NAME-$KERNEL_VERSION \
              $INSTALL_PATH/$KERNEL_NAME-$KERNEL_VERSION.old;
fi

if [ ! -L $INSTALL_PATH/$KERNEL_NAME ]; then
    if [ -e $INSTALLPATH/$KERNEL_NAME ]; then 
        mv $INSTALL_PATH/$KERNEL_NAME $INSTALL_PATH/$KERNEL_NAME.old
    fi
fi

if [ -f $INSTALL_PATH/System.map-$KERNEL_VERSION ]; then 
      mv $INSTALL_PATH/System.map-$KERNEL_VERSION \
              $INSTALL_PATH/System.map-$KERNEL_VERSION.old; 
fi

if [ ! -L $INSTALL_PATH/System.map ]; then
    if [ -e $INSTALLPATH/System.map ]; then 
        mv $INSTALL_PATH/System.map $INSTALL_PATH/System.map.old
    fi
fi

[jes@red-feather ~]$ rpm -qf /sbin/installkernel 
grubby-8.8-2.fc16.x86_64

This is a great example of how an over-complicating script system breaks
things left right and center :(

Jes

Ok, so it is Fedoras grubby that do stuff that interfere with upstream grub. That is not something upstream grub should care about, and it is hard to see why Fedora grub2 should be patched to work around behaviour of other Fedora stuff.

But what is the point in having these .old files if they don't show up in the boot menu? Having them in the boot menu seems like a fine rescue mechanism to me.

It would probably be better if grubby stupped creating these .old files.

No idea if Fedora's grubby is different here or not. There is plenty of
reason to leave the old kernels behind so you can roll back to them if
needed, even if they have the same version number.

What is the real problem here is that grub is adding 217 entries to my
grub menu which I didn't ask it to add in the first place. When using a
devel box for a while you end up with so many entries it's impossible to
find the ones you actually want to work with because of this.

grub/grubby or whatever it is, should not add the .old files, just as most
packages leave the .rpmsave files behind etc.

Jes

If it makes sense for you to have 217 .old kernels in /boot then I think it makes sense that grub2 creates entries for them.

Why do you want .old kernels if you don't want to be able to boot them from the boot menu?

I may want to keep them in case I broke something in the middle.

This is exactly the problem though, when I do a make install they should
be added, but if I manually removed the entry from grub.conf, grub should
not re-add it without asking for it explicitly.

Having 217 entries in the boot menu makes it impossible to find anything.
It's a major issue if you have more than one distro installed and you
develop and test for all of them. With all the auto-probing you end up
with a grub menu so long that it takes days to look through it, and it's
even worse when working using serial console.

grub2-mkconfig will intentionally overwrite your existing boot loader configuration. That is one reason Fedora doesn't use it on kernel upgrades. If you don't want it to overwrite your customizations and add entries for all your kernels then don't invoke it.

I doubt upstream or the Fedora packager consider it a relevant use case to have 217 kernels in /boot that shouldn't show up in the boot loader. /etc/grub.d/10_linux is in /etc - feel free to customize it.

A simpler solution could be to move .old kernels from your manual kernel installations to a subdirectory.

FWIW, I still can't believe that you really need/want all these old kernels around. Your or grubby should remove them at some point.

Well Fedora provides the script that creates the .old files, so Fedora knows
that you don't want them all to show up and that they are backup files.

This bug was filed against Fedora, so yeah, it's a bug in Fedora grub/grubby/
whatever is responsible for it, to not include these when one invokes the
grub-mkconfig Fedora provides.

The problem with grub2 is that adding modifications and changes is an utter
nightmare due to the new format of them. In addition grub-mkconfig doesn't
properly parse the kernel parameters for other installs you may have on your
system. Ie. if you have Fedora 16 and Fedora 17 on the same box and have 17
as your master - it won't pick up the kernel arguments for 16's kernels, but
just provide some bad default - again a major issue when working with serial
console. Effectively it forces you to chain load the grub of the other OS in
order to boot properly.

There's a bunch of other problems with grub2 - like it kills the serial port
when you chain load another gru, so once you picked you want F16 from your
F17 grub, you can no longer pick the kernel you want. But this is for another
bug.

Anyway, short story here is that grub-mkconfig in Fedora is misaligned with
the installkernel script in Fedora, and should be taught to ignore .old files
as it was clearly intended to do.

Well ... it seems like we can agree to disagree on whether grub should ignore files left over from the installkernel convenience script shipped with grubby.

I could agree that grubby installkernel perhaps should have an option for not creating .old files or include a /sbin/deletekernel (which would be a simple rm command) to remove old kernels.

FWIW: I am sure nothing will change in grub and you will have to use a manual workaround.

I would have closed this with NOTABUG.

Yes, other bugs in grub2 should be filed separately and there is no good place for general complaints about how much grub2 sucks.

Yes, the current os-prober linux entries are useless. Upstream will switch to using 'configfile' for chaining of bootloaders when os-prober supports it.

I believe that since you do want to boot them sometimes as you have acknowledged yourself, we should keep an entry for them

(In reply to comment #9)
> Well ... it seems like we can agree to disagree on whether grub should
> ignore files left over from the installkernel convenience script shipped
> with grubby.
> 
> I could agree that grubby installkernel perhaps should have an option for
> not creating .old files or include a /sbin/deletekernel (which would be a
> simple rm command) to remove old kernels.
> 
> FWIW: I am sure nothing will change in grub and you will have to use a
> manual workaround.
> 
> I would have closed this with NOTABUG.
> 
> Yes, other bugs in grub2 should be filed separately and there is no good
> place for general complaints about how much grub2 sucks.
> 
> Yes, the current os-prober linux entries are useless. Upstream will switch
> to using 'configfile' for chaining of bootloaders when os-prober supports it.

We have an inconsistency in the installed system here. The so-called
convenience script happens to be a key component for developers - try doing
some kernel development and you'll find out just how annoying it is for grub
to end up with 217 entries in the menu.

Whether grub2 upstream does or does not ignore .old files is irrelevant,
however right now Fedora has an inconsistency between what installkernel
does and what grub2-mkconfig does - that *IS* a bug, which should be fixed.

It is pretty clear grub2-mkconfig is the component at error here!

I will have to file other bugs on grub2 obviously, the chain loading
technique is unfortunately unusable with current grub2 - been there done
that. You are right though, there is no place to file bugs about how
hopeless and annoying the grub2 config file format is :(

Jes

Looks like you're not interested in being constructive or finding a solution. In this case I stop the discussion right here, right now.

I proposed a constructive solution: ignore the .old files so the behavior
is consistent with installkernel

It doesn't solve the following problem:
for a user unfamiliar with manual config entry editing, it's not possible to use a kernel if there isn't a corresponding entry in the menu. Yet the kernel is still there occupying space, so if user can't use it you might as well delete it altogether.

A user will not end up with a .old file in /boot unless he/she ran the
installkernel script. If he/she can run that script, the person can also
figure out how to hit 'e' in the grub menu.

Leaving the .old files untouched is consistent with how rpm moves old
config files to .rpmsave if one exists already. In this case you also end
with a config file that you cannot use directly, without manual intervention.

The difference with .old kernel files is that kernel developers generally
generate a lot of them quickly, and it is frustrating having to manually
go remove them all the time. We don't really care about having a lot of files
there that aren't necessarily usable.

This can't be propagated in upstream since other distros have other behaviour for .old in which you do want to have the entries for them. So it'd a RedHat-specific patch something like:
=== modified file 'util/grub-mkconfig_lib.in'
--- util/grub-mkconfig_lib.in	2012-05-27 11:14:42 +0000
+++ util/grub-mkconfig_lib.in	2012-06-04 10:21:16 +0000
@@ -178,6 +178,7 @@
     case "$1" in
       *.dpkg-*) return 1 ;; # debian dpkg
       *.rpmsave|*.rpmnew) return 1 ;;
+      *.old) return 1 ;;
       README*|*/README*)  return 1 ;; # documentation
     esac
   else

If installkernel is changed to something that doesn't clash with other distros (e.g. .installkernel-old) such a change can be upstreamed.
Please don't disparage my work as I don't disparage yours. Usually when I hear someone disparaging my work blindly and unconstructively, I just ignore this person altogether.

(In reply to comment #11)
> We have an inconsistency in the installed system here.

I kind of agree. The two tools is not a bullet proof combination. It doesn't scale with the work-flow you use.

> It is pretty clear grub2-mkconfig is the component at error here!

It is pretty clear that a workflow where you get 217 .old kernels in /boot is at error.

removedotoldkernel() { rm -f /boot/$1.old; }

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.