Trond Danielsen wrote:
On Mon, Mar 10, 2008 at 12:13 AM, Andrew Farris <lordmorgul@xxxxxxxxx> 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@xxxxxxxxx> 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
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
