Bug 63947
| Summary: | RFE: Make new-kernel-image more flexible | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Gerald Teschl <gt> | ||||
| Component: | mkinitrd | Assignee: | Jeremy Katz <katzj> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.3 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2002-05-22 17:08:41 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Gerald Teschl
2002-04-22 15:12:13 UTC
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 real problem. 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. |