Zing wrote:
On Mon, 10 Mar 2008 14:23:53 -0500, Callum Lerwick wrote:
On Mon, 2008-03-10 at 01:22 -0700, Andrew Farris wrote:
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...
It's easy. It's much like the dirty flag on filesystems. GRUB writes a
flag somewhere on disk, that indicates "Attempting to boot kernel
2.6.XXXXX". Then somewhere in the early userspace init scripts, you
change the flag to "Finished booting kernel 2.6.XXXX". The next time
grub starts up, it sees this flag and it now knows that that particular
kernel at least made it to userspace, which is a pretty good indication
it's not completely b0rked. If GRUB starts up and sees a "Attempting
boot" flag still remaining, then that's an indication that that kernel
failed to boot.
And I know this idea has come up before... Is this on anyone's to-do
list?
I believe redhat has been carrying around a patch in grub which
essentially would allow the above, called "bootonce" patch. It allows
you to couple it with "reboot on kernel panic" and "failback" to a known
working kernel... I've never tried it or had the use for it myself.
This idea is still going to work for some failures and not for others. I
suppose it is better to have that than nothing, but you have to choose where to
place the 'ok the kernel is booted enough to count' position in the booting
sequence. For that to be really useful it needs to be after any kernel modules
are loaded and fairly deep into the daemon startup I would think.
IMO, The user still needs to know about the grub menu and the presence of
multiple kernels in the end.
--
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
