[Bug 1912915] [NEW] grub CLI too difficult to explain to user to recover from failed boot

[Damiön la Bagh]

Public bug reported:

Remote machine 100km further away
Computer is updating
End user thinks computer is slow and pulls the power plug from the computer
Turns out computer was updating the kernel
Starts machine
Grub can't find any kernels anymore and drops into Grub CLI

The process of finding the kernel with the CLI is too difficult to
explain over the telephone

have to drive 100km to the customer location to get Ubuntu to start

grub2 needs better failsafes built in. especially with the advent of
Internet of Things devices and remote computers.

We've all been there, should not be a phrase we are saying about Ubuntu.

What needs fixing:
Some way of remote access into Grub when it drops into CLI

and/or

Having grub2 be more highly available and redundant by duplicating the
things it needs to start on two area's of the disk. Similar to how GPT
works with the partition table at the start and a redundant partition
table at the end.

and easier commands for the command line.

Current way of working
grub> ls
(hd0,1)(hd0,2)(/dev/mapper/vg/root)
grub> set root=(hd0,1)
grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot

Proposed way of working
grub> boot

the command line should only show up when requested. 
The computer should boot no matter what, even if it has to drop into the previous kernel by itself to do so.
Grub2 should be smart enough to search the drives and partitions for a kernel any kernel to get the system up and running.

We are in the age of machine learning, yet computers are still not
booting for silly reasons.

Starting with the bug here. Will consider reporting upstream.

** Affects: grub2 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1912915

Title:
  grub CLI too difficult to explain to user to recover from failed boot

Status in grub2 package in Ubuntu:
  New

Bug description:
  Remote machine 100km further away
  Computer is updating
  End user thinks computer is slow and pulls the power plug from the computer
  Turns out computer was updating the kernel
  Starts machine
  Grub can't find any kernels anymore and drops into Grub CLI

  The process of finding the kernel with the CLI is too difficult to
  explain over the telephone

  have to drive 100km to the customer location to get Ubuntu to start

  grub2 needs better failsafes built in. especially with the advent of
  Internet of Things devices and remote computers.

  We've all been there, should not be a phrase we are saying about
  Ubuntu.

  What needs fixing:
  Some way of remote access into Grub when it drops into CLI

  and/or

  Having grub2 be more highly available and redundant by duplicating the
  things it needs to start on two area's of the disk. Similar to how GPT
  works with the partition table at the start and a redundant partition
  table at the end.

  and easier commands for the command line.

  Current way of working
  grub> ls
  (hd0,1)(hd0,2)(/dev/mapper/vg/root)
  grub> set root=(hd0,1)
  grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1
  grub> initrd /boot/initrd.img-3.13.0-29-generic
  grub> boot

  Proposed way of working
  grub> boot

  the command line should only show up when requested. 
  The computer should boot no matter what, even if it has to drop into the previous kernel by itself to do so.
  Grub2 should be smart enough to search the drives and partitions for a kernel any kernel to get the system up and running.

  We are in the age of machine learning, yet computers are still not
  booting for silly reasons.

  Starting with the bug here. Will consider reporting upstream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1912915/+subscriptions