The new kernel packages update grub.conf in their post script. Not every
customer wants this feature and hence I feel it should be configurabel.
Moreover, some might want the newly installed kernel to bekome the default
Attached is a patch to new-kernel-image which makes this configurable via
a configuration file /etc/sysconfig/new-kernel-image.
Created attachment 54845 [details]
patch to /sbin/new-kernel-pkg
Nope, adding configuration options due to somebody just deciding they want a new
configuration option is the wrong answer. Havoc has written a few things up in
various places on the subject. This would cause *lots* of overhead for things
like up2date and anaconda for trying to figure out whether or not they can count
on the bootloader config being properly updated or not and it would end up
requiring duplication of all of the code present in grubby everywhere else which
defeats the purpose of having grubby to begin with.
Oh, and having a "make default" option is non-sensical due to the fact that if
someone installs the UP, SMP, and bigmem kernel and then installs a new version
of each in a different order, their default won't change in a sensible fashion.
I don't understand why I should not be allowed to disable grubby. Yes I agree,
grubby is just not flexible enough to handle certain situations. This is
why I want to be able to turn it off! I have my own tool which handles these
situations nicely, but it no longer works since the introduction of grubby
(since grubby gets in its way). I personally don't care since grub doesn't
work for us and we still use lilo. But users of my tool keep bugging me why
it does not work with grub the way it works with lilo. Linux is about choice
and I don't understand why you try to force me into using grubby if I
prefere something else. I fully understand that redhat cannot implement every
option users request, but the ability to disable grubby is trivial to implement
and it does not hurt anyone!
If I disable grubby and up2date does not update grub.conf, then this is
obviously what I want! Moreover, if I decide to use lilo, then this
situation is not handled either.
Adding an option attacks entirely the wrong problem. In what situation does
grubby not work properly for you instead and we can actually look at fixing the
And it causes a huge burden for support reasons, especially with the way
bootloaders are handled on upgrade now.
My tool makes the new kernel the default kernel if the old one was (handling
smp, bigmem, etc. properly). And it uninstalls old kernels which are no longer
needed (keeping only one old kernel). It works with both lilo and grub.
If the kernel post script can handle these, I'll be happy to throw my code away;-)
up2date does all of this... and new-kernel-pkg will handle lilo properly as soon
as I can dig myself out of replying to bug reports and doing other higher
priority tasks. But adding options which will significantly complicate what our
tools have to do isn't going to happen. If you don't want grubby to run, just
remove it... new-kernel-pkg always checks that it exists before trying to run it.
OK. Thanks for looking into this.