Re: Resizing moving & deleting partitions

[Vladimir 'φ-coder/phcoder' Serbinenko]

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