Avoiding best-effort

Avoiding best-effort

[Samuel Thibault]

Hello,

There's a concern with the way grub menu entries work: even if a command
fails, grub continues with others, like bash's "best-effort" way.  This
leads to difficult-to-diagnose results: say for instance

multiboot /boot/mykernel
module /boot/initrd
module /boot/inittask

and initrd is too big for the memory for instance.  The actual error
message that the user will be able to read is "rd0: no such device",
because grub will silently ignore the initrd load failure.

It'd be better to at least have a way to show the actual error.  I've
talked a bit with phcoder, the kind of solutions we've come with are

- "set -e" command, to disable best-effort
- shell-like "&&" to chain commands only if they succeed
- introduce a small delay when printing error messages, to keep best
  effort while still showing the actual grub error.

Thoughts?

Samuel

Re: Avoiding best-effort

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On 07/10/2010 09:11 AM, Samuel Thibault wrote:
> Hello,
>
> There's a concern with the way grub menu entries work: even if a command
> fails, grub continues with others, like bash's "best-effort" way.  This
> leads to difficult-to-diagnose results: say for instance
>
> multiboot /boot/mykernel
> module /boot/initrd
> module /boot/inittask
>
> and initrd is too big for the memory for instance.  The actual error
> message that the user will be able to read is "rd0: no such device",
> because grub will silently ignore the initrd load failure.
>
> It'd be better to at least have a way to show the actual error.  I've
> talked a bit with phcoder, the kind of solutions we've come with are
>
> - "set -e" command, to disable best-effort
>   
I think this is a possibility. set -e must be limited to current
menuentry. Also it's out of the question to touch internal "set" for
this. You need either a separate command (shopt ?) or use priorities.
But set -e must not be imposed on user by default because target machine
may be a server and a small error shouldn't interrupt server booting.
> - shell-like "&&" to chain commands only if they succeed
> - introduce a small delay when printing error messages, to keep best
>   effort while still showing the actual grub error.
>   
This would be good independently of interrupting execution. Wait must be
right before executing implied "boot" command. It should also not take
into account the progress echos.
> Thoughts?
>
> Samuel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]