Make grub.cfg generation more robust

Bug #1912915 reported by Damiön la Bagh
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
New
Wishlist
Unassigned

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.

Revision history for this message
Damiön la Bagh (kat-amsterdam) wrote :

Here is the machine info from Landscape:

Distribution: Ubuntu 18.04.5 LTS (bionic)
Hardware:
Processor: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz
Memory: 8 GiB RAM
Storage: Model: SanDisk SDSSDX24
Size: 240 GB

Network: Model: Wireless 3160
MAC: f4:06:69:x:x:x
IP: 192.168.x.x

Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
MAC: 1c:1b:0d:x:x:x
IP: 192.168.x.x

Video: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller
Product identifier: GB-BACE-3150 (To be filled by O.E.M.)

Revision history for this message
Mate Kukri (mkukri) wrote :

I think what happened here is that the GRUB configuration itself got corrupted.

Normally a failed boot should never drop you to the prompt, and recordfail should show you the friendlier menu where you can select from two kernels.

I guess we could look into trying to make GRUB config generation more robust.

summary: - grub CLI too difficult to explain to user to recover from failed boot
+ Make grub.cfg generation more robust
Changed in grub2 (Ubuntu):
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.