Comment 109 for bug 477104

In executing Xavier's suggestion in #72 to set GRUB_DEFAULT=2 in /etc/default/grub ... I typo'd set GRUB_DEFAULT=1

As the gurus here will already know, this means that the system booted to the grub kernel selection menu; with kernel 31-17 (recovery mode) option highlighted rather than the desired 31-16. No problem, I just arrow'd down to the 31-16 option and all went well.

However, when I went back to /etc/default/grub and corrected my typo with a "2" the problem of booting to the sh:grub> prompt returned. So I went back to /etc/default/grub and set the "2" back to "1" ... which had just worked a moment ago ... no joy. Right back to where I started with kernels 17, 16, 15 available ... 16 bootable by hand ... 17 "invalid magic number" ... 15 untested ... and my results to the required #29 tests identical to those described in #47 and others.

So, my experiences certainly confirm #47, #48, #49.

In executing Xavier's suggestion:

* All edits made via 'sudo emacs /etc/default/grub'
* Ran 'sudo update-grub' and 'sudo update-grub2' after each edit
* cat /etc/boot/grub/grub.cfg reflected changes successfully made by grub-mkconfig

Curiouser and curiouser ... thanks for all the work here! I was trying to find a lazy shortcut to Mark Abene's #65 "real" fix ... but so far, looks like that's still the most reliable workaround, for now.