F8 kernel-2.6.24.3-12.fc8

[Andrew Farris]

Trond Danielsen wrote:
> On Mon, Mar 10, 2008 at 12:13 AM, Andrew Farris <lordmorgul at gmail.com> wrote:
>> Benjamin Kreuter wrote:
>>  > On Thursday 06 March 2008 19:29:23 Chuck Ebbert wrote:
>>  >> Sorry, we had to release with known bugs. A new kernel will be in
>>  >> updates-testing very shortly.
>>  >
>>  > Why did you have to release with known bugs?  Why not just wait until the bugs
>>  > are fixed?  The last three kernel updates broke suspend for me...
>>
>>  Then why are you installing them?  If this kernel was known to break things,
>>  then when it hits updates don't install it... not rocket science.
> 
> When the yum update applet reports that new updates are available, I
> always choose to accept them without checking in advance whether or
> not they will render my computer unusable.
> 
> Also if I did decide to check if the update would break my system, it
> currently is not possible to tell pup to ignore this particular
> update.

I understand this complaint, a method of marking an update as 'never install 
this one' is not even available yet in PackageKit, the eventual replacement of 
pup in rawhide, and it would be a very good feature to have.

> A try-catch mechanism could provide a fallback solution to kernels.
> Kernels could be marked as bootable, not_checked and non_bootable, and
> grub could check this flag/status file and switch to the first
> bootable kernel if the default is marked as non_bootable. Perhaps a
> feature like this is already available in grub?

An automated choice no, but you can change the default kernel manually by 
changing the 'default=' setting in /boot/grub/grub.conf.  This can also be 
changed by using the system-config-boot tool (which may not behave right in F8 I 
do not remember, but in rawhide it works correctly).

In any case, the try-catch mechanism is in place by keeping the prior kernel 
installed, and if it fails you choose the next one in the list next time.  It is 
not possible to try a kernel until its been booted, and when it does boot if the 
kernel itself misbehaves it is not possible to do anything automatic because the 
kernel has failed to do what it should do... the kernel is *everything*.  In 
some relatively minor kernel boot failures I'm sure a method could be there to 
set a kernel as 'nonbootable' so it is not tried again, but I suspect most of 
those situations the failure is so minor that the user is barely inconvenienced 
by it (network or sound not working).  In any major error it is just not going 
to be feasible to build a 'recover from this disastrous kernel failure' mechanism.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----