yum wants to remove my kernels, why?

David Timms dtimms at bigpond.net.au
Sun Jan 22 22:17:51 UTC 2006


Timothy Murphy wrote:

>On Sunday 22 January 2006 17:14, Jeff Spaleta wrote:
>  
>
>>>I regard kernel and distribution as orthogonal,
>>>and would rather keep them separate.
>>>I don't find it very onerous to go through the Grub menu,
>>>and choose the kernel (or OS) I want.
>>>      
>>>
>>If you don't find it difficult to use the grub menu to find the kernel
>>you want.. why is it so bad if the new updates become the default?
>>    
>>
>I'm not a newbie.
>I don't think most newbies would know what to do if Linux fails to start.
>
>Actually, the responses to my posting simply confirm in my mind
>the enormous gap between developers and typical (ie home) Fedora users.
>  
>
>>Security kernel updates are very important, I don't see it as an
>>appropriate trade off to make the security update kernels optional to
>>avoid potential regressions.  Anyone running a system which needs to
>>avoid reboots into kernel updates because of ciritical production
>>situations should configure their system appropriately at install time
>>and should be aware of the impact on security by not using the
>>security update kernels.
>>    
>>
>...
>  
>
How about coding a situtation (previously seen in w95 auto scandisk), 
that when a new kernel is installed, a mark is placed somewhere 
indicating that it has not yet booted and run. When the default new 
kernel is booted, it writes to the disk(/boot? ro!) early in the boot to 
state that it is trying to start kernel x., and if it achieves runlevel 
3/5 or login screen, a process could clear the "not yet booted and run 
bit".  And the user could be given a one time autorun stating that a 
s/he is now running a new  kernel (umm a bit scarry - unless the right 
words found), and if new problems are found to use the grub boot menu to 
choose an older kernel. (or only if they / detection method) run the the 
non-current kernel.

I guess if the kernel sees the "not yet booted and run" flag for it's 
own version, it would set the default grub item to the previous kernel 
(in case it fails to boot). Then if it completes boot the grub entry is 
re-changed back to what it needs to be.

This could be pretty transparent to the user, but would provide a nice 
fall back in the rare cases where stuff happens...

I understand Timothy's point, I admin a dell 2650 server, where updated 
smp kernels would hang during boot. But as it is a production machine, 
the only thing to do is get it working as fast as you can... choosing 
the single kernel, or previous kernel gets you back in action again, it 
would have been nice for the kernel to "detect it's own failure" and go 
back to the last happy kernel. It is important that this last kernel is 
still installed !




More information about the test mailing list