Lately, I had to increase the size of the partition where grub-pc is managed. Upon rebooting, the grub menu had become inaccessible, all I could see was an "Error: file not found". As far as I can remember, there was also a shell-like prompt with "rescue" or "grub rescue" followed by the greater than ">" sign but I wasn't able to make much of that.
I eventually managed to recreate a working grub environment (via a graphical mini-app called "boot-repair" that I ran off the ubuntu live CD) but now I appear to have lost my customizations, framebuffer console with my favored fonts and screen resolution. The tool I ended up using works.. automatically, but it doesn't tell you much so that at this point, I don't even know on which partition the active grub actually lives. Now, I have more than a handful of linux systems on this machine, and I occasionally have to delete, move, or create new partitions for new installs. Backing up everything and reinstalling on top of LVM would probably make it easier to move stuff around, but since grub.cfg config files appear to point to bootable partitions via their ordinal numbers - i.e. msdos3, msdos7, etc. - I doubt this would make much difference (?). On such multi-system machines, what would be the better strategy to avoid such situations? I was thinking that a bootable USB key that supports my active custom grub environment (and just that) might provide something a bit more robust than my current setup. Has anyone documented setting this up, or come up with a better approach? Will UEFI help solve the catch22 situation where you need to boot a given system to fix a broken boot loader? Thanks, CJ _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
