On 17.10.2011 00:40, Chris Jones wrote: > 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. > Unless the UUID was changed (in which case the partitioning tool is to blame), number of /boot was changed, embed area was affected or it was a blocklist install to begin with (in which case you've been warned) it shouldn't happen. If you can provide a way to recreate it on loopback (in preference a script), please file a bug report. Using UUIDs to locate /boot is currently done only on cross-disk installs as it eats valuable embedding space. > 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 (?). Read better. grub.cfg uses UUIDs, partition ids are only a fallback. > Will UEFI help solve the catch22 situation where you need to boot > a given system to fix a broken boot loader? Nope. UEFI is useless in most senses. Its only advantage is that you don't need embedding area to take special care of.
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
