On Sat, 2010-05-15 at 12:19 +0300, Gilboa Davara wrote: > On Sat, 2010-05-15 at 11:01 +0200, Richard Zidlicky wrote: > > On Sat, May 15, 2010 at 09:58:27AM +0200, Alexander Boström wrote: > > > > > Long story short: There are situations where a grub menu is vital, like > > > until you've successfully booted a new kernel. > > > > of course, and I do not think it is so hard to think of a sensible > > behaviour. > > > > After each (semi)automatic change to grub/kernel conf as well as for the > > very first > > boot there should be a timeout as well as visible menu. > > Once the kernel did boot with default command line etc it would be safe to > > set > > the timeout to a small value - after asking the user. > > > > More elaborate solution, there could be two config values - quicktimeout > > and > > safetimout. > > After kernel and config changes timeout would be changed to safetimout and > > once > > the kernel booted safely it could be reset to quicktimeout automatically. > > > > Richard > > Another options will be to test a successful boot flag. (E.g. a touch > file in /boot/). > If the file doesn't exists (Post installation, new kernel, failed > boot/shutdown) grub should switch to a predefined timeout, giving the > user time to react. > > The main issue here, is grub changes. Such a feature will require > changes to grub (code), kernel (post install script) and init functions. > > While the last two are less problematic (bash scripts), given the fact > that development of grub is slowly shifting to grub2, I doubt that the > Fedora grub maintainers will be willing to spend time on such a feature > when grub is be phased out. (Or is it?) > > - Gilboa >
Actually, I do remember grub having a fallback feature. It should solve the failed kernel upgrade problem. However, it will not solve the failed first boot problem. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
