From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VpH6S-0000Uk-MU for mharc-grub-devel@gnu.org; Sat, 07 Dec 2013 07:35:24 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpH6I-0000RJ-El for grub-devel@gnu.org; Sat, 07 Dec 2013 07:35:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VpH6A-0006pV-0L for grub-devel@gnu.org; Sat, 07 Dec 2013 07:35:14 -0500 Received: from mail-lb0-x230.google.com ([2a00:1450:4010:c04::230]:63324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpH69-0006mZ-Or for grub-devel@gnu.org; Sat, 07 Dec 2013 07:35:05 -0500 Received: by mail-lb0-f176.google.com with SMTP id x18so685693lbi.7 for ; Sat, 07 Dec 2013 04:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=OH03y8nRRknifMaPPMXRTao1U/ZQ6toR/OuQf5EvgFw=; b=q+PVcEZIo1z1lDsrqRG5kexFdxKTOTnbPrHEsH+ogGUZyryCYC8WwS5ni/tsfga4MG ne84kqaObyULvSNis25nDma54jjT+pcIy6gRF9b2/AoZ6t/f3QGGAvgj/MQB0S0p5ZuU BCeq20qPu4lcXIggmlIuiWveGil+b3TIu3KgRG2aQXHO2FN3DLDnT9AaxrUCJ/bidRiQ xwZtMxIlzGVk6qeibSyeNEwMSGx8suB57f0FgNfzLuTzrTD0BqyqJIcat8SHIe2F8b5S y2DsOxYk6nm6eNxC7wEfmtue2D7qMFKInf17W/SeFja05JhV3DUYXiFuzszvc2sLsmQ0 U5tQ== X-Received: by 10.112.53.201 with SMTP id d9mr2099284lbp.26.1386419704563; Sat, 07 Dec 2013 04:35:04 -0800 (PST) Received: from opensuse.site (ppp91-76-134-134.pppoe.mtu-net.ru. [91.76.134.134]) by mx.google.com with ESMTPSA id e10sm2731805laa.6.2013.12.07.04.35.03 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 07 Dec 2013 04:35:04 -0800 (PST) Date: Sat, 7 Dec 2013 16:35:03 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: [PATCH v0] Require human interaction to go to normal shell if grub.cfg has a problem Message-ID: <20131207163503.6d0c54ee@opensuse.site> In-Reply-To: References: <1385423208-18212-1-git-send-email-jonmccune@google.com> <20131128213455.2aa3d691@opensuse.site> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::230 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 12:35:23 -0000 В Mon, 2 Dec 2013 12:49:03 -0800 Jonathan McCune пишет: > On Mon, Dec 2, 2013 at 12:38 PM, Andrey Borzenkov 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.