From: Jonathan McCune <jonmccune@google.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH v0] Require human interaction to go to normal shell if grub.cfg has a problem
Date: Mon, 2 Dec 2013 12:16:54 -0800 [thread overview]
Message-ID: <CADtfRCVW1djg-y64f=cxRPOb156zAZwpWcp-zc=U8bt4+HJFWw@mail.gmail.com> (raw)
In-Reply-To: <20131128213455.2aa3d691@opensuse.site>
[-- Attachment #1: Type: text/plain, Size: 5087 bytes --]
Replying here instead of the install_c thread to try to keep it clean. In
response to:
On Mon, Dec 2, 2013 at 11:18 AM, Andrey Borzenkov <arvidjaar@gmail.com>
wrote:
> On Mon, Dec 2, 2013 at 11:09 PM, Jonathan McCune <jonmccune@google.com>
> wrote:
> > On Sat, Nov 9, 2013 at 4:51 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> > <phcoder@gmail.com> wrote:
> >>
> >> Hello, all. install_c is feature complete and I intent to make it
> >> upstream unless issues are raised until 16 Nov. It's available under
> >> http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/install_c
> >
> >
> > I just realized that the option --grub-mkimage is now accepted silently
> > without having any effect in
> > util/grub-install-common.c:grub_install_parse(). This makes it no longer
> > feasible to easily wrap the mkimage command. While most of the
> meaningful
> > reasons to wrap grub-mkimage have now been added to grub-install, I've
> run
> > into something I'm struggling to work around: How do I add custom
> contents
> > to a load.cfg, since util/grub-install.c seems to unconditionally
> > grub_util_unlink(load_cfg)?
> >
>
> Could you provide examples of your grub.cfg usage? I think we need to
> have more real-life use cases to understand better how and when it is
> used.
The real life use case is a headless / unattended environment where it is
better to reboot than to present a console prompt if there is some kind of
GRUB problem, since the machine will just sit there until somebody or
something notices that it never booted up.
I was thinking that adding something in load.cfg (not grub.cfg) might be a
reasonable way to specify the desire to predispose GRUB towards rebooting
in the event of problems for use in headless/unattended environments.
Whether that is true or not, I see now that the intention is for the
contents of load.cfg to be generated by the appropriate grub tools, and not
from arbitrary shell scripts. No problem.
I'm wondering what is the "right" way to enable rebooting behavior. Flag
to grub-install? I also think this new functionality should have some kind
of delay and be cancelable at the console (current patch does this).
Thoughts?
Thanks,
-Jon
On Thu, Nov 28, 2013 at 9:34 AM, Andrey Borzenkov <arvidjaar@gmail.com>wrote:
> В Mon, 25 Nov 2013 15:46:48 -0800
> Jon McCune <jonmccune@google.com> пишет:
>
> > The rescue prompt is very useful for human operators, but not so
> > useful in unattended environments. Add a facility for rebooting
> > after a delay, so that, e.g., the system can still PXE boot if
> > there is no console attached.
> >
> > Signed-off-by: Jon McCune <jonmccune@google.com>
> > ---
> > grub-core/normal/main.c | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
>
> You get rescue prompt when you can *not* launch normal.mod.
>
> > index ad36273..f8953d5 100644
> > --- a/grub-core/normal/main.c
> > +++ b/grub-core/normal/main.c
> > @@ -32,6 +32,7 @@
> > #include <grub/i18n.h>
> > #include <grub/charset.h>
> > #include <grub/script_sh.h>
> > +#include <grub/time.h>
> >
> > GRUB_MOD_LICENSE ("GPLv3+");
> >
> > @@ -333,6 +334,21 @@ grub_normal_execute (const char *config, int
> nested, int batch)
> > }
> > }
> >
> > +/* Copied from grub-core/commands/sleep.c. */
> > +static int
> > +grub_interruptible_millisleep (grub_uint32_t ms)
> > +{
> > + grub_uint64_t start;
> > +
> > + start = grub_get_time_ms ();
> > +
> > + while (grub_get_time_ms () - start < ms)
> > + if (grub_getkey_noblock () == GRUB_TERM_ESC)
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
> > /* This starts the normal mode. */
> > void
> > grub_enter_normal_mode (const char *config)
> > @@ -340,6 +356,15 @@ grub_enter_normal_mode (const char *config)
> > grub_boot_time ("Entering normal mode");
> > nested_level++;
> > grub_normal_execute (config, 0, 0);
> > + /* Control only returns from grub_normal_execute() if there is some
> kind of
> > + * problem with grub.cfg, like it does not exist. Reboot by default
> unless
> > + * ESC is pressed within 5 seconds. */
>
> grub-mkrescue creates CD that starts normal CLI without grub.cfg. So
> please - not as default. You can make it dependent on variable which
> can be set in embedded grub.cfg for the cases when you really need it.
>
> > + grub_printf ("Press ESC in 5 seconds for a rescue shell.\n");
>
> "for a command line". This is not rescue shell.
>
> > + if (!grub_interruptible_millisleep (5000))
> > + {
> > + grub_printf ("Rebooting instead of going to rescue shell.\n");
>
> Ditto.
>
> > + grub_reboot ();
> > + }
> > grub_boot_time ("Entering shell");
> > grub_cmdline_run (0);
> > nested_level--;
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: Type: text/html, Size: 7061 bytes --]
next prev parent reply other threads:[~2013-12-02 20:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 23:46 [PATCH v0] Require human interaction to go to normal shell if grub.cfg has a problem Jon McCune
2013-11-28 6:41 ` Vladimir 'phcoder' Serbinenko
2013-11-28 17:34 ` Andrey Borzenkov
2013-12-02 20:16 ` Jonathan McCune [this message]
2013-12-02 20:38 ` Andrey Borzenkov
2013-12-02 20:49 ` Jonathan McCune
2013-12-07 12:35 ` Andrey Borzenkov
2013-12-09 15:25 ` Jonathan McCune
2013-12-09 23:33 ` Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADtfRCVW1djg-y64f=cxRPOb156zAZwpWcp-zc=U8bt4+HJFWw@mail.gmail.com' \
--to=jonmccune@google.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).