В Mon, 2 Dec 2013 12:49:03 -0800 Jonathan McCune <jonmcc...@google.com> пишет:
> On Mon, Dec 2, 2013 at 12:38 PM, Andrey Borzenkov <arvidj...@gmail.com>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 BIOS. 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 place? > > > 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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
