[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v0] Require human interaction to go to normal shell if grub.c

From: Jonathan McCune
Subject: Re: [PATCH v0] Require human interaction to go to normal shell if grub.cfg has a problem
Date: Mon, 9 Dec 2013 07:25:27 -0800


On Sat, Dec 7, 2013 at 4:35 AM, Andrey Borzenkov <address@hidden> wrote:
В Mon, 2 Dec 2013 12:49:03 -0800
Jonathan McCune <address@hidden> пишет:

> On Mon, Dec 2, 2013 at 12:38 PM, Andrey Borzenkov <address@hidden>wrote:
> >
> > I still do not quite understand how rebooting can fix the problem. The
> > only case it may happen is when you have intermittent network issues
> > where grub fails to read some file.
> >
> Ah, rebooting allows a machine to network boot, e.g., PXE boot using its
> NIC.

Hmm ... how does it work? After reboot you use the same default boot
order and end up in the same non-working grub, right? May be you want
to not reboot but simply exit grub letting firmware to continue with
next boot choice; I'm not sure whether this works reliably in case of

Good point.  This is another interesting option.  I'm not sure how generally reliable it is for BIOS systems either, but it seems like a case worth considering.
And I still do not really see how useful it is. Booting from network
will presumably land you into some sort of remote installation
environment. How does it help? How do know it landed there in the first

I agree that a naive always-netboot-to-reinstall is not a useful configuration, but DHCP servers can be easily configured to enable or disable netboot for individual machines.  Sometimes this can be a nice control point for diagnosing or reconfiguring machines.  
> > I have a feeling that you attempt to paper over some problem outside of
> > grub.
> >
> This is somewhat true, in that grub's own commands should not get the
> machine into a state where this functionality is useful.  But furthering
> the real life example, users / administrators might make a mistake and
> create a broken config.  If the machine is unattended, it seems reasonable
> that the user might prefer for it to reboot.  Otherwise, it becomes
> necessary to somehow cause a reboot out-of-band.  These out-of-band
> solutions are generally proprietary and I think it's a good idea to have
> support for avoiding them if desired.

Well, I spent last 10+ years doing remote maintenance and I know
pretty well, that if you do not have remote access to console and
possibility to remotely trigger reboot, you will get in trouble in any
case. There are much more situations that require it and they are far
more probable than grub misconfiguration.

I concede that some problems inevitably require manual intervention, but the probabilities of different misconfigurations seem likely to be deployment-specific.   Remote console / serial concentrators / remote reboot / humans to press buttons  / etc are neither instantaneous nor free.  Anyways, I will try my hand at another iteration on this patch.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]